Una aplicación de IA se vuelve útil cuando puede llegar a otros sistemas: leer un ticket, consultar una base de datos, publicar un mensaje. Sin un estándar común, cada aplicación se conecta a cada sistema a mano. Cinco aplicaciones y diez sistemas (GitHub, Slack, Postgres, Jira...) pueden sumar cincuenta integraciones separadas, cada una con su propio formato, su acceso y sus bugs.
El Model Context Protocol () es un estándar común para esas conexiones. Esta lección cubre qué estandariza MCP, qué deja deliberadamente en tus manos y cómo usarlo en ambas direcciones, consumiendo herramientas de otros sistemas y exponiendo las tuyas, sin ceder el control que construimos en Tool calling y harness.
Qué estandariza MCP
Piensa en un enchufe universal: cuando todos los aparatos y tomas comparten una forma, ya no necesitas un adaptador para cada par. MCP cumple ese papel entre las aplicaciones de IA y los sistemas que usan. Cada lado implementa el protocolo una vez, así que cinco aplicaciones y diez sistemas necesitan quince implementaciones, no cincuenta. LSP, el estándar que permite a cualquier editor de código soportar cualquier lenguaje de programación, funciona igual.
Hay tres piezas, y el diagrama muestra cómo se conectan:
- Hosteditor, agente o chat; tiene el modelo
- Modelo
- Lógica del host
- Clientesdentro del host, una conexión por servidor
- Servidorescada uno ofrece las capacidades de un sistema
- GitHub
- Archivos
- Postgres
- El host es la aplicación que tiene el modelo y toma las decisiones.
- Un cliente es la pieza dentro del host que mantiene la conexión con un servidor.
- Un servidor es un programa que ofrece capacidades de algún sistema.
Un servidor puede ofrecer herramientas (acciones que el modelo puede pedir ejecutar), recursos (datos que la aplicación puede leer, como un archivo) y (plantillas de mensajes reutilizables que un usuario puede elegir). Al conectarse, el cliente le pide al servidor su lista de herramientas, y cada una llega con un nombre, una descripción y la forma de sus argumentos: justo lo que el modelo necesita para decidir cuándo usarla. El servidor puede correr como un programa local que el host inicia en la misma máquina, o como un servicio remoto en la web.
Qué deja en tus manos
MCP resuelve la conexión, no la confianza. Para servidores remotos, define cómo un cliente se autentica y obtiene permiso para hablar con el servidor. Eso responde "¿esta aplicación puede hablar con este servidor?". No responde "¿este agente debería hacer esta llamada, con estos argumentos, ahora?". Esa decisión sigue siendo del host.
Conectar un servidor significa dejar entrar trabajo ajeno en tres niveles:
- Código: un servidor local es un programa que corre en tu máquina, con tus permisos.
- Texto que lee el modelo: las descripciones y los resultados de las herramientas entran al contexto del modelo, y ambos pueden traer instrucciones escondidas (ver Sandboxing y seguridad de agentes).
- Acciones: las herramientas actúan sobre sistemas reales, a menudo con tus credenciales.
| Pregunta | Respuesta débil | Respuesta mejor |
|---|---|---|
| ¿Quién decide qué tan riesgosa es una herramienta? | "el servidor dice que es de solo lectura" | el host; lo desconocido es riesgoso |
| ¿Quién decide si una llamada puede ejecutarse? | el servidor | el host, con sus propias reglas, en cada llamada |
| ¿Quién registra la acción? | el servidor, si quiere | el host, antes de ejecutarla |
| ¿Quién guarda las credenciales? | el modelo o el prompt | el servidor o un proxy, con el mínimo acceso necesario |
Usar herramientas ajenas sin ceder el control
El patrón seguro es fácil de enunciar: una herramienta que llega por MCP pasa por el mismo punto de control único que tus propias herramientas, donde se revisan los permisos y se registra la llamada. MCP es solo el medio de entrega.
Así responde docket a las preguntas de la tabla:
- Nombres: las herramientas remotas reciben un prefijo elegido por el operador, nunca por el servidor, así que no pueden hacerse pasar por integradas ni reemplazar una que ya existe.
- Filtro: el nombre y la descripción de cada herramienta pasan por las mismas reglas que cualquier entrada no confiable, y si una no las supera, no se agrega.
- Riesgo: como nada prueba que una herramienta remota solo lea, todas se tratan como capaces de cambiar cosas. Un rol sin acceso de escritura no recibe ninguna herramienta MCP.
- Aislamiento: cada intercambio con un servidor local corre en un proceso nuevo con límite de tiempo. Un servidor que falla se salta y se registra sin romper el turno del agente.
En docket
- Lista del servidorlo que el servidor ofrezca
- Renombrada y filtradaprefijo elegido por el operador
- Acotada por rolsin escritura, sin herramientas remotas
- Punto de controlreglas, aprobación y auditoría en cada llamada
- Proceso nuevoun intercambio, con límite de tiempo
Los límites, dichos con claridad: un rol de solo lectura no puede usar ni siquiera un servidor de documentación inofensivo; cada servidor configurado se reinicia en cada turno (el proyecto midió unos 0,6 segundos por servidor), ambos señalados en el README de docket; y el filtro cubre las descripciones, no los resultados. Lo que devuelve un servidor entra al contexto sin filtrar, así que la defensa está en lo que el agente puede hacer después.
Exponer tu sistema por MCP
MCP también permite que la aplicación de IA de otro maneje tu sistema. La regla no cambia: el protocolo es una puerta más hacia los mismos controles, no un atajo que los evita.
En Tack
- Clientestodos toman el mismo camino
- Un agente, por MCP
- La línea de comandos
- API webrevisa las reglas del tablero para todos
- Base de datossolo la API escribe en ella
En la práctica
- Decide quién aplica las reglas antes de conectar un servidor. Si tu aplicación no tiene su propio punto de control en cada llamada, estás delegando tu seguridad en el autor de cada servidor.
- Trata todo lo que envía un servidor como no confiable, descripciones y resultados por igual.
- Da a las herramientas remotas el mínimo acceso que funcione, y pon las desconocidas en la categoría riesgosa por defecto.
- Antes de exponer tu sistema, decide qué queda fuera del protocolo. Todo lo que devuelva secretos o tome decisiones de operador debe quedar fuera del alcance de un agente.
Para profundizar
La documentación de docket y de Tack cubre ambas direcciones con más detalle (en inglés):
- Own the loop, rent the protocols (ADR 0002) registra la decisión detrás de la postura de docket: conserva el ciclo, la lista de herramientas y todos los controles, y usa MCP solo para conectar servidores de herramientas.
- Command reference detalla, en su sección
mcp, las herramientas que docket ofrece como servidor y cómo un operador agrega un servidor externo. - MCP Server cubre el servidor de Tack: por qué corre como un proceso local y no como un endpoint web, todas las herramientas que ofrece y qué acciones quedan solo en la línea de comandos.
Para llevar
- MCP es un estándar común para que las aplicaciones de IA encuentren y usen herramientas, datos y prompts que ofrecen otros sistemas.
- Resuelve quién puede conectarse, no si una acción concreta debe ejecutarse; eso queda en el host.
- Las descripciones y los resultados de un servidor MCP son entrada no confiable.
- Las herramientas que llegan por MCP deben pasar por el mismo punto de control que las tuyas.
- Un servidor MCP que expones debe usar los mismos caminos validados que tus otras interfaces y dejar fuera las acciones administrativas.
Comprueba lo aprendido
¿Qué problema resuelve MCP y cuál deja abierto?
Resuelve la conexión: cualquier aplicación que hable MCP puede usar cualquier sistema que ofrezca un servidor MCP, sin una integración a medida para cada par. Deja abierto si una llamada concreta, con sus argumentos, debe ejecutarse; eso lo tiene que decidir el host en cada llamada.
¿Por qué docket trata cada herramienta remota como capaz de cambiar cosas?
Porque nada prueba que una herramienta remota solo lea. Asumir el caso riesgoso es el valor por defecto seguro: un rol sin acceso de escritura simplemente no recibe ninguna.
¿Qué impide que un agente que usa el servidor MCP de Tack rompa las reglas del tablero?
El servidor nunca escribe directamente en la base de datos. Pasa por la misma API web que todos los demás, y esa API revisa las reglas del tablero para cada cliente.