pyATS MCP Server

Cisco pyATS y Genie ya saben cómo hablar con una red: analizar comandos show, aplicar configuración, aprender el estado de las funciones y ejecutar pruebas declarativas. Lo que no tenían era una forma de que un agente de IA pudiera manejarlos directamente. Este servidor cierra esa brecha: envuelve pyATS/Genie como un conjunto de herramientas MCP estructuradas y protegidas que un agente como Claude puede invocar contra un testbed real, a través del transporte Streamable HTTP actual del Model Context Protocol.

Apúntale un agente y podrá buscar un dispositivo, ejecutar y analizar un comando show, aplicar configuración con un punto de rollback, aprender y comparar el estado de una función antes y después de un cambio, distribuir un comando a través de una flota (un grupo de hilos o un proceso por dispositivo), ejecutar una prueba declarativa de Blitz o Robot Framework, o llamar directamente a la API REST/RESTCONF de un dispositivo. Cada ruta riesgosa está protegida antes de llegar al dispositivo, y cada llamada queda registrada en un registro de auditoría en memoria que el agente puede revisar durante la sesión.

De un vistazo

• Transporte — Streamable HTTP (mcp>=2.0.0), con o sin estado, elegido con una variable de entorno. STDIO ya no existe.

• 26 herramientas en descubrimiento, comandos show, configuración, aprendizaje/diferencias de Genie, Genie Clean, pruebas declarativas (Blitz, Robot Framework, AEtest), REST/RESTCONF genérico y Cisco XPresso.

• Dos formas de distribuir un comando entre muchos dispositivos: un grupo de hilos compartido para uso diario, o un proceso de SO por dispositivo (pyats.async_.pcall) cuando se necesita aislamiento real a escala.

• Protecciones, no sistemas de honor — los comandos peligrosos se bloquean antes de llegar al dispositivo, Genie Clean nunca puede ejecutar una etapa que reinicie o reimage un dispositivo, y las acciones destructivas requieren una frase de confirmación exacta.

• Nada codificado — cada credencial y detalle del dispositivo vive en .env, se incorpora a testbed.yaml en tiempo de ejecución mediante la sustitución %ENV{}.

Related MCP server: network-mcp

Requisitos previos

• Python 3.10+

• Un testbed.yaml de pyATS apuntando a dispositivos de red reales o virtuales: un laboratorio físico, Cisco Modeling Labs / VIRL / GNS3, o cualquier otra cosa que Unicon pueda alcanzar por SSH/Telnet. pyATS MCP no simula una red; la maneja.

• Un cliente compatible con MCP para comunicarse con él — consulte Conecte su agente a continuación.

Inicio rápido

# 1. Clone and install
git clone https://github.com/automateyournetwork/pyATS_MCP
cd pyATS_MCP
pip install -r requirements.txt

# 2. Configure your environment
cp .env.example .env
# Edit .env — see Configuration below

# 3. Run — starts a Streamable HTTP server on 0.0.0.0:8080 by default
python3 pyats_mcp_server.py

El endpoint MCP estará disponible en http://<host>:<port>/mcp.

Configuración

Todos los detalles de los dispositivos y las credenciales viven en un archivo .env — nada está codificado en el repositorio.

1. Copie la plantilla

cp .env.example .env

2. Establezca las variables del servidor

PYATS_TESTBED_PATH=/absolute/path/to/your/testbed.yaml
PYATS_MCP_ARTIFACTS_DIR=          # default: ~/.pyats-mcp/artifacts
PYATS_MCP_KEEP_ARTIFACTS=1        # 1 = keep, 0 = delete after each run
PYATS_MCP_TESTBED_CACHE_TTL=30    # seconds before testbed reloads from disk
PYATS_MCP_CONN_CACHE_TTL=0        # seconds to keep connections alive (0 = off)
PYATS_MCP_OP_LOG_MAX=500          # max entries in the in-memory operation log

# Transport (Streamable HTTP only — STDIO is not supported)
PYATS_MCP_TRANSPORT_MODE=stateful # stateful (default) | stateless
PYATS_MCP_HTTP_HOST=0.0.0.0
PYATS_MCP_HTTP_PORT=8080

# Optional — only needed for pyats_xpresso_request
XPRESSO_URL=
XPRESSO_API_TOKEN=
XPRESSO_GROUP=

PYATS_MCP_TRANSPORT_MODE=stateless establece stateless_http=True en el transporte Streamable HTTP, de modo que no se retiene estado de sesión en el servidor entre solicitudes de clientes que aún negocian el protocolo antiguo basado en handshake. Los clientes que hablan el protocolo MCP actual (2026-07-28, SEP-2575) no requieren handshake por defecto independientemente de esta configuración; eso proviene del propio SDK mcp>=2.0.0, no de nada configurado aquí.

3. Añada un bloque para cada dispositivo

Cada dispositivo en su testbed.yaml usa la sustitución %ENV{VAR}, por lo que las credenciales y los detalles de conexión se leen de .env en tiempo de ejecución.

Use la convención de nomenclatura {DEVICENAME}_{FIELD}:

# Supported os values: iosxe | iosxr | nxos | ios | eos | junos | panos | linux | windows
# Set os=generic and platform="" to let Unicon autodetect on first connect.

CORE1_IP=10.1.1.1
CORE1_PORT=22
CORE1_OS=iosxe
CORE1_PLATFORM=cat9k
CORE1_USERNAME=admin
CORE1_PASSWORD=s3cr3t
CORE1_ENABLE_PASSWORD=s3cr3t

FW1_IP=10.1.1.2
FW1_PORT=22
FW1_OS=panos
FW1_PLATFORM=
FW1_USERNAME=admin
FW1_PASSWORD=s3cr3t
# (no enable password for Palo Alto)

LINUX1_IP=10.1.1.3
LINUX1_PORT=22
LINUX1_OS=linux
LINUX1_PLATFORM=ubuntu
LINUX1_USERNAME=admin
LINUX1_PASSWORD=s3cr3t
# (no enable password for Linux)

Si un grupo de dispositivos comparte credenciales, defina variables a nivel de grupo y refiéralas en todos los dispositivos:

SITE_A_USERNAME=netops
SITE_A_PASSWORD=s3cr3t
SITE_A_ENABLE_PASSWORD=s3cr3t

4. Referencie las variables en testbed.yaml

devices:
  CORE1:
    alias: "Core Switch 1"
    type: "switch"
    os: "%ENV{CORE1_OS}"
    platform: "%ENV{CORE1_PLATFORM}"
    credentials:
      default:
        username: "%ENV{CORE1_USERNAME}"
        password: "%ENV{CORE1_PASSWORD}"
      enable:
        password: "%ENV{CORE1_ENABLE_PASSWORD}"
    connections:
      cli:
        protocol: ssh
        ip: "%ENV{CORE1_IP}"
        port: "%ENV{CORE1_PORT}"
        arguments:
          connection_timeout: 360

Para dispositivos con SO desconocido, establezca os: "%ENV{DEVICE_OS}" con DEVICE_OS=generic en .env y opcionalmente añada learn_os: true bajo arguments: — Unicon detectará y almacenará en caché el SO después de la primera conexión.

Docker

Compilar

docker build -t pyats-mcp-server .

Ejecutar (pasar .env directamente)

docker run -p 8080:8080 --rm \
  --env-file /absolute/path/to/.env \
  -v /absolute/path/to/testbed.yaml:/app/testbed.yaml \
  pyats-mcp-server

En cualquier caso, el servidor es un proceso de larga duración que se inicia una vez y al que los clientes se conectan; no es algo que un agente genere por sesión. Vea a continuación exactamente cómo se conecta cada cliente.

Conecte su agente

El servidor expone una sola cosa: un endpoint MCP en http://<host>:<port>/mcp (Streamable HTTP). Cada cliente a continuación solo necesita esa URL — sin command/args, sin proceso local que el cliente deba gestionar.

Claude Code

claude mcp add --transport http pyats http://localhost:8080/mcp

# Behind auth (e.g. a reverse proxy in front of the server)
claude mcp add --transport http pyats http://localhost:8080/mcp \
  --header "Authorization: Bearer your-token"

O colóquelo directamente en .mcp.json (a nivel de proyecto, confirmado en el repositorio) o en ~/.claude.json (a nivel de usuario):

{
  "mcpServers": {
    "pyats": { "type": "http", "url": "http://localhost:8080/mcp" }
  }
}

VS Code (GitHub Copilot Chat)

Añada un .vscode/mcp.json en el espacio de trabajo (o ejecute MCP: Add Server desde la Paleta de Comandos):

{
  "servers": {
    "pyats": { "type": "http", "url": "http://localhost:8080/mcp" }
  }
}

OpenAI Codex CLI

codex mcp add pyats --url http://localhost:8080/mcp

O en ~/.codex/config.toml:

[mcp_servers.pyats]
url = "http://localhost:8080/mcp"

Claude Desktop

El claude_desktop_config.json de Claude Desktop es solo stdio — poner un campo url no funciona (es un problema conocido, no una ruta compatible). Los servidores remotos/HTTP se añaden en su lugar como Custom Connector en Configuración → Conectores, y Desktop se conecta desde la nube de Anthropic, no desde su máquina local — por lo que necesita una URL HTTPS real y accesible públicamente, no localhost.

Para apuntar Desktop a un servidor que se ejecuta en su propia máquina de todos modos, conéctelo a través de mcp-remote como un proxy stdio local:

{
  "mcpServers": {
    "pyats": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:8080/mcp", "--transport", "http-only"]
    }
  }
}

Python puro (LangGraph, agentes personalizados, cualquier otra cosa)

from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client

async def main():
    async with streamablehttp_client("http://localhost:8080/mcp") as (read, write, _session_id):
        async with ClientSession(read, write) as session:
            await session.initialize()
            tools = await session.list_tools()
            result = await session.call_tool(
                "pyats_run_show_command",
                arguments={"device_name": "CORE1", "command": "show version"},
            )

Qué pedirle

Una vez conectado, hable con él como hablaría con alguien que ya conoce la red:

• "¿Qué dispositivos hay en el testbed?" → pyats_list_devices

• "Muéstrame el resumen de BGP en CORE1" → pyats_run_show_command, analizado en JSON estructurado

• "Captura el estado de OSPF de CORE1, luego aplica esta configuración y muéstrame qué cambió" → pyats_learn_feature (antes) → pyats_configure_with_diff → pyats_learn_feature (después) → pyats_diff_learned_snapshots

• "Ejecuta show ip interface brief en todos los switches" → pyats_run_show_command_multi (o pyats_pcall_show_command para aislamiento por proceso a escala real)

• "Si ese cambio de configuración rompe algo, reviértelo" → pyats_rollback_config

• "Ejecuta esta prueba Blitz contra R1 y R2" / "Ejecuta esta suite de Robot Framework" → pyats_run_blitz / pyats_run_robot

El agente encadena estas acciones por sí mismo — usted describe el resultado, él elige las herramientas.

Herramientas disponibles

26 herramientas, agrupadas por lo que hacen.

Descubrimiento

Comandos show

Configuración

Estado y diagnóstico

Pruebas y automatización

APIs

Sesión

Seguridad

• Los comandos show se validan: se bloquean tuberías, redirecciones y palabras clave peligrosas.

• Los cambios de configuración se verifican para reload, erase, write erase, delete, format; la misma verificación se ejecuta dentro de pyats_clean_device, pyats_run_blitz y pyats_run_robot.

• Los scripts de prueba dinámicos se ejecutan en un sandbox restringido (importaciones prohibidas: os, sys, subprocess, etc.).

• pyats_clean_device nunca ejecuta una etapa real de Genie Clean que reinicie, borre o reinstale la imagen de un dispositivo; solo se generan connect+execute_command, y el valor predeterminado es dry_run=True; ejecutarlo de verdad también requiere una frase de confirmación exacta.

• Cada caché global del proceso (caché de conexiones, caché de testbed, instantáneas de configuración/aprendizaje, registro de operaciones) está protegida por un bloqueo, de modo que los clientes HTTP concurrentes no pueden corromper el estado compartido.

• Todas las credenciales provienen de .env; nunca se almacenan en el archivo de testbed ni en el código fuente.

Estructura del Proyecto

.
├── pyats_mcp_server.py      # MCP server
├── test_pyats_mcp_server.py # Unit tests (119 tests)
├── benchmark/               # Pre/post, stateful/stateless transport benchmark
├── Dockerfile               # Container definition
├── requirements.txt         # Pinned runtime dependencies
├── requirements-dev.txt     # Dev/test dependencies
├── pyproject.toml           # Tool config (black, isort, pytest, mypy)
├── .env.example             # Configuration template — copy to .env
├── .gitignore
├── LICENSE
└── CONTRIBUTING.md

Desarrollo

# Install dev dependencies with uv
uv venv .venv && uv pip install -r requirements-dev.txt

# Run tests
.venv/bin/python -m pytest

# Lint and format
.venv/bin/black .
.venv/bin/isort .
.venv/bin/flake8 . --max-line-length=100

Consulta CONTRIBUTING.md para la configuración completa y el flujo de trabajo de PR.

Benchmark

benchmark/ compara STDIO (heredado) con Streamable HTTP en modo con estado y sin estado, contra un testbed real. Consulta benchmark/scenarios.py para la lista de escenarios y benchmark/aggregate.py para generar el informe de comparación; benchmark/results/summary.md contiene los números de la ejecución más reciente.

Licencia

MIT