Un runtime abierto: herramientas tipadas, permisos acotados y una persona en el camino de escritura

Si vas a integrar una herramienta en un runtime de agentes, la pregunta interesante no es qué te deja mandar el protocolo. Es qué promete hacer el runtime del otro lado antes de ejecutar lo que mandaste.

1. Qué estandariza MCP

El Model Context Protocol es «an open protocol that enables seamless integration between LLM applications and external data sources and tools». Va sobre JSON-RPC 2.0 y nombra tres papeles: hosts (la aplicación), clients (los conectores que lleva dentro) y servers (lo que aporta la capacidad).

Un servidor ofrece tres clases de cosa, y la distinción importa al diseñar una integración:

• Recursos — contexto y datos, para que los lea el usuario o el modelo.
• Prompts — mensajes y flujos con plantilla, ofrecidos al usuario.
• Herramientas — funciones que el modelo puede ejecutar.

El valor de eso es el de cualquier protocolo: una integración escrita una vez sirve contra todo lo que lo hable. Ya solo por eso merece adoptarse.

2. Qué dice explícitamente que NO hace

Esta es la parte que merece leerse dos veces, y la especificación es admirablemente directa. Sobre seguridad dice que quien lo implementa debe obtener consentimiento explícito antes de invocar cualquier herramienta, que una herramienta es ejecución de código arbitrario, y que la descripción que la propia herramienta da de sí misma «should be considered untrusted, unless obtained from a trusted server».

3. Contratos tipados: qué tiene que declarar una herramienta

Una herramienta que acepta entrada libre es una herramienta sobre la que no puedes razonar. El contrato tiene que decir cuatro cosas antes de que la llamada merezca la pena:

1. Qué recibe, con tipos y restricciones, no solo nombres. Un campo tipado como «cadena» no restringe nada.
2. Para quién. Cada llamada carga con el cliente en cuyo nombre actúa, y la herramienta lo COMPRUEBA en vez de fiarse.
3. Qué devuelve, con una forma que quien llama pueda validar. Una herramienta que devuelve prosa ha movido el problema de parseo, no lo ha resuelto.
4. Si escribe. Una herramienta que solo lee y una que crea un pedido no son el mismo riesgo y no deberían recorrer el mismo camino.

Esa última distinción es la que más integraciones se saltan, y es la que decide lo que tiene que pasar a continuación.

4. Permisos: denegar por defecto, y comprobar donde importa

Dos reglas hacen casi todo el trabajo, y ninguna es exótica:

• Denegar por defecto. Una llamada sin credenciales, o con una firma que no verifica, se rechaza. Ni se degrada, ni se registra y se deja pasar.
• Comprobar el cliente en el servicio, no en la puerta. Una puerta que autentica y luego reenvía llamadas de confianza convierte cualquier error interno en un error entre clientes. Quien tiene los datos es quien tiene que confirmar que quien llama es quien la URL dice.

Hay una tercera menos evidente: una credencial válida para siempre es una credencial que en la práctica no puedes revocar. Una ventana de validez corta con protección contra repetición cuesta casi nada y se lleva por delante una clase entera de problemas.

5. Una persona en el camino de escritura

La especificación dice que el host debe obtener consentimiento explícito antes de invocar una herramienta. En un producto conversacional eso no puede significar un diálogo en cada llamada — nadie lo usaría. Significa decidir, de antemano, qué acciones se paran.

La palabra determinista ahí carga con todo. Una instrucción en un prompt diciéndole al modelo que pregunte antes de actuar es una petición, y una petición no es un control. La interrupción tiene que vivir en el código que despacha la llamada.

6. La vida de una llamada a herramienta

1. Autenticar y acotar. Quién llama, en nombre de quién, y si esa credencial sigue siendo válida.
2. Validar la entrada contra el contrato declarado, antes de que se ejecute nada.
3. Decidir si se para. Lectura, escritura reversible o irreversible: la clasificación es de la herramienta, no del modelo.
4. Ejecutar contra el sistema que de verdad tiene el dato.
5. Validar la salida igual que se validó la entrada.
6. Dejar registro. Qué se llamó, quién, para qué cliente y con qué resultado. Si eso no se puede reconstruir después, no puedes responder a la única pregunta que importa cuando algo sale mal.

7. Implementar tu primera herramienta

El consejo que más tiempo ahorra es de orden. Construye primero la versión de solo lectura, con su contrato declarado y su entrada validada, y hazla funcionar de punta a punta. Solo entonces añade algo que escriba — y cuando lo hagas, decide su clase de reversibilidad antes de escribir el código, no después.

Montar MCP junto a una interfaz HTTP que ya existe, en vez de sustituirla, merece la pena por lo mismo: los consumidores se mueven de uno en uno y no hay que apagar nada para que la primera integración funcione.

La especificación, y dónde leerla

Todo lo citado arriba sale de la propia especificación de MCP. Es corta y merece leerse entera, sobre todo la sección de seguridad.

• modelcontextprotocol.io — MCP es «an open protocol that enables seamless integration between LLM applications and external data sources and tools», sobre JSON-RPC 2.0, con tres papeles: hosts, clients y servers. Un servidor ofrece recursos, prompts y herramientas.
• modelcontextprotocol.io — «Hosts must obtain explicit user consent before invoking any tool», y las descripciones de una herramienta «should be considered untrusted, unless obtained from a trusted server»: una herramienta es ejecución de código arbitrario.
• modelcontextprotocol.io — Y lo dice de sí misma: «MCP itself cannot enforce these security principles at the protocol level». El consentimiento y el control de accesos los tiene que construir quien lo implementa; el protocolo solo los recomienda.

Especificación consultada el 2026-09-29. MCP versiona por fecha, así que comprueba contra la revisión que estés implementando.