El protocolo MCP ejecuta como destructivos a los servidores que guardan silencio

La especificación del Protocolo de Contexto de Modelo (MCP) define un comportamiento implícito que puede bloquear la ejecución de herramientas o, peor aún, permitir operaciones no deseadas. Si un servidor no envía explícitamente la anotación destructiveHint establecida en falso, el cliente debe asumir por defecto que la herramienta es destructiva. Esto significa que el silencio de un desarrollador se traduce en una bandera roja de seguridad para el sistema que consume la API.

Eugeniya Ivanova documentó esta fricción al intentar publicar un servidor de memoria en el directorio de ChatGPT. El escáner automático rechazó la implementación porque cuatro de sus herramientas de solo lectura no declaraban explícitamente que eran seguras. La normativa exige valores concretos para readOnlyHint, openWorldHint y destructiveHint. Añadir los metadatos resolvió el bloqueo, aunque el código subyacente no varió. La solución fue administrativa, no técnica, pero necesaria para pasar los filtros de la plataforma.

Esta fricción administrativa oscurece una divergencia técnica más profunda. La especificación establece valores por defecto para cuatro campos booleanos: readOnlyHint (falso), destructiveHint (verdadero), idempotentHint (falso) y openWorldHint (verdadero). Un cliente que respete la estricta interpretación del esquema tratará cualquier herramienta sin anotaciones como peligrosa, no idempotente y capaz de acceder a recursos externos. Sin embargo, la propia documentación advierte que estas son solo "pistas" y que los clientes no deben tomar decisiones críticas basándose en ellas si el servidor no es de confianza. Esta contradicción deja dos lecturas válidas del mismo silencio: una que bloquea la ejecución por precaución y otra que la permite por falta de restricciones explícitas.

La realidad en los repositorios públicos es que la mayoría de los servidores MCP no implementan estas anotaciones. Un análisis reciente de siete proyectos destacados, incluidas bases de datos de memoria y agentes de contexto, muestra que gran parte del código fuente no declara ninguno de estos campos. Proyectos como zep, graphiti o cognee tienen cero ocurrencias de estos identificadores en sus archivos. Incluso servidores más grandes como supermemory usan plantillas prefabricadas que pueden no reflejarse en un conteo directo de literales.

El riesgo recae sobre el cliente. Si un sistema automatizado decide bloquear herramientas por defecto para protegerse de cambios destructivos, la mayoría de los servidores actuales quedarán inutilizables. Si, por el contrario, ignora la ausencia de anotaciones, expone al usuario a comportamientos indeterminados. La falta de estandarización en la implementación de estas claves convierte a las anotaciones de seguridad en una promesa vacía para la gran mayoría de las implementaciones de MCP en producción.

El contraste entre la teoría y el despliegue

La especificación contiene una advertencia explícita: las anotaciones son indicios, no garantías. Esto es fundamental cuando se integra un servidor externo en un flujo de automatización. Un desarrollador que audita su propio servidor podría encontrar herramientas sin definir, pero un cliente que interactúa con él no tiene más opción que seguir la hoja de ruta del esquema. Esa hoja de ruta penaliza la omisión.

Para que un servidor sea interoperable con clientes estrictos, es obligatorio declarar que una herramienta es de solo lectura (readOnlyHint: true) y no destructiva. Sin eso, el cliente asume lo peor. La experiencia de Ivanova y la observación de Himanshu Kumar sobre servidores que "no mintieron, simplemente callaron" ilustran que el problema no es malicioso, es estructural. La carga de la prueba recae sobre el proveedor de la herramienta, y muchos no han asumido ese coste de desarrollo.