Model Context Protocol (MCP)

Model Context Protocol (MCP) es un protocolo abierto para conectar aplicaciones de IA con sistemas que aportan datos o capacidades externas.

Sin una interfaz común, cada aplicación tiene que implementar sus propias integraciones para hablar con un filesystem, GitHub, una base de datos, un navegador o cualquier otro servicio. MCP estandariza la comunicación entre la aplicación y esas integraciones.

El modelo no se conecta directamente al servidor MCP. Entre ambos sigue existiendo el host, que decide qué capacidades expone al modelo, qué contenido incorpora al contexto y qué operaciones permite ejecutar.

Host, client y server

Una integración MCP tiene tres piezas principales:

• El host es la aplicación donde trabaja el usuario, por ejemplo un IDE, un coding agent o cualquier aplicación que incorpore un modelo.
• El client vive dentro del host e implementa el lado cliente del protocolo.
• El server expone capacidades o datos mediante MCP.

Un host puede conectarse a varios servidores y normalmente mantiene un client lógico para cada uno.

El servidor puede ser un proceso local ejecutado por el propio host o un servicio remoto. En ambos casos, el modelo ve las capacidades a través del host. El servidor no obtiene acceso directo al LLM por el hecho de usar MCP.

MCP estandariza la interfaz entre aplicaciones y servidores, pero no sustituye al harness. La selección de tools, la construcción del contexto, las políticas de aprobación y el sandbox siguen dependiendo del sistema que utiliza MCP.

Tools, resources y prompts

El protocolo organiza buena parte de lo que expone un servidor alrededor de tres primitives. Una forma útil de distinguirlas es mirar quién controla su uso.

Tools

Una tool representa una operación que el modelo puede solicitar.

Un servidor puede exponer, por ejemplo, search_repository, read_issue o create_ticket. La definición incluye un nombre y un schema de entrada, normalmente acompañados de una descripción y, cuando resulta útil, un schema de salida.

El client descubre esas definiciones y el host puede presentarlas al modelo como parte de las tools disponibles. Si el modelo selecciona una, MCP transporta la llamada hasta el servidor y devuelve el resultado.

La mecánica sigue siendo la misma que con una tool integrada directamente en un harness. El modelo solicita una operación y otra capa la ejecuta. MCP estandariza la interfaz utilizada para conectar esa capacidad.

Las tools pueden incluir annotations como readOnlyHint, destructiveHint, idempotentHint u openWorldHint. Sirven para describir propiedades de la operación y pueden ayudar al cliente a decidir cómo presentarla o cuándo pedir confirmación.

Son hints, no controles de seguridad. Un cliente no debería asumir que una annotation enviada por un servidor no confiable describe fielmente el comportamiento real de la tool.

Resources

Un resource expone información que la aplicación puede leer y aportar al modelo.

Se identifica mediante una URI y puede representar, por ejemplo, un fichero, configuración, documentación o datos obtenidos de otro servicio.

Desde el punto de vista del protocolo, una tool ofrece una operación elegida por el modelo y un resource ofrece datos gestionados por la aplicación. El código que existe detrás del servidor puede ser complejo en ambos casos, pero el control que ve el cliente es diferente.

Prompts

Un prompt es una plantilla reutilizable que el servidor pone a disposición del usuario.

Puede aparecer en el host como una acción, una entrada de menú o un comando equivalente. Cuando el usuario lo selecciona, el client solicita al servidor los mensajes resultantes y los incorpora a la conversación.

No equivale a las instrucciones permanentes de un proyecto. El usuario elige cuándo utilizar un prompt MCP, mientras que ficheros como AGENTS.md dependen del mecanismo de instrucciones del propio harness.

Flujo de una tool call

Supongamos que un servidor MCP expone una tool search_repository.

El servidor puede terminar llamando a una API, consultando una base de datos, leyendo el filesystem o ejecutando cualquier otra lógica que implemente.

Por eso una tool MCP no describe necesariamente la tecnología que existe detrás. El protocolo define la interfaz visible desde el host.

Transportes

La misma interfaz puede utilizarse con servidores locales o remotos.

stdio

Con stdio, el host arranca un proceso local y se comunica con él mediante su entrada y salida estándar.

Es habitual en integraciones que necesitan trabajar con el mismo equipo donde corre el agente, por ejemplo herramientas de desarrollo, filesystem, bases de datos locales o utilidades instaladas en la máquina.

El mecanismo de configuración utilizado para arrancar ese proceso no forma parte de MCP. Ficheros como mcp.json, bloques mcpServers o pantallas de configuración concretas pertenecen al host que los implementa.

Streamable HTTP

Streamable HTTP permite ejecutar el servidor como un servicio accesible por red.

El client se comunica con un endpoint MCP en lugar de lanzar un proceso local. Este modelo encaja mejor con integraciones compartidas, servicios SaaS o servidores desplegados independientemente del equipo donde vive el host.

Aquí aparecen también las fronteras habituales de un servicio remoto: red, TLS, autenticación, autorización, disponibilidad y las credenciales utilizadas para acceder al backend.

El transporte HTTP+SSE de versiones anteriores está deprecated. Streamable HTTP es el transporte HTTP actual.

Versiones y lifecycle

MCP ha evolucionado rápido y parte de la documentación existente describe un lifecycle anterior.

La revisión estable 2026-07-28 no utiliza el handshake initialize ni sesiones a nivel de protocolo. Cada request es autocontenida e incluye la información necesaria sobre versión, client y capacidades. Un client puede utilizar server/discover para consultar previamente qué soporta el servidor, pero no es un paso obligatorio antes de cada operación.

Que el core sea stateless a nivel de protocolo no obliga a la aplicación a ser stateless. Un servidor puede conservar estado mediante jobs, identificadores, datos persistentes o handles explícitos que viajan entre llamadas.

Los SDK modernos pueden mantener compatibilidad con las dos generaciones. Por eso dos integraciones MCP funcionales pueden mostrar tráfico y lifecycle diferentes dependiendo de la versión utilizada.

Autorización

Conectar una tool no implica tener autoridad para realizar la operación que representa.

Para los transportes HTTP, MCP define un modelo de autorización basado en OAuth, pero la autorización es opcional. Cuando se utiliza, la credencial presentada al servidor puede limitar las capacidades disponibles para ese client.

El servidor también puede utilizar otra identidad para hablar con el sistema que existe detrás.

Por ejemplo, un servidor MCP de GitHub puede recibir una llamada correctamente autorizada desde el host y después utilizar una credencial para consultar GitHub. El efecto final depende de la política del host y de los permisos de esa credencial.

La cadena completa puede verse así:

modelo → host → client MCP → server MCP → servicio externo

Permitir una tool en el host no amplía por sí mismo los permisos de la cuenta externa. La autoridad efectiva depende de toda la cadena.

Seguridad

MCP facilita conectar capacidades de distintos sistemas a un mismo agente. Eso añade nuevas fronteras de confianza.

Servidores locales

Un servidor ejecutado mediante stdio puede ser software instalado desde un paquete o repositorio externo.

Si el proceso tiene acceso al home del usuario, variables de entorno, credenciales de cloud o sockets locales, su capacidad real puede ser mucho mayor que las tools que anuncia.

Revisar una lista de tools no equivale a revisar lo que puede hacer el proceso que las implementa. Un servidor local también es una dependencia ejecutable.

Tool definitions y contexto

Nombre, descripción, schemas y otros metadatos ayudan al modelo a entender cuándo y cómo utilizar una tool.

Esos metadatos también pueden influir en sus decisiones.

Un servidor malicioso puede esconder instrucciones dentro de las definiciones para intentar modificar cómo utiliza el agente esa tool u otras capacidades disponibles. Este patrón suele denominarse tool poisoning.

La confianza tampoco termina al instalar el servidor. Si sus definiciones cambian posteriormente, una integración previamente revisada puede empezar a presentar otro comportamiento. Cuando el cambio aprovecha la confianza obtenida anteriormente se suele hablar de rug pull.

Las annotations ayudan a describir el riesgo esperado de una tool, pero proceden del propio servidor. No sustituyen a políticas aplicadas por el host o por el runtime.

Resultados y resources

El contenido devuelto por una tool o leído desde un resource puede proceder de fuentes externas.

Una tool de búsqueda web, email o repositorios puede recuperar texto controlado por terceros. Cuando ese resultado entra en el contexto del modelo aparece la misma frontera que en una indirect prompt injection. El agente necesita procesar los datos, pero esos datos no deberían adquirir autoridad para decidir qué otras acciones ejecuta.

Confiar en el servidor MCP no implica confiar en todo el contenido que el servidor recupera.

Permisos

El impacto de una decisión manipulada depende de las capacidades que existan detrás.

Un servidor de correo con acceso de solo lectura presenta un blast radius diferente del mismo servidor utilizando una cuenta capaz de enviar mensajes, borrar contenido o modificar reglas.

Los scopes, las políticas del host, la aprobación humana y los permisos de la identidad externa actúan en capas diferentes. MCP proporciona mecanismos para comunicar y autorizar capacidades, pero la autoridad final sigue dependiendo de las credenciales y controles que rodean la operación.

También importa la composición. Un servidor puede aportar acceso a datos sensibles mientras otro proporciona comunicación con Internet o ejecución de comandos. La capacidad efectiva del agente sale de la combinación de las rutas disponibles, no de evaluar cada servidor de forma aislada.

Qué revisar

Al añadir o auditar una integración MCP conviene poder responder a estas preguntas:

• ¿El server es un proceso local o un servicio remoto?
• ¿Qué código se ejecuta y con qué permisos?
• ¿Qué tools, resources y prompts expone?
• ¿Qué metadatos y resultados pueden terminar en el contexto del modelo?
• ¿Qué credenciales utiliza el server y qué autoridad tienen?
• ¿Puede una capacidad producir el mismo efecto que otra aparentemente restringida?
• ¿Puede el catálogo o el comportamiento del servidor cambiar después de haber sido aprobado?
• ¿Qué controles aplica el host antes de ejecutar una acción?
• ¿Qué contenido externo puede volver al modelo después de una llamada?

MCP define cómo conectar las piezas. La confianza, los permisos y el aislamiento dependen de cómo se despliegan y combinan esas piezas.

Referencias

• Model Context Protocol — Specification 2026-07-28
• Model Context Protocol — Server features
• Model Context Protocol — Tools
• Model Context Protocol — Resources
• Model Context Protocol — Transports
• Model Context Protocol — Authorization
• Model Context Protocol — The 2026-07-28 Specification
• Model Context Protocol — Tool Annotations as Risk Vocabulary
• OWASP — MCP Security Cheat Sheet
• OWASP — MCP Top 10