Cisco pyATS 和 Genie 已经知道如何与网络通信——解析显示命令、推送配置、学习功能状态、运行声明式测试。但他们没有让 AI 代理直接驱动这些功能。这台服务器弥补了这一空白：它将 pyATS/Genie 包裹为一组结构化、受保护的 MCP 工具，代理如 Claude 可以在实际测试平台调用，而非基于模型上下文协议当前的可流式 HTTP 传输。

指向该设备，它可以查找设备，运行并解析显示命令，应用带回滚点的配置，学习并差异功能变更前后状态，向整个舰队发送命令——一个线程池或一个设备一个进程——运行声明式闪电战或机器人框架测试，或直接调用设备的REST/RESTCONF API。每条风险路径在到达设备之前都会被保护，每次呼叫都会进入内存审计日志，代理可在会话中途查看。

---

一览

• Transport — 可流式 HTTP （[mcp>=2.3.0），有状态或无状态，选择一个环境变量。STDIO 已消失。

pyATS MCP Server

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.

---

[!TIP]

Testbed-free: build testbeds dynamically, in memory

You don’t need a testbed.yaml. The pyats_testbed_* tools build a pyATS testbed on the fly from Itential Inventory Manager (the default source), NetBox, Nautobot, Catalyst Center, any JSON REST API, or inline/file CSV, JSON, YAML and XML, using a declarative field mapping. The testbed lives in server memory, is activated with one call, and every existing tool (pyats_run_show_command, pyats_configure_device, …) uses it immediately. Start the server with PYATS_MCP_DYNAMIC_ONLY=1 and no YAML at all. Credentials stay on the server as %ENV{} references and never pass through the model. See Dynamic Testbeds and the technical write-up.

---

At a glance

• Transport — Streamable HTTP (mcp>=2.3.0), stateful or stateless, chosen with one environment variable. STDIO is gone.
• 34 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+