cisco-iosxe-mcp

Un servidor MCP que expone dispositivos Cisco IOS-XE como herramientas que un cliente LLM puede invocar. Lecturas operativas con nombre, más una ruta de cambio de configuración que muestra la lista exacta de comandos, los aplica bajo configure terminal revert timer, verifica que el dispositivo aún responda en una sesión nueva, y solo entonces confirma.

Habla MCP sobre HTTP Streamable, por lo que se ejecuta como su propio servicio en la red en lugar de como un subproceso local de un solo cliente. El transporte al dispositivo es la CLI de IOS-XE sobre SSH, a través de scrapli.

Construido para universal-network-director, un gestor de red multi-fabricante impulsado por chat con una puerta de aprobación humana en cada escritura, pero es un servidor MCP independiente y funciona con cualquier cliente MCP.

No afiliado, respaldado ni soportado por Cisco Systems, Inc. "Cisco" e "IOS-XE" son marcas comerciales de sus respectivos propietarios y se utilizan aquí solo para describir con qué se comunica este software.

El modelo de seguridad

Dos pasos, con la misma forma que la ruta de Junos, con una diferencia honesta que debes entender antes de usarlo.

Paso 1 — la vista previa muestra la lista de comandos, no un diff

preview_config_change devuelve los comandos exactos que se enviarían, el dispositivo al que irían y el estado actual de las líneas que tocan. Apruebas eso.

Esto es más débil que un show | compare de Junos. Junos carga una configuración candidata y el dispositivo calcula el diff real; IOS-XE no tiene configuración candidata, por lo que no hay nada que pedirle al dispositivo que compare. La vista previa aquí es el cambio tal como está escrito, verificado contra lo que está configurado actualmente, no el propio recuento del dispositivo de cuál sería el resultado. Lee los comandos, no solo el resumen.

Paso 2 — aplicar bajo un temporizador de reversión

write_apply_config_block solo toma un id de vista previa — no puede aplicar nada que no haya sido previsualizado. Los comandos se introducen bajo configure terminal revert timer <n>: entran en vigor de inmediato, pero IOS-XE revierte la configuración automáticamente a menos que llegue un configure confirm a tiempo. Este servidor entonces se reconecta en una nueva sesión SSH para demostrar que el dispositivo sigue siendo accesible, y confirma solo si lo es. Si te bloqueas, el equipo deshace el cambio.

Requisito previo del dispositivo que Junos no tiene: la función archive de IOS debe estar configurada (archive / path ...) o el temporizador de reversión no tiene punto de restauración y la red de seguridad simplemente no está ahí. get_archive_status informa de esto por dispositivo, y write_apply_config_block se niega cuando falta en lugar de aplicar sin protección.

Deliberadamente no hay una herramienta de comandos de forma libre. Cada lectura operativa ejecuta un comando construido a partir de una plantilla fija más argumentos validados. El único lugar donde el modelo compone texto libremente — un bloque de configuración — está controlado, se muestra a un humano textualmente y se aplica bajo el temporizador de reversión.

Related MCP server: Itential MCP Server

Lee esto antes de apuntarlo a producción

Tres de las diecinueve herramientas cambian el estado, y este servidor no pregunta antes de ejecutarlas. El prefijo write_ es una convención para que tu cliente pueda controlarlas.

Nota la asimetría que codifica el prefijo: write_ significa "un humano debe aprobar esto", no "esto edita la configuración". write_save_config no añade configuración en absoluto, y está controlado porque hacer un cambio permanente es una decisión que alguien debe tomar deliberadamente.

cancel_reload no está controlado a propósito — es una acción de recuperación, y requerir un viaje de ida y vuelta de aprobación para detener un reinicio pendiente es la compensación incorrecta.

Limita la cuenta del dispositivo a solo lectura a menos que tengas la intención específica de que las escrituras funcionen. Ese control reside en el dispositivo, no en este código.

El endpoint MCP no tiene autenticación

Este servidor expone sus herramientas a cualquiera que pueda alcanzar su puerto. No hay token, autenticación de cliente ni TLS en el lado MCP.

MCP_HOST por defecto es 127.0.0.1 por esa razón. La imagen del contenedor establece 0.0.0.0 porque tiene que hacerlo, lo que significa que publicar el puerto del contenedor coloca una ruta no autenticada a tus routers en esa interfaz. Mantenlo en una red interna con el cliente, o termina TLS y autenticación delante de él.

Inventario de dispositivos

Las credenciales de los dispositivos residen en un archivo JSON montado como solo lectura dentro del contenedor — nunca incrustado en la imagen, nunca comprometido. Contiene credenciales SSH en texto plano, así que ponle chmod 600 y propietario como el uid bajo el que se ejecuta el contenedor.

Misma forma que el inventario de la puerta de enlace de Junos, por lo que solo hay un formato que aprender, más una enable_password opcional:

{
  "csr-lab": {
    "ip": "192.0.2.53",
    "port": 22,
    "username": "automation",
    "auth": { "type": "password", "password": "..." }
  }
}

enable_password se lee solo si un dispositivo realmente lo necesita — una cuenta que ya está en privilegio 15 llega a # y no necesita escalada secundaria.

Usa un archivo diferente al de la puerta de enlace de Junos. Contenedores separados que contienen credenciales separadas es la razón por la que los servidores están divididos: un error en este no puede alcanzar tus cortafuegos.

Uid del contenedor. La imagen crea deliberadamente una entrada passwd para uid-1000. El transporte system de scrapli ejecuta el binario ssh, y OpenSSH se niega a ejecutarse cuando el uid que llama no tiene una entrada en /etc/passwd — el síntoma es un engañoso "EOF reading from transport" en lugar de algo que nombre la causa.

Ejecutarlo

docker build -t cisco-iosxe-mcp .
docker run --rm \
  -v "$PWD/secrets/devices.json:/app/config/devices.json:ro" \
  --user 1000:1000 \
  -p 127.0.0.1:8004:8004 \
  cisco-iosxe-mcp

Pruebas

docker run --rm cisco-iosxe-mcp python test_arg_validation.py
docker run --rm cisco-iosxe-mcp python test_reload.py

Ambas son offline — sin contacto con el dispositivo, sin necesidad de credenciales. test_reload.py reproduce los bytes exactos que un equipo IOS-XE real envió para reload in 5, reload cancel y los mensajes de confirmación, incluido el caso en el que el mensaje de guardado nunca aparece.

Referencia de herramientas

TOOLS.md tiene la referencia herramienta por herramienta: argumentos, qué devuelve cada una, cuáles necesitan aprobación y el razonamiento detrás del diseño de la puerta de control.

Licencia

Apache-2.0. Ver LICENSE.