MCP, el Model Context Protocol

Sin un protocolo común, cada aplicación con LLMLLM Large language model: red neuronal entrenada para predecir el siguiente token y ajustada para seguir instrucciones. integra cada sistema externo a mano. Cinco aplicaciones (un IDE, un chat, un agente de códigoAgente de código Agente que trabaja dentro de un repositorio: lee archivos, edita código y ejecuta comandos para cumplir una tarea., un bot interno, un asistente de soporte) y diez sistemas (GitHub, Slack, Postgres, Jira...) suman hasta cincuenta integraciones, cada una con su formato de herramientas, su autenticación y sus bugs.

El Model Context Protocol (MCPMCP Model Context Protocol, protocolo abierto sobre JSON-RPC para exponer herramientas, recursos y prompts a aplicaciones con LLM.) ataca ese problema de integración. Veamos qué estandariza, qué deja deliberadamente fuera y cómo exponer o consumir herramientas por MCP sin ceder el control que construimos en Tool calling y harness.

Qué estandariza MCP

+------------- Host (IDE, agent, chat) --------------+
|  LLM <-> host logic <-> client   client   client   |
+---------------------------|--------|--------|------+
              JSON-RPC 2.0  |        |        |
                            v        v        v
                        server    server   server
                        (GitHub)  (files)  (Postgres)

• Host: la aplicación que contiene al modelo y decide.
• Client: el componente del host que mantiene la conexión con un servidor.
• Server: el programa que expone capacidades.

Un servidor ofrece tres primitivas principales:

El cliente descubre las herramientas con tools/list, que devuelve nombre, descripción y JSON Schema: exactamente la "publicidad" de una herramienta. Los mensajes viajan como JSON-RPC 2.0 sobre dos tipos de transporte: stdio (el host lanza el servidor como proceso hijo) o HTTP (servidor remoto).

Qué no estandariza

MCP resuelve integración, no confianza. Para servidores remotos, la especificación define cómo un cliente se autentica y obtiene autorización (basada en OAuth). Eso responde "¿puede este cliente hablar con este servidor?". No responde "¿debería este agente ejecutar esta llamada, con estos argumentos, ahora?". Esa decisión sigue siendo del host.

Conectar un servidor significa aceptar código y texto de un tercero en tres niveles:

• Código: un servidor stdio es un proceso que corre en tu máquina, con tus permisos.
• Texto que el modelo lee: las descripciones de las herramientas y sus resultados entran al contexto; ambos pueden traer instrucciones hostiles (ver Sandboxing y seguridad de agentes).
• Acciones: las herramientas actúan sobre sistemas externos, a menudo con tus credenciales.

Consumir MCP sin ceder el control

Así responde docket a las cuatro preguntas:

• Nombres: toda herramienta adaptada se llama mcp____, y ninguna integrada empieza con mcp__. El nombre del servidor lo elige el operador, no el servidor remoto. Si un nombre ya existe, la herramienta nueva se omite en lugar de sobrescribir.
• Validación: nombre y descripción pasan por la política pre_input con trusted=False; si una política los bloquea, la herramienta no se registra.
• Permiso: como nada prueba que una herramienta remota sea de solo lectura, todas se registran con kind="write". Un rol sin escritura recibe cero herramientas MCP.
• Aislamiento: src/docket/edges/adapters/mcp_client.py lanza un subproceso stdio nuevo por cada intercambio, con timeout; un servidor caído se omite y se registra sin tumbar el turno.

Los límites, dichos con claridad: un rol de solo lectura no puede usar ni siquiera un servidor MCP de documentación inofensivo; no hay caché de listados, así que cada servidor configurado se relanza en cada turno (la spec, specs/functional/mcp-client.spec.md, registra una medición de unos 0,6 s por servidor); y el filtro pre_input se aplica a las descripciones, no a los resultados. Lo que devuelve un servidor entra al contexto sin filtrar; la defensa es estructural: lo que el agente puede hacer después.

Exponer MCP: el protocolo como canal

MCP también sirve para que otro host conduzca tu sistema. La regla es la misma: el protocolo es una puerta más hacia los mismos controles, no un atajo.

// From crates/tack-cli/src/mcp.rs
"move_item" => {
    let id = require_str(args, "id")?;
    let status = require_str(args, "status")?;
    write_item(client, &id, &json!({ "status": status }))
}

write_item lee el item con su ETag y escribe con If-Match, de modo que un agente no puede pisar un cambio que una persona hizo en la interfaz entre la lectura y la escritura. Los errores vuelven como resultado con isError: true, no como falla del protocolo. Tack excluye a propósito del MCP el enrolamiento de runnersRunner Proceso trabajador que reclama trabajo, lo ejecuta cerca del código y las credenciales, y reporta el resultado. (devuelve un secreto de un solo uso), la creación de flotas y perfiles, y la reconciliación de ejecuciones ambiguas. Su límite declarado: el servidor hereda el tokenToken Unidad de subpalabra con la que el modelo lee, escribe y cobra. de la CLI y no hay alcance por herramienta. Las herramientas de ejecución pertenecen a la flota de agentes, que según el README es posterior a los binarios publicados y por ahora se instala desde la rama develop.

Para CTOs

Antes de conectar un servidor MCP, decide quién aplica la política. Si tu host no tiene un punto de enforcement propio en cada llamada, estás delegando tu seguridad en el autor de cada servidor. Y antes de exponer uno, decide qué acciones quedan fuera del protocolo: lo que devuelve secretos o toma decisiones de operador no debería estar al alcance de un agente.

Para llevar

• MCP estandariza descubrimiento e invocación de tools, resources y promptsPrompt Todo lo que se envía al modelo en una llamada: mensajes con rol y definiciones de herramientas. sobre JSON-RPC (stdio o HTTP).
• MCP no decide si una acción concreta está permitida: esa decisión sigue en el host.
• Descripciones y resultados de un servidor MCP son entrada no confiable.
• Al consumir MCP, las herramientas remotas deben pasar por el mismo chokepointChokepoint Único camino de código por el que pasa toda acción, donde se concentran políticas y registro. que las propias.
• Al exponer MCP, el servidor debe llamar a los mismos caminos validados que tu CLI o API, y dejar fuera las acciones de administrador.

Comprueba lo aprendido