automateyournetwork/pyATS_MCP

Cisco pyATS and Genie already know how to talk to a network — parsing show commands, pushing configuration, learning feature state, running declarative tests. What they didn't have was a way for an AI agent to drive any of it directly. This server closes that gap: it wraps pyATS/Genie as a set of structured, guarded MCP tools that an agent like Claude can call against a real testbed, over the Model Context Protocol's current Streamable HTTP transport.
Point an agent at it and it can look up a device, run and parse a show command, apply configuration with a rollback point, learn and diff a feature's state before and after a change, fan a command out across a fleet — one thread pool or one process per device — run a declarative Blitz or Robot Framework test, or call a device's REST/RESTCONF API directly. Every risky path is guarded before it reaches a device, and every call lands in an in-memory audit log the agent can review mid-session.
---
At a glance
- **Transport** — Streamable HTTP (mcp>=2.3.0), stateful or stateless, chosen with one environment variable. STDIO is gone.
- **26 tools** across discovery, show commands, configuration, Genie learn/diff, Genie Clean, declarative testing (Blitz, Robot Framework, AEtest), generic REST/RESTCONF, and Cisco XPresso.
- **Two ways to fan out** a command across many devices — a shared thread pool for everyday use, or one OS process per device (pyats.async_.pcall) when you want real isolation at scale.
- **Guardrails, not honor systems** — dangerous commands are blocked before they reach a device, Genie Clean can never run a stage that reboots or reimages one, and destructive actions require an exact confirmation phrase.
- **Nothing hard-coded** — every credential and device detail lives in .env, pulled into testbed.yaml at runtime via %ENV{} substitution.
---
Prerequisites
- Python 3.10+
- A pyATS testbed.yaml pointed at real or virtual network devices — a physical lab, Cisco Modeling Labs / VIRL / GNS3, or anything else Unicon can reach over SSH/Telnet. pyATS MCP doesn't simulate a network; it drives one.
- An MCP-capable client to talk to it — see Connect Your Agent below.
---
Quick Start
The MCP endpoint is then reachable at http:// : /mcp.
---
Configuration
All device details and credentials live in a .env file — nothing is hard-coded in the repo.
1. Copy the template
2. Set the server variables
PYATS_MCP_TRANSPORT_MODE=stateless sets stateless_http=True on the Streamable HTTP transport, so no server-side session state is retained between requests from clients still negotiating the older, handshake-based protocol. Clients speaking the current MCP protocol (2026-07-28, SEP-2575) are handshake-free by default regardless of this setting — that comes from the mcp>=2.3.0 SDK itself, not anything configured here.
3. Add a block for each device
Every device in your testbed.yaml uses %ENV{VAR} substitution, so credentials and connection details are read from .env at runtime.
Use the {DEVICENAME}_{FIELD} naming convention:
If a group of devices shares credentials, define group-level vars and reference them across devices:
4. Reference the variables in testbed.yaml
> For devices with unknown OS, set os: "%ENV{DEVICE_OS}" with DEVICE_OS=generic in .env
> and optionally add learn_os: true under arguments: — Unicon will detect and cache the OS
> after the first connection.
---
Docker
Build
Run (pass .env directly)
Either way, the server is a long-running process you start once and point clients at — it isn't something an agent spawns per session. See below for exactly how each client connects to it.
---
Connect Your Agent
The server exposes one thing: an MCP endpoint at http:// : /mcp (Streamable HTTP). Every client below just needs that URL — no command/args, no local process for the client to manage.
Claude Code
Or drop it straight into .mcp.json (project-scoped, committed to the repo) or ~/.claude.json (user-scoped):
VS Code (GitHub Copilot Chat)