Un agente es un modelo de lenguaje metido en un bucle con acceso a herramientas: recibe un objetivo, decide una acción, la ejecuta, mira el resultado y vuelve a decidir. El Model Context Protocol —MCP— es «un estándar de código abierto para conectar aplicaciones de IA con sistemas externos», y su documentación usa una analogía útil: «pensá en MCP como un puerto USB-C para aplicaciones de IA». Define una arquitectura de host, cliente y servidor sobre mensajes JSON-RPC 2.0, con tres primitivas que un servidor puede exponer —herramientas, recursos y prompts— y dos transportes: stdio para lo local y Streamable HTTP para lo remoto. La revisión vigente de la especificación es 2025-11-25.
Ver índice de contenidos
Qué convierte un modelo en agente
Un modelo de lenguaje, por sí solo, produce texto. No lee tu disco, no consulta una base de datos y no manda un correo: predice la continuación más probable de lo que se le dio. Lo que convierte a ese modelo en agente no es un modelo distinto —puede ser exactamente el mismo— sino tres piezas alrededor:
- HerramientasFunciones que el modelo puede pedir que se ejecuten: leer un archivo, consultar una API, correr una prueba.
- Un bucleEl resultado de cada acción vuelve al contexto, y el modelo decide la siguiente con esa información nueva.
- Un criterio de paradaObjetivo cumplido, permiso denegado, cantidad de pasos agotada o costo excedido. Sin esto, no hay agente: hay un proceso que no termina.
La diferencia práctica con un chatbot es de capacidad de acción. A un chatbot le pedís que redacte un correo y te lo escribe; un agente puede enviarlo. Ese salto es el que trae todo lo interesante y todo el riesgo, porque un error de un chatbot es un texto equivocado y un error de un agente es una acción equivocada sobre un sistema real.
La pregunta que ordena el tema
Cuando alguien dice «agente», la pregunta útil no es qué modelo usa, sino qué herramientas tiene y con qué permisos. Un agente con una herramienta de solo lectura sobre un directorio y un agente con acceso de escritura a la base de datos de producción se describen igual y no tienen nada que ver.
El problema que resuelve MCP
Si cada aplicación de IA define a su manera cómo se le declara una herramienta, el resultado es previsible: quien mantiene una fuente de datos —un repositorio, un sistema de tickets, una base— tiene que escribir una integración por cada aplicación, y quien construye una aplicación tiene que escribir una integración por cada fuente. Es el problema clásico de N por M.
MCP se propone cortarlo con un protocolo común. La documentación lo define así:
«MCP es un estándar de código abierto para conectar aplicaciones de IA con sistemas externos.»
«Pensá en MCP como un puerto USB-C para aplicaciones de IA. Igual que USB-C provee una manera estandarizada de conectar dispositivos electrónicos, MCP provee una manera estandarizada de conectar aplicaciones de IA con sistemas externos.»
La comparación que más ayuda a entender el alcance, y que está en la propia especificación, es otra: MCP «toma algo de inspiración del Language Server Protocol», que estandarizó cómo se agrega soporte de un lenguaje de programación a todo un ecosistema de herramientas de desarrollo. La idea es la misma trasladada: escribir el servidor una vez e integrarlo en cualquier parte.
Host, cliente y servidor
MCP sigue una arquitectura cliente-servidor, y los tres participantes están definidos con precisión en la documentación:
| Participante | Definición oficial | Ejemplo |
|---|---|---|
| Host | «La aplicación de IA que coordina y administra uno o varios clientes MCP» | Un editor de código, una aplicación de escritorio, una herramienta de línea de comandos |
| Cliente | «Un componente que mantiene una conexión con un servidor MCP y obtiene contexto de él para que el host lo use» | Se crea uno por cada servidor al que el host se conecta |
| Servidor | «Un programa que provee contexto a los clientes MCP» | Un servidor de sistema de archivos, uno de base de datos, uno de un servicio remoto |
Hay un malentendido que conviene sacar de encima temprano, porque la documentación lo aclara de forma explícita: «servidor MCP» se refiere al programa que sirve los datos de contexto, sin importar dónde corre. Un servidor de sistema de archivos que arranca en tu propia máquina es igual de «servidor» que uno que corre en la infraestructura de un proveedor. Lo que cambia es el transporte.
Debajo, el protocolo se organiza en dos capas. La capa de datos «define el protocolo basado en JSON-RPC» e incluye la gestión del ciclo de vida y las primitivas. La capa de transporte «define los mecanismos y canales de comunicación», con el establecimiento de la conexión, el encuadre de mensajes y la autorización. Conceptualmente la de datos es la interna y la de transporte la externa, y esa separación es la que permite usar el mismo formato de mensajes en cualquier transporte.
Las primitivas
Acá está el corazón del protocolo. La documentación es directa al respecto: «las primitivas de MCP son el concepto más importante dentro de MCP» porque «definen lo que clientes y servidores pueden ofrecerse mutuamente». Un servidor puede exponer tres:
- Herramientas: «funciones ejecutables que las aplicaciones de IA pueden invocar para realizar acciones» —operaciones sobre archivos, llamadas a APIs, consultas a bases de datos—.
- Recursos: «fuentes de datos que proveen información contextual a las aplicaciones de IA» —contenido de archivos, registros de una base, respuestas de una API—.
- Prompts: «plantillas reutilizables que ayudan a estructurar interacciones con modelos de lenguaje» —prompts de sistema, ejemplos—.
La distinción entre herramienta y recurso es la que más se confunde y la que más importa: una herramienta hace algo, un recurso informa algo. Un servidor de base de datos bien diseñado expone el esquema como recurso y la consulta como herramienta. Esa separación no es estética: define qué necesita autorización.
Menos conocido es que el cliente también puede ofrecer primitivas al servidor, y son las que permiten interacciones más ricas:
| Primitiva | Qué permite | Para qué sirve |
|---|---|---|
| Sampling | Que el servidor pida una respuesta del modelo al host | El servidor usa un modelo sin incluir un SDK propio ni atarse a un proveedor |
| Roots | Consultar los límites de sistema de archivos o de URI en los que operar | Que el servidor sepa dónde tiene permitido trabajar |
| Elicitation | Pedirle información adicional o una confirmación a la persona | Preguntar un dato que falta o confirmar una acción antes de ejecutarla |
De las tres, elicitation es la que más rinde para la seguridad, porque es el mecanismo estándar para poner a una persona en el medio antes de una acción que no se puede deshacer. Y sobre sampling la especificación agrega una restricción interesante: «el protocolo limita intencionalmente la visibilidad del servidor sobre los prompts».
Los dos transportes
MCP admite dos mecanismos de transporte, y la elección no es de gusto: determina dónde corre el servidor y cómo se autentica.
| Transporte | Cómo funciona | Cuándo |
|---|---|---|
| stdio | «Usa flujos de entrada y salida estándar para comunicación directa entre procesos locales en la misma máquina, con rendimiento óptimo y sin sobrecarga de red» | El servidor corre en tu equipo. Suele atender a un solo cliente |
| Streamable HTTP | HTTP POST del cliente al servidor, con eventos enviados por el servidor de forma opcional para streaming. Admite autenticación HTTP estándar; se recomienda OAuth para obtener los tokens | El servidor es remoto. Suele atender a muchos clientes |
La consecuencia de seguridad es directa y vale tenerla presente antes de configurar nada: un servidor stdio es un proceso que arranca en tu máquina con tus permisos de usuario, así que instalarlo equivale a ejecutar el programa de un tercero en tu equipo. Un servidor remoto no corre en tu máquina, pero recibe los datos que le mandes.
Cómo se ve en la práctica
El protocolo es con estado y arranca con una negociación de capacidades: el cliente manda initialize con la versión del protocolo que habla y lo que sabe hacer, el servidor responde con lo suyo, y si no hay una versión compatible en común la conexión se termina. Después, el ciclo de descubrir y ejecutar:
// 1. El cliente pregunta qué herramientas hay
{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }
// 2. El servidor responde con nombre, descripción y esquema de entrada
{ "tools": [ {
"name": "weather_current",
"description": "Get current weather information for any location",
"inputSchema": { "type": "object",
"properties": { "location": { "type": "string" } },
"required": ["location"] } } ] }
// 3. El cliente ejecuta con el nombre exacto y los argumentos del esquema
{ "jsonrpc": "2.0", "id": 3, "method": "tools/call",
"params": { "name": "weather_current",
"arguments": { "location": "Buenos Aires" } } }
// 4. Si la lista de herramientas cambia, el servidor avisa sin que nadie pregunte
{ "jsonrpc": "2.0", "method": "notifications/tools/list_changed" }Tres cosas de ese intercambio explican por qué el protocolo funciona bien en la práctica. El esquema de entrada es JSON Schema, así que la validación de tipos y la documentación de los parámetros vienen incluidas. El descubrimiento es dinámico: las herramientas pueden aparecer y desaparecer según el estado del servidor o los permisos de quien lo usa. Y las notificaciones evitan que el cliente tenga que preguntar todo el tiempo si algo cambió.
Qué no resuelve MCP
Esta es la parte que más malentendidos evita, y está escrita en la documentación con una claridad que conviene citar: «MCP se enfoca únicamente en el protocolo para el intercambio de contexto; no dicta cómo las aplicaciones de IA usan los modelos ni cómo administran el contexto provisto».
Es decir, MCP no decide nada de esto, y sigue siendo trabajo de la aplicación:
- Qué herramientas se le muestran al modelo y cuáles se dejan afuera en cada momento.
- Cuánto contexto entra y qué se descarta cuando no cabe todo.
- El bucle del agente: cuántos pasos, con qué criterio de parada, qué hacer ante un error.
- Los permisos: qué se ejecuta solo y qué requiere confirmación.
Dicho de otro modo: MCP resuelve el cómo se conecta, no el cómo se decide. Un agente mal diseñado con MCP sigue siendo un agente mal diseñado, ahora con mejores integraciones.
Los permisos son tu problema
La especificación dedica una sección a seguridad y arranca reconociendo el tamaño del asunto: «el Model Context Protocol habilita capacidades poderosas mediante acceso arbitrario a datos y caminos de ejecución de código». Y sobre las herramientas es todavía más explícita:
«Las herramientas representan ejecución de código arbitrario y deben tratarse con la precaución apropiada.»
«En particular, las descripciones del comportamiento de una herramienta, como las anotaciones, deben considerarse no confiables, a menos que provengan de un servidor confiable.»
«Los hosts deben obtener consentimiento explícito de la persona antes de invocar cualquier herramienta.»
Los cuatro principios que enumera son consentimiento y control de la persona, privacidad de los datos, seguridad de las herramientas y control del sampling. Pero el reconocimiento más importante es el que viene después: «MCP no puede hacer cumplir estos principios de seguridad a nivel del protocolo». Son responsabilidad de quien implementa el host.
Errores frecuentes
- Creer que MCP es un modelo o un producto. Es un protocolo: define cómo se hablan las partes, nada más.
- Suponer que «servidor» significa remoto. La mayoría de los servidores MCP de uso diario corren en tu propia máquina por stdio.
- Exponer todo como herramienta. Lo que solo informa va como recurso; así queda claro qué necesita autorización.
- Confiar en la descripción de una herramienta ajena. La especificación dice que las anotaciones deben considerarse no confiables si el servidor no lo es.
- Instalar servidores sin mirar qué son. Un servidor stdio es un programa de un tercero corriendo con tus permisos.
- Conectar veinte servidores «por si acaso». Cada herramienta declarada ocupa contexto y agrega superficie de ataque.
- Esperar que el protocolo ponga los límites. El bucle, el contexto y los permisos los define la aplicación.
Preguntas frecuentes
¿Qué diferencia hay entre un chatbot y un agente?
Un chatbot recibe un pedido y devuelve texto. Un agente recibe un objetivo y trabaja en un bucle: decide una acción, la ejecuta con una herramienta, mira el resultado y vuelve a decidir, hasta que considera cumplido el objetivo o se queda sin permiso o sin pasos. La diferencia no está en el modelo, que puede ser el mismo, sino en tres piezas que lo rodean: herramientas que le permiten actuar, un bucle que le devuelve el resultado de cada acción, y un criterio para detenerse.
¿Qué es el Model Context Protocol?
Es «un estándar de código abierto para conectar aplicaciones de IA con sistemas externos», y su propia documentación lo compara con un puerto USB-C para aplicaciones de IA: igual que USB-C provee una manera estandarizada de conectar dispositivos electrónicos, MCP provee una manera estandarizada de conectar aplicaciones de IA con sistemas externos. Usa mensajes JSON-RPC 2.0 y define qué puede ofrecer un servidor a un cliente: herramientas, recursos y plantillas de prompt.
¿Cuáles son las primitivas de MCP?
Un servidor puede exponer tres: herramientas, que son «funciones ejecutables que las aplicaciones de IA pueden invocar para realizar acciones»; recursos, que son «fuentes de datos que proveen información contextual»; y prompts, que son «plantillas reutilizables que ayudan a estructurar interacciones con modelos de lenguaje». El cliente, a su vez, puede ofrecer al servidor sampling —pedirle una respuesta al modelo del host—, roots —los límites de sistema de archivos o de URI en los que operar— y elicitation, para pedirle información o confirmación a la persona.
¿Qué es un host, un cliente y un servidor MCP?
El host es «la aplicación de IA que coordina y administra uno o varios clientes MCP»: por ejemplo un editor de código o una aplicación de escritorio. El cliente es «un componente que mantiene una conexión con un servidor MCP y obtiene contexto de él para que el host lo use»; hay uno por cada servidor conectado. Y el servidor es «un programa que provee contexto a los clientes MCP», que puede correr en la misma máquina o de forma remota. Servidor no significa máquina remota: significa el programa que sirve el contexto.
¿Qué transportes usa MCP?
Dos. El transporte stdio «usa flujos de entrada y salida estándar para comunicación directa entre procesos locales en la misma máquina, con rendimiento óptimo y sin sobrecarga de red», y es el que se usa cuando el servidor corre en tu equipo. El transporte Streamable HTTP usa HTTP POST del cliente al servidor con eventos enviados por el servidor de forma opcional para streaming, permite servidores remotos y admite autenticación HTTP estándar; para obtener los tokens, la documentación recomienda OAuth.
¿MCP resuelve la seguridad de un agente?
No, y la especificación es explícita: «MCP no puede hacer cumplir estos principios de seguridad a nivel del protocolo». Enumera los principios que quien implementa debería seguir —consentimiento y control de la persona, privacidad de los datos, seguridad de las herramientas y control del sampling— y advierte que «las herramientas representan ejecución de código arbitrario y deben tratarse con la precaución apropiada». La seguridad queda del lado de la aplicación que decide qué permisos otorga.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, blog. Google dona el protocolo Agent2Agent (A2A) a la Fundación Linux, 25 de junio de 2025. El otro protocolo del ecosistema: comunicación entre agentes, no entre agente y herramientas.
- Underc0de, foro. Sección Inteligencia artificial. Discusiones de la comunidad sobre herramientas y agentes.
Documentación oficial
- Model Context Protocol. What is the Model Context Protocol?. Definición del protocolo y la analogía del puerto USB-C, citadas textualmente.
- Model Context Protocol. Architecture overview. Participantes, capas, primitivas, transportes y el ejemplo de intercambio JSON-RPC, citados textualmente.
- Model Context Protocol. Specification, revisión 2025-11-25. La sección de seguridad, los cuatro principios y la inspiración en el Language Server Protocol.
- JSON-RPC. JSON-RPC 2.0. El protocolo de llamadas remotas sobre el que se apoya la capa de datos.