PyATS MCP

What automateyournetwork/pyATS_MCP MCP server does

The automateyournetwork/pyATS_MCP MCP server gives an MCP client structured access to Cisco pyATS and Genie workflows. It can discover devices from a testbed, search by device name or alias, execute validated show commands, retrieve running configuration and logs, check device health, inspect CDP or LLDP neighbors, and identify the interface associated with an IP address.

The server also supports operational changes and testing. Agents can apply configuration to one or more devices, request a before-and-after diff, roll back to the most recent saved configuration snapshot, and run pings from network devices. Testing options include declarative pyATS Blitz YAML, Robot Framework suites using pyATS/Genie libraries, and sandboxed pyATS AEtest scripts.

How it works

A running Python process exposes the MCP endpoint at /mcp using Streamable HTTP. The default listener is 0.0.0.0:8080, with host, port, and statefulness controlled through environment variables. The server reads a pyATS testbed.yaml; device fields in that file can reference environment variables using %ENV{} substitution.

The automateyournetwork/pyATS_MCP MCP server can fan commands or configuration changes across multiple devices using either a shared thread pool or one operating-system process per device through pyATS pcall. Genie feature learning can save named snapshots, which can later be compared for changes in interface, OSPF, BGP, or other supported feature state. REST, RESTCONF, and NX-API requests use pyATS's REST connector, while XPresso requests target Cisco XPresso REST API v2.

Each call is recorded in an in-memory operation log that an agent can retrieve. Configuration actions include safety controls, and destructive operations require an exact confirmation phrase. Genie Clean is limited to non-destructive connect and execute_command stages and defaults to dry-run mode.

Setup and configuration

The project requires Python 3.10 or newer, a reachable pyATS testbed, and an MCP-capable client. Install the repository requirements, copy .env.example to .env, populate the server settings and device credentials, then start python3 pyats_mcp_server.py. The testbed may point to physical devices or environments such as Cisco Modeling Labs, VIRL, or GNS3, provided Unicon can reach them over SSH or Telnet.

PYATS_TESTBED_PATH identifies the testbed file. Other settings control artifact retention, testbed and connection cache lifetimes, operation-log size, HTTP transport mode, and the listening address. XPresso URL, token, and group variables are only needed for the XPresso request tool. Docker is also supported by building the included image, passing the environment file, and mounting the testbed file.

Tools and capabilities

The tool set covers:

• Device listing and fuzzy search.
• Parsed or raw show-command execution, including concurrent multi-device variants.
• Running configuration, logging, health, neighbor, ping, and interface lookups.
• Single-device and multi-device configuration with rollback and diff support.
• Genie feature learning and comparison of saved snapshots.
• Restricted Genie Clean operations.
• Blitz, Robot Framework, and dynamic AEtest execution.
• Generic REST requests, Cisco XPresso API calls, and operation-log retrieval.

Limitations and notes

The automateyournetwork/pyATS_MCP MCP server does not simulate a network; it operates against devices or hosts reachable through the configured testbed. STDIO transport is not supported by the project itself. Claude Desktop therefore needs an HTTPS custom connector for a publicly reachable deployment, or a local mcp-remote bridge; its desktop configuration cannot directly start this server through a URL.

Network credentials and device details must be supplied by the operator. The material does not describe built-in server authentication, so deployments exposed beyond a trusted environment should account for access control separately, such as with a reverse proxy.