RoSGrid: un servidor MCP para operar routers MikroTik con agentes de IA

RoSGrid es un proyecto open source que junta dos cosas: una consola web multi-tenant para administrar flotas de routers MikroTik con RouterOS v7, y un servidor MCP con 22 tools para que un agente como Claude Code o Cursor opere esa flota. Desde la versión 1.1.0, las seis tools que cambian algo en los routers no tocan nada: dejan una solicitud que un humano tiene que aprobar. La 1.0.0 salió sin ese freno en cinco de las seis, y lo corrigieron en menos de un día.

No lo instalé contra routers: leí la web, la documentación del repo y el código Python del servidor MCP en la 1.0.0 y en la 1.1.1. Me interesó porque es de los pocos servidores MCP que tocan infraestructura de red real, donde un agente que se equivoca deja a un barrio sin internet.

Qué es RoSGrid

RoSGrid es una plataforma web para que ISP, operadores de telecomunicaciones, centros de monitoreo (NOC) y equipos de infraestructura administren muchos MikroTik desde un solo lugar. Su README lo describe como el traslado de "la experiencia operativa y técnica de WinBox / WebFig" a un entorno web centralizado, con 11 roles de acceso, backups con diff estilo Git y una bitácora de auditoría inmutable.

Los datos del proyecto:

Es un proyecto recién salido, con un puñado de estrellas en GitHub y mucha documentación: el README habla de 106 especificaciones de arquitectura en docs/specs/ y hay un AGENTS.md con reglas para agentes de código.

Cómo se conecta RoSGrid a los MikroTik

RoSGrid habla con los routers solo por la REST API de RouterOS sobre HTTPS (/rest/*, puerto 443). La versión larga de su documentación para LLMs prohíbe explícitamente SSH (22), Telnet (23), FTP (21), HTTP (80) y la API binaria (8728/8729).

La consola tampoco ofrece una terminal. El README le dedica una sección a explicar por qué: una CLI libre dejaría a un técnico saltarse la aprobación de cambios y borrar las tareas de reversión del Safe Mode, y lo que hiciera ahí no quedaría auditado como un cambio estructurado. Es una decisión que comparto: si quieres auditar cada cambio, el canal tiene que ser estructurado.

Al registrar un router, RoSGrid guarda la huella SHA-256 de su certificado TLS en la primera conexión y bloquea cualquier cambio posterior (pinning TOFU). Así acepta los certificados autofirmados de RouterOS sin quedar expuesto después a un man-in-the-middle.

Para los cambios delicados usa un Safe Mode de 60 segundos: antes de aplicar el cambio, crea en el propio MikroTik un scheduler de reversión. Si el cambio deja al router incomunicado, el router revierte solo.

La versión mínima es RouterOS v7.13. En la 1.1.0 unificaron ese requisito en el README, los manuales y la web, que antes daban cifras distintas.

Instalar RoSGrid con Docker

RoSGrid se instala con Docker Compose en un servidor Linux. El README pide Ubuntu 24.04/26.04 LTS o Debian 12+, Docker Engine 24.0+, Docker Compose v2.20+, 2 vCPU y 4 GB de RAM.

La opción que recomienda es un curl | bash:

curl -fsSL https://raw.githubusercontent.com/tecno-consultores/RoSGrid/main/scripts/instalar-rosgrid.sh | bash

El script crea /opt/rosgrid, descarga docker-compose.prod.yml, genera un .env con secretos aleatorios, baja las imágenes de Docker Hub y levanta los contenedores. Para un servidor que va a guardar las credenciales de toda tu red, yo prefiero la opción B, que hace lo mismo pero te deja leer el script antes:

git clone https://github.com/tecno-consultores/RoSGrid.git
cd RoSGrid
./scripts/instalar-rosgrid.sh

Después abres http://<IP_DE_TU_SERVIDOR>:8080 y un asistente te pide el nombre de la organización, la cuenta de superadmin y el 2FA TOTP, que es obligatorio.

Preparar el MikroTik para RoSGrid

Cada router necesita un certificado TLS, el servicio www-ssl activo en el 443 y un usuario dedicado para la API. El README y la guía de preparación de RouterOS traen el bloque completo de comandos. El grupo de permisos que proponen es este:

/user group add name="rosgrid-api-group" policy=api,rest-api,read,write,ftp,test,reboot,policy,sensitive comment="Acceso REST para RoSGrid"

Ese grupo es más amplio que el que declara la propia web. El llms-full.txt pide read,write,api,rest-api,test,sensitive, sin ftp, reboot ni policy, y la misma web lista FTP entre los protocolos prohibidos. Empieza por la lista corta y agrega permisos solo si una función concreta falla por falta de ellos.

El servidor MCP de RoSGrid

El servidor MCP de RoSGrid expone 22 tools en POST /api/v1/mcp, todas con prefijo rosgrid_. El llms-full.txt las agrupa en tres niveles:

Las protecciones de acceso se ven en el código del endpoint:

• Viene apagado: en el .env.example, ROSGRID_MCP_ENABLED=false, y con eso el endpoint responde 404.
• Solo entran tokens del rol SERVICE_ACCOUNT. Cualquier otro rol, incluido el superadmin, recibe 403.
• Cada cuenta de servicio necesita una lista blanca de redes (allowed_cidr_list). Si la lista está vacía, o la petición llega desde otra red, la respuesta es 403.
• Cada agente tiene un límite de 30 peticiones por minuto (ROSGRID_MCP_RATE_LIMIT_PER_MIN=30).
• Según la guía de integración MCP, el agente pide acciones por router_id y el backend resuelve las credenciales, así que ninguna tool devuelve contraseñas.
• Cada llamada queda en la auditoría como MCP_AI_TOOL_CALL.

Conectar RoSGrid a Claude Code

Para conectar RoSGrid a Claude Code necesitas un token de una cuenta SERVICE_ACCOUNT. La guía de integración da dos caminos: el botón "Token MCP" en la consola web, o este script dentro del contenedor de la API:

docker exec -it rosgrid_api python3 /app/scripts/generar_token_mcp.py --username <NOMBRE_SERVICE_ACCOUNT> --expiry-days 365

Con el token, se agrega como servidor MCP remoto por HTTP con la cabecera de autenticación, en el formato que documenta la guía de MCP de Claude Code:

claude mcp add --transport http rosgrid-mcp https://noc.tu-dominio.com/api/v1/mcp \
  --header "Authorization: Bearer <TOKEN>"

Tu IP tiene que estar en la lista CIDR de esa cuenta de servicio, o el servidor responde 403 antes de llegar a cualquier tool.

Cómo pasan por aprobación humana las tools de RoSGrid

Las seis tools del nivel 3 son las únicas que cambian algo en los routers, y en la 1.1.1 ninguna ejecuta el cambio cuando el agente la llama. Cada handler de mcp.py crea una solicitud PENDING en approval_requests, que vence en 24 horas, publica el evento para los aprobadores y le devuelve al agente status: "AWAITING_APPROVAL" con el id de la solicitud.

El cambio se ejecuta cuando alguien lo aprueba. El endpoint de aprobación acepta cuatro roles (SUPERADMIN_GLOBAL, TENANT_ADMIN, SUPERVISOR y SUPPORT_L3) y rechaza que quien pidió el cambio lo apruebe, salvo el superadmin. Como una cuenta de servicio no está entre esos roles, el agente no puede aprobar lo que él mismo propuso.

Al aprobar, approvals.py ejecuta la acción guardada: el aislamiento, la restauración, el cambio de perfil de ancho de banda o la actualización por etapas. La reconexión PPPoE y los cambios propuestos con rosgrid_propose_network_change van por la rutina genérica que aplica el cambio REST con Safe Mode.

Lo que traía la 1.0.0

En el tag 1.0.0, solo rosgrid_propose_network_change creaba una solicitud. Las otras cinco ejecutaban la acción en el router apenas el agente las llamaba, aunque la web ya las presentaba bajo "Maker-Checker HTTP 202 + Safe Mode 60s". El endpoint aceptaba además tokens de TENANT_ADMIN y SUPERADMIN_GLOBAL, no solo de cuentas de servicio.

El CHANGELOG de la 1.1.0 lo registra como "Gobernanza Maker-Checker Obligatoria en las 6 Herramientas MCP de Mutación". Si instalaste la 1.0.0, actualiza antes de darle un token a un agente.

Dos detalles del flujo de aprobación

La guía y la web hablan de una respuesta HTTP 202. El endpoint MCP no la usa: devuelve el resultado JSON-RPC normal, con AWAITING_APPROVAL dentro. Para un agente da igual, pero si escribes un cliente propio, mira el contenido y no el código de estado.

El segundo detalle importa más: aprobar no pide un segundo código. El campo totp_code del payload de aprobación es opcional, el endpoint lo valida solo si viene, y la bandeja de aprobaciones de la consola no lo pide. El 2FA del login sí es obligatorio, así que quien aprueba entró con 2FA, pero una sesión abierta y desatendida de un supervisor alcanza para aprobar lo que proponga el agente.

La lección: en un servidor MCP que toca infraestructura, lee el handler de cada tool antes de creerle a la tabla de garantías del README, y vuelve a leerlo en cada versión.

La telemetría de RoSGrid es opt-in

RoSGrid trae un beacon que avisa a rosgrid.net que la instalación está viva, y desde la 1.1.0 viene apagado. En el .env.example está ROSGRID_TELEMETRY_BEACON_ENABLED=false, con la URL https://rosgrid.net/api/telemetry/heartbeat y un intervalo de 21.600 segundos, o sea cada seis horas. En la 1.0.0 venía en true.

Si lo activas, lo que manda está en el worker del beacon: schema_version, un instance_id, la versión, un fleet_bucket y la hora. El fleet_bucket es un rango del tamaño de tu flota (1-10, 11-50, 51-250 o 250+), no el número exacto. No viaja ninguna IP de router ni nombre de cliente.

El patrón: la documentación iba por delante del código

En la 1.0.0, todas las diferencias entre documentación y código iban para el mismo lado: la documentación describía un sistema más estricto que el que estaba en el repo. Más tools bajo aprobación, menos roles con acceso al MCP, menos permisos en el router.

No me parece mala fe. Es lo que pasa en un proyecto que escribe especificaciones antes que código, con más de cien specs y reglas para agentes, en menos de un mes: la promesa se escribe una vez, se copia a la web, el README y el llms.txt, y el código avanza a su ritmo. La 1.1.0 cerró la brecha en lo importante. Quedan el grupo de permisos del router, que la web declara más corto que el README, y el 202 que el endpoint no devuelve.

Cuándo probar RoSGrid

La consola tiene sentido si administras muchos MikroTik y hoy vives entre WinBox, scripts y planillas: el inventario, los backups con diff, el Safe Mode y la auditoría son útiles sin tocar el MCP. Pruébala en laboratorio primero; el docker-compose.yml del repo viene pensado para un entorno local o un laboratorio EVE-NG.

Con el servidor MCP, usa la 1.1.1 o posterior, nunca la 1.0.0. Dale al agente una cuenta de servicio en un tenant de laboratorio, con su CIDR acotado, y no dejes sesiones de supervisor abiertas en equipos compartidos del NOC, porque aprobar no pide un segundo código. Las 16 tools de los niveles 1 y 2 solo leen, así que son la parte que puedes usar desde el primer día sin que el agente proponga cambios.

Si te interesa cómo funciona un servidor MCP por dentro, tienes MCP por dentro; para lo que puede salir mal con uno, servidores MCP maliciosos; y para conectarlos a tu editor, cómo conectar un MCP a Cursor y Claude.

Preguntas frecuentes

Fuentes

• tecno-consultores/RoSGrid (repositorio, licencia GPL-3.0)
• Releases de RoSGrid (1.0.0, 1.1.0 y 1.1.1)
• README.md de RoSGrid 1.1.1 (stack, requisitos, instalación, preparación del MikroTik y roles)
• CHANGELOG.md de RoSGrid 1.1.1 (cambios de la 1.1.0 en MCP, CIS y telemetría)
• fastapi/src/api/v1/mcp.py (handlers de las tools MCP, rol permitido, CIDR y dispatcher)
• fastapi/src/api/v1/approvals.py (roles aprobadores, segregación de funciones y ejecución diferida)
• fastapi/src/workers/telemetry_beacon_worker.py (contenido del beacon de telemetría)
• .env.example (MCP y telemetría por defecto)
• Guía de integración IA, MCP, Hermes y Claude (token de servicio, CIDR y rate limit)
• Preparación de MikroTik RouterOS v7 (grupo de permisos del usuario de la API)
• RoSGrid llms-full.txt (niveles de tools, protocolos prohibidos, permisos y versión mínima según la web)
• Connect Claude Code to tools via MCP (sintaxis de claude mcp add con cabecera de autenticación)