Model Context Protocol

How MCP Connects AI Agents to Network Infrastructure

Using MCP servers to give AI agents structured, bounded access to Cisco network environments for discovery, configuration review, validation and troubleshooting.

  • MCP
  • Cisco
  • network discovery
  • pyATS
  • troubleshooting

Why networks need careful integration

Networks are shared infrastructure with a large blast radius: one wrong command on a core switch can affect every user. They are also heterogeneous, with different operating systems, controllers and interfaces in the same environment. An AI agent that works with a network therefore needs access that is structured, scoped and verifiable, not a free-form terminal.

Cisco environments and their interfaces

Cisco environments expose management through several interfaces, and an MCP server is usually a thin, typed layer over one of them:

  • Device CLI over SSH, often combined with parsers that turn show-command output into structured data.
  • Model-driven interfaces such as NETCONF and RESTCONF with YANG data models.
  • Controller and cloud APIs, for example Catalyst Center, Meraki Dashboard, ACI (APIC) and ISE.
  • Test frameworks such as pyATS, which can learn device features and compare state snapshots.

MCP servers exist for several of these platforms, published by vendors and by the community. Their scope and quality vary, so each one has to be reviewed and qualified before it is used against real devices.

Network discovery

Discovery builds the AS-IS picture an agent needs before it can reason about a network. A read-only discovery sequence might be:

  1. Read the device inventory from a controller or source of truth.
  2. For each device, collect platform, software version and interface status.
  3. Collect CDP or LLDP neighbours to infer physical topology.
  4. Collect routing tables, VLANs and spanning-tree state where relevant.
  5. Assemble a structured baseline that records where each fact came from and when.

Recording the source and time of every fact matters. An agent should be able to say that it observed an interface as down at 10:42 from a given device, rather than asserting it as a permanent truth.

Working with device configurations

Configuration review is one of the most valuable read-only uses. An agent can retrieve the running configuration, compare it with an intended or standard configuration and explain the differences in plain language.

  • Mask secrets such as passwords, keys and SNMP communities before configuration text reaches a model.
  • Prefer structured, parsed data over raw text where a parser exists; it reduces misreading.
  • Compare against a defined standard, not against what the model thinks is best practice.

Structured tool access

The design of the tools decides how safe the integration is. Narrow tools with typed inputs are easier to authorise, audit and test than a generic command runner.

Narrow, read-only tool definition (illustrative)
{
  "name": "get_interface_status",
  "description": "Read interface state from one managed switch",
  "inputSchema": {
    "type": "object",
    "properties": {
      "device": { "type": "string", "description": "Inventory name" },
      "interface": { "type": "string", "pattern": "^[A-Za-z]+[0-9/.]+$" }
    },
    "required": ["device"]
  }
}
  • Separate read-only tools from tools that change state, ideally on separate servers with separate credentials.
  • Restrict which devices each tool may reach with an allowlist that the model cannot change.
  • Avoid tools that accept arbitrary commands; if one is unavoidable, constrain it to a reviewed list.

Validation and troubleshooting

For troubleshooting, an agent can follow a documented decision path using read-only tools. Consider the report that phones in one building cannot reach their gateway:

  1. Check the access ports: link state, errors and assigned voice VLAN.
  2. Check the VLAN on the uplink trunk and the spanning-tree state for that VLAN.
  3. Check the gateway interface and its ARP entries for the affected subnet.
  4. Compare with an unaffected building, and with the last known-good baseline.
  5. Report findings with the evidence for each, and propose a fix for an engineer to approve.

For changes, validation uses the same tools before and after: capture a pre-change snapshot, apply the approved change, capture a post-change snapshot and compare them against the expected result.

References