Servidores MCP seguros por defecto para Kubernetes, Kafka y operaciones en la nube

Dejar que un agente de IA toque la infraestructura de producción es una forma fácil de avanzar rápido. También es una forma fácil de perder una base de datos porque un prompt era un poco vago. El Model Context Protocol (MCP) hace trivial darle a un agente herramientas como "listar los pods", "reiniciar el deployment" y "ejecutar esta consulta". Pero en infraestructura, el mismo mecanismo puede entregar con la misma facilidad delete_topic, DROP TABLE o delete_resource_group. El consejo habitual es dejar fuera las herramientas peligrosas, pero entonces el servidor deja de ser útil justo cuando necesitas esas operaciones.

Una respuesta es una familia de ocho servidores MCP construidos en torno a un único principio. Cada uno es seguro por defecto, y su poder lo amplías de forma deliberada. Así funciona el diseño y esto es lo que cubre el conjunto.

El motor de políticas

Los ocho servidores comparten un motor de políticas que se apoya en cuatro ideas.

Modos de acceso por capas. Un servidor arranca en modo de solo lectura. Pasar a lectura y escritura, y después a administración, exige cambiar a propósito una variable de entorno. El detalle clave es que las herramientas por encima del modo actual ni siquiera se registran. En modo de solo lectura, el agente no ve una herramienta de borrado que educadamente decide no llamar. La herramienta simplemente no está en su lista, y no se puede abusar de algo que no existe.

Listas de permitidos y recursos protegidos. Un servidor puede limitarse a namespaces, topics, bases de datos, proyectos o suscripciones concretos. Además, ciertos recursos pueden marcarse como protegidos, como el namespace kube-system, un topic interno de Kafka o el realm master de Keycloak. Los recursos protegidos siguen siendo legibles, pero nunca se pueden modificar, ni siquiera en modo de administración.

Acciones destructivas tras un segundo interruptor. Los borrados y otras operaciones irreversibles requieren el modo de administración y además una activación aparte, por ejemplo KAFKA_ALLOW_DELETE=true. Una instalación nueva no puede destruir nada, ni siquiera en el modo más alto, hasta que lo hayas confirmado dos veces.

Un rastro de auditoría visible. Cada acción emite una línea JSON estructurada en stderr con los secretos ocultos, así que después es fácil ver qué hizo el agente.

Lo que obtienes es un regulador y no un interruptor. La confianza se entrega en pasos que tú controlas, en lugar de elegir entre un servidor inútil y uno que da miedo.

Un modelo de seguridad que entienden las máquinas

Hasta la versión 0.1.1, el modelo de seguridad vivía solo en el README. Las personas podían leerlo, pero la aplicación que aloja al agente (Claude Desktop, Cursor, Copilot) no.

MCP ya tiene una función para esto: las anotaciones de herramientas. Una herramienta puede anunciar pistas estructuradas, en concreto readOnlyHint, destructiveHint, idempotentHint y openWorldHint, que el host usa para decidir qué aprobar automáticamente y dónde detenerse a preguntar.

Ahora esas pistas están definidas en todas las herramientas de los ocho servidores y se derivan automáticamente del nivel de acceso de cada herramienta. Una herramienta de lectura se declara de solo lectura y no destructiva. Una herramienta de borrado se declara destructiva. Así el host puede valorar el alcance del daño de una herramienta antes de ejecutarla, con metadatos estructurados en lugar de analizar una descripción en inglés y esperar lo mejor. Un test comprueba que cada pista coincide con la herramienta que describe. Es la diferencia entre "confía en nosotros, es seguro" y una afirmación que una máquina puede verificar.

Los ocho servidores

Todos los servidores tienen licencia MIT, están escritos en TypeScript y se instalan con un solo comando npx.

• mcp-kubernetes cubre pods, logs, deployments, escalado y reinicios, apply y exec.
• mcp-kafka gestiona topics, grupos de consumidores y lag, además de operaciones de creación, modificación y reinicio.
• mcp-clickhouse expone esquemas y consultas, y clasifica el SQL como lectura, escritura o destructivo para controlar cada sentencia.
• mcp-debezium administra conectores de captura de cambios de datos, incluidos su estado, configuración y ciclo de vida.
• mcp-oci descubre recursos de Oracle Cloud y genera Terraform.
• mcp-azure trabaja con Azure Resource Manager para inventario, etiquetas, estado de encendido de las VM y ciclo de vida.
• mcp-azure-devops accede a tableros, repositorios, pipelines y proyectos.
• mcp-keycloak cubre realms, usuarios, clientes, roles y grupos.

Probar uno

Añadir un servidor a Claude Code lleva una sola línea, y arranca en modo de solo lectura:

claude mcp add kubernetes -e K8S_MODE=read-only -- npx -y @dockndevai/mcp-kubernetes

Cada repositorio documenta la configuración para Claude, Cursor, Codex, VS Code y Windsurf. El código fuente está en GitHub y los paquetes están publicados en npm.

La pregunta abierta

Una decisión de diseño invita al debate: exigir tanto el modo de administración como un flag de activación por operación antes de que se ejecute una acción destructiva. ¿Es demasiado estricto para el trabajo real, o es justo el valor por defecto adecuado cuando la infraestructura pasa a manos de un agente? Los equipos llegan a conclusiones distintas, desde solo lectura para siempre hasta una confianza gradual que crece a medida que aumenta la seguridad. Sea cual sea la postura que encaje, el núcleo del diseño se sostiene: haz que el comportamiento más seguro sea el predeterminado y exige pasos claros y deliberados para relajarlo.