Este artículo aborda todo lo necesario para entender el funcionamiento de MCP —su arquitectura y componentes—, así como los riesgos de seguridad y los aspectos prácticos de su integración. También se explora el futuro de esta tecnología: MCP Tasks y MCP Apps.
¿Qué es el Model Context Protocol (MCP) y cómo funciona?
El Model Context Protocol es un protocolo de capa de aplicación basado en JSON-RPC. Establece una interfaz para que las aplicaciones de inteligencia artificial, denominadas hosts, lean datos y ejecuten acciones sobre sistemas externos, denominados servidores MCP.
La analogía del "USB-C para la IA"
La industria compara con frecuencia a MCP con el USB-C aplicado a la inteligencia artificial. Antes de la estandarización de este conector físico, cada dispositivo móvil y periférico utilizaba conectores propietarios; de manera similar, antes de MCP, cada plataforma de inteligencia artificial requería un formato particular para invocar funciones o consultar bases de datos. MCP cumple una función equivalente a la de ese conector: un servidor construido para un servicio, como GitHub o PostgreSQL, funciona en cualquier cliente compatible con el protocolo sin necesidad de reescribir la integración.
Arquitectura Cliente-Servidor y las 3 Primitivas Fundamentales
La arquitectura de MCP distribuye las responsabilidades entre tres actores. El host o client es la aplicación con la que interactúa el usuario final -Claude Desktop, Cursor o un flujo de trabajo en n8n, entre otros- y aloja el cliente del protocolo. El server es el programa ejecutable ligero que expone capacidades estructuradas mediante el protocolo. El modelo de lenguaje interpreta el contexto disponible, decide qué herramientas invocar y sintetiza la respuesta final.
A diferencia de las llamadas a funciones tradicionales, la especificación se apoya en tres primitivas esenciales.
Primitivas fundamentales de MCP
-
Tools (Herramientas)acciones ejecutables que el modelo invoca de forma autónoma cuando las considera necesarias para resolver una consulta; tienen efectos secundarios -crear registros, enviar correos, modificar archivos- y requieren parámetros validados mediante esquemas como Zod o JSON Schema.
-
Resources (Recursos)fuentes de información de solo lectura expuestas mediante URIs, por ejemplo config://politica-alerta o file:///logs/app.log, que permiten adjuntar contexto sin ejecutar lógica activa.
-
Prompts (Plantillas)instrucciones y comandos reutilizables que el usuario invoca de forma explícita desde la interfaz del cliente, de manera similar a los comandos con barra, para completar contextos complejos de forma estandarizada.
Medios de Transporte: STDIO vs. Streamable HTTP
Para intercambiar mensajes JSON-RPC, MCP define dos mecanismos de transporte. STDIO está diseñado para servidores locales que se ejecutan como subprocesos en la máquina del usuario: lee mensajes por entrada estándar y responde por salida estándar. Los servidores que usan este transporte no deben escribir registros informativos en la salida estándar, ya que esto corrompe las tramas JSON-RPC; los registros deben dirigirse a la salida de errores estándar. Streamable HTTP, por su parte, está diseñado para servidores remotos desplegados en la nube o detrás de pasarelas de API, y reemplazó los esquemas basados en websockets o en Server-Sent Events para alinearse con infraestructuras web estándar.
Beneficios y Características Principales de MCP
La adopción de MCP ofrece ventajas estructurales tanto para desarrolladores de software como para organizaciones que despliegan agentes de inteligencia artificial.
Beneficios principales de MCP
-
Estandarización y reutilizaciónun servidor MCP se desarrolla una sola vez y se ejecuta sin cambios en múltiples clientes de inteligencia artificial.
-
Separación de responsabilidadesel servidor gestiona la lógica de negocio, la autenticación con la API externa y la validación de tipos, mientras el cliente gestiona la interacción con el usuario y el modelo de lenguaje.
-
Descubrimiento dinámico de capacidadesal conectarse, el cliente solicita el catálogo de herramientas disponibles mediante la función tools/list, lo que permite que el agente identifique qué acciones puede realizar.
-
Control de ejecución en el modeloel agente evalúa las descripciones de las herramientas y determina el momento adecuado para ejecutarlas según la necesidad del usuario.
-
Flexibilidad de lenguajeexisten SDKs oficiales en TypeScript, Python, Go, C# y Java, lo que permite integrar el protocolo en distintas pilas tecnológicas.
La Evolución: Del Core Stateful al Núcleo Sin Estado (Stateless Core)
En sus primeras versiones, MCP exigía un procedimiento de inicialización obligatorio -el intercambio initialize/initialized- y mantenía una sesión persistente mediante la cabecera Mcp-Session-Id. Este diseño funcionaba en entornos locales, pero generaba cuellos de botella al escalar servidores en clústeres de Kubernetes o detrás de balanceadores de carga en la nube, ya que requería sesiones persistentes (sticky sessions).
Cambios introducidos por el núcleo sin estado
Eliminación del handshake y la sesión
Se retiraron la fase initialize y la cabecera Mcp-Session-Id.
Peticiones autocontenidas
Cada solicitud JSON-RPC incluye toda la información necesaria -versión del protocolo, identidad del cliente y banderas de capacidad- dentro de un objeto _meta.
Enrutamiento por cabeceras
Las peticiones HTTP incorporan las cabeceras Mcp-Method y Mcp-Name, que permiten a balanceadores de carga y pasarelas de seguridad enrutar el tráfico sin analizar el cuerpo JSON.
Caché eficiente
Las respuestas a catálogos de herramientas y recursos incorporan los campos ttlMs y cacheScope, lo que reduce el tráfico innecesario en la red.
Comparativa y Listado de Recursos, SDKs y Extensiones Clave
Para construir e integrar servidores MCP de forma profesional resulta necesario conocer las herramientas del ecosistema oficial y las extensiones desarrolladas por la comunidad.
Recursos, SDKs y extensiones del ecosistema MCP
| Componente / Recurso | Lenguaje / Soporte | Uso Principal | Características Clave |
|---|---|---|---|
| @modelcontextprotocol/server | TypeScript (Node.js/Bun) | Creación de Servidores MCP | Registro con Zod/Standard Schema, soporte STDIO y HTTP. |
| mcp (SDK v2) | Python 3.10+ | Servidores y Clientes MCP | Decoradores sintácticos (@mcp.tool()), tipado nativo. |
| MCP Inspector (mcp dev) | CLI / Web UI | Depuración y Pruebas | Interfaz gráfica interactiva para probar herramientas y validar JSON-RPC. |
| MCP Tasks (SEP-2663) | Extensión Oficial | Operaciones Asíncronas | Asignación de taskId, sondeo (tasks/get) y estados duraderos. |
| MCP Apps (SEP-1865) | Extensión Oficial | UIs Interactivas en Chat | Renderizado de HTML/JS en un iFrame aislado dentro del cliente. |
| Context-Aware MCP (CA-MCP) | Arquitectura de Investigación | Coordinación Agéntica | Memoria compartida (Shared Context Store) que reduce llamadas al LLM. |
Listado de SDKs Oficiales
El ecosistema de MCP cuenta con bibliotecas mantenidas oficialmente por la comunidad y por empresas patrocinadoras.
SDKs oficiales del ecosistema MCP
-
TypeScript SDK (@modelcontextprotocol/server y @modelcontextprotocol/client)ofrece soporte modular para Node.js, Bun y Deno, junto con adaptadores middleware para Express, Fastify y Hono.
-
Python SDK (mcp v2.x)utiliza type-hints y docstrings de Python para generar automáticamente los esquemas JSON de las herramientas sin código repetitivo.
-
Go SDK y C# SDKproporcionan soporte nativo para entornos compilados de alto rendimiento en sistemas empresariales.
Las Nuevas Extensiones Oficiales: MCP Tasks (SEP-2663) y MCP Apps (SEP-1865)
Para mantener el núcleo del protocolo ligero y sin estado, las funciones avanzadas se organizan mediante un marco de extensiones.
En los flujos de trabajo tradicionales, las herramientas eran síncronas: si una consulta tardaba varios minutos en procesarse -compilaciones de código o procesamiento de video, por ejemplo-, la conexión sufría un timeout. La extensión Tasks (io.modelcontextprotocol/tasks) introduce un patrón asíncrono dirigido por el servidor.
Ciclo de vida de una tarea con MCP Tasks
Generación del taskId
El servidor genera de inmediato un objeto con un identificador duradero (taskId) y un estado inicial working.
Sondeo periódico
El cliente consulta el estado de la tarea mediante el método tasks/get.
Confirmación intermedia
Si la tarea requiere intervención humana, cambia al estado input_required y el cliente envía datos mediante tasks/update.
Estado terminal
La tarea alcanza un estado inmutable: completed, failed o cancelled.
La extensión Apps (io.modelcontextprotocol/apps) permite a los servidores definir interfaces de usuario interactivas en HTML y JavaScript que se renderizan dentro de la ventana de chat del cliente. Estas interfaces se cargan en un iFrame aislado (sandboxed) para evitar accesos no autorizados al DOM del host o a las cookies, y se comunican de forma bidireccional mediante mensajes JSON-RPC a través de postMessage.
Innovaciones de Investigación: Context-Aware MCP (CA-MCP)
Investigaciones académicas de la Universidad de Chicago dieron lugar a Context-Aware MCP (CA-MCP). En el modelo tradicional, el modelo de lenguaje central actúa como un orquestador que interviene en cada paso intermedio, lo que satura la ventana de contexto y genera cuellos de botella. CA-MCP introduce un Shared Context Store (SCS), una memoria compartida centralizada: el modelo central se limita a la planificación inicial y al resumen final, mientras los servidores MCP funcionan como reactores autónomos que leen y escriben en esa memoria.
Los experimentos registraron una reducción del tiempo de ejecución de entre 67,8% y 73,5% con CA-MCP, junto con un recorte del 60% en las llamadas al modelo central.
Integración en Plataformas de Automatización (n8n)
Plataformas de automatización sin código como n8n incorporaron soporte para servidores MCP mediante nodos de la comunidad (n8n-nodes-mcp). Esto permite conectar un agente de inteligencia artificial, dentro de un flujo de trabajo, a múltiples servidores MCP, entre ellos Airtable, GitHub o Gmail. El agente utiliza la herramienta listTools para identificar qué operaciones están disponibles y executeTool para llevarlas a cabo.
Preguntas Frecuentes sobre MCP (Sección de FAQ)
¿Qué riesgos de seguridad existen al utilizar servidores MCP?
Investigaciones de OX Security y de la Cloud Security Alliance documentaron fallas de inyección de comandos en el transporte STDIO cuando las descripciones no se validan, así como vulnerabilidades de Tool Poisoning -un servidor malicioso inyecta instrucciones ocultas en las descripciones de las herramientas para manipular el razonamiento del modelo- y ataques de Rug Pull, que consisten en la modificación silenciosa del comportamiento de una herramienta previamente aprobada.
¿Cuál es la diferencia entre un Tool y un Resource en MCP?
Un tool es una acción interactiva con efectos secundarios que el modelo de inteligencia artificial ejecuta de forma autónoma tras validar los parámetros de entrada. Un resource es un conjunto de datos estático de solo lectura -un archivo o un documento de configuración, por ejemplo- expuesto mediante una URI para alimentar el contexto del cliente.
¿Cómo se manejan las tareas de larga duración que superan los tiempos de espera?
La extensión MCP Tasks (SEP-2663) resuelve este escenario. En lugar de bloquear la conexión HTTP, el servidor devuelve una respuesta con un taskId duradero; el cliente realiza sondeos periódicos mediante tasks/get y suministra las entradas requeridas con tasks/update sin perder el progreso de la tarea.
¿Qué clientes de IA ofrecen el mejor nivel de seguridad en la ejecución de MCP?
Un estudio empírico que evaluó siete clientes de inteligencia artificial expuestos a ataques de tool poisoning identificó a Claude Desktop y Cline como los más seguros, gracias a sus políticas de validación estricta y a las guías éticas integradas. Los clientes con permisos de sistema de archivos implícitos y sin filtrado visual resultaron vulnerables a la extracción no autorizada de credenciales.
Conclusión: El Futuro del Protocolo de Contexto en el Ecosistema Agéntico
El Model Context Protocol evolucionó con rapidez: pasó de ser una herramienta de uso local a convertirse en el estándar de conectividad distribuida para la inteligencia artificial. Al desacoplar la provisión de datos de la inferencia del modelo, simplificó el desarrollo de sistemas agénticos escalables y modulares -aunque esa misma apertura, como muestran los hallazgos sobre tool poisoning y ataques de rug pull, exige controles de seguridad que todavía están madurando.
Con la consolidación de MCP, la adopción de arquitecturas sin estado, asi como la expansión de extensiones como MCP Tasks y MCP Apps, el protocolo se posiciona como una pieza central del desarrollo de software agéntico. Comprender sus primitivas, aplicar las prácticas de seguridad documentadas y diseñar servidores bien estructurados se perfila como una competencia que todo equipo de ingeniería de IA deberá incorporar, no como una opción secundaria.
¿Te gustó este artículo? ¡Compártelo y suscríbete!
