Cisco pyATS и Genie уже знают, как разговаривать с сетью — анализируют команды шоу, продвигают конфигурацию, состояние функции обучения, запускают декларативные тесты. То, чего у них не было, было способом для агента ИИ управлять любым из них напрямую. Этот сервер закрывает этот пробел: он обертывает pyATS/Genie как набор структурированных, защищенных инструментов MCP, которые агент, такой как Клод, может вызвать против реального испытательного стенда, по текущему потоковому HTTP-транспорту протокола Model Context.

Направьте на него агента, и он может искать устройство, запускать и анализировать показную команду, применять конфигурацию с точкой отката, изучать и дифференцировать состояние функции до и после изменения, вентилировать команду через флот - один пул потоков или один процесс на устройство - запустить декларативный тест Blitz или Robot Framework или напрямую вызвать API REST / RESTCONF устройства. Каждый рискованный путь охраняется до того, как он достигнет устройства, и каждый звонок попадает в журнал аудита в памяти, который агент может просмотреть в середине сессии.

С первого взгляда

Transport — потоковый HTTP (mcp>=2.3.0), государственный или апатридный, выбранный с одной переменной среды. Стдио больше нет.

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+