Por qué el Model Context Protocol cambia las reglas del juego para los agentes de IA
Si trabajas con modelos de lenguaje, seguro que te ha pasado: tienes un LLM increíblemente capaz pero encerrado en su burbuja. Quieres que consulte tu Drive, que cree un ticket en el CRM o que lance un despliegue, pero cada integración es un proyecto a medida. Un adaptador distinto para cada herramienta, un formato diferente para cada API.
El Model Context Protocol (MCP) nació para resolver exactamente eso. Es un estándar abierto, impulsado por Anthropic y adoptado por un ecosistema creciente, que define un idioma común entre aplicaciones de IA y las herramientas o fuentes de datos que necesitan usar.
Eso es todo. Estas 20 líneas convierten cualquier API en una herramienta que cualquier agente de IA compatible con MCP puede descubrir y usar de forma autónoma. FastMCP genera automáticamente el esquema, la validación y la documentación a partir de la función Python y su docstring.
Qué es el MCP (y por qué lo llaman el USB-C de la IA)
La analogía es sencilla: antes del USB-C, cada fabricante tenía su propio conector. El MCP hace lo mismo con la IA: en lugar de fabricar un cable distinto para cada servicio, define un único protocolo para que cualquier host (la aplicación que aloja al modelo, como Claude Desktop o Cursor) se conecte a cualquier servidor MCP (un servicio que expone datos o capacidades).
Visión general: aplicaciones de IA (izquierda) conectadas a fuentes de datos y herramientas (derecha) a través del protocolo MCP. Fuente: modelcontextprotocol.io
El protocolo estandariza tres tipos de interacción, cada uno con un rol distinto:
- Herramientas (Tools): el modelo puede ejecutar acciones: crear un ticket, lanzar un build, hacer una búsqueda. Es la primitiva más potente y la que más se usa.
- Recursos (Resources): el modelo puede leer datos: archivos, registros de base de datos, documentos. Funcionan como un sistema de lectura bajo demanda.
- Prompts: plantillas predefinidas que guían al modelo en tareas específicas. Es la primitiva menos extendida por ahora, pero útil para flujos repetitivos.
El orden no es casual: las Tools son el motor principal de MCP, los Resources aportan contexto y los Prompts son un complemento útil pero secundario.
Arquitectura: Host, Client y Server
La arquitectura de MCP tiene tres capas bien diferenciadas:
- Host: la aplicación que el usuario ve y con la que interactúa (Claude Desktop, Cursor, VS Code con Copilot…). Aloja al modelo y gestiona la experiencia.
- Client: un componente dentro del host que mantiene una conexión 1:1 con un servidor MCP concreto. El host puede tener varios clients simultáneos.
- Server: el proceso que expone herramientas, recursos y/o prompts. Puede correr en local (mismo equipo) o en remoto (por Internet).
Esta separación es importante porque permite que un mismo host conecte simultáneamente con múltiples servidores MCP, por ejemplo, uno para Google Drive, otro para Jira y otro para tu base de datos interna sin que unos interfieran con otros.
Cómo se comunican: los transportes
MCP define dos transportes oficiales:
- Stdio: para servidores locales. El host lanza el servidor como un subproceso y se comunican por entrada/salida estándar. Es lo más sencillo de configurar.
- Streamable HTTP: para servidores remotos. Un único endpoint HTTP que soporta tanto peticiones simples como streaming mediante Server-Sent Events cuando es necesario. Incluye gestión de sesiones y normalmente se combina con OAuth para autorización.
El transporte anterior basado en SSE puro fue reemplazado en la especificación de marzo de 2025 por Streamable HTTP, que es más simple, flexible y compatible con infraestructura HTTP estándar.
MCP frente a APIs tradicionales
Una pregunta legítima es que, si ya tengo APIs REST, ¿para qué necesito MCP?. La diferencia no está en lo que conectan, sino en para quién están diseñados. Las APIs están pensadas para que un desarrollador las integre manualmente y MCP está pensado para que un agente de IA descubra y use herramientas de forma autónoma.
De hecho, la mayoría de servidores MCP llaman a APIs existentes por debajo. MCP no las sustituye, las hace enchufables para agentes, estandarizando el contrato de descubrimiento, invocación y respuesta.
| API REST clásica | MCP | |
| Diseñado para | Desarrolladores humanos | Agentes de IA |
| Descubrimiento | Documentación externa (Swagger, docs) | Automático: el agente lista tools/resources |
| Integración | Endpoint a endpoint, a medida | Estandarizada: un host compatible conecta cualquier server |
| Semántica | Libre (cada API define su contrato) | Compartida: tool, resource, prompt con esquemas claros |
| Estado de sesión | Gestionado por la aplicación | Negociación de capacidades a nivel de protocolo |
| Madurez | Décadas de ecosistema, tooling robusto | Emergente (nov. 2024), crecimiento rápido |
Seguridad: lo que MCP exige (y lo que no garantiza)
Si conectas un agente a herramientas con poder real (leer archivos, modificar producción, mover dinero) hay riesgo real. Y aquí viene un punto importante: MCP no es seguro por defecto. El protocolo define principios claros de seguridad, pero delega la implementación en cada servidor y host. Esto significa que la seguridad real depende de quién construye cada pieza.
Los principios que el protocolo establece como innegociables son:
- Consentimiento explícito: el usuario debe autorizar las acciones sensibles antes de que se ejecuten. Un agente no debería poder borrar una base de datos sin que tú lo apruebes.
- Mínimo privilegio: cada servidor solo debe tener acceso a lo estrictamente necesario. Si tu server de Jira solo necesita crear tickets, no debería poder leer tus emails.
- Control de combinaciones: el riesgo real suele aparecer al combinar herramientas. Una tool que lee archivos + otra que escribe en Git = una vía para exfiltrar código si no hay controles.
Más allá de estos principios, hay riesgos específicos del ecosistema MCP que conviene conocer: la posibilidad de tool poisoning (un servidor malicioso que describe sus herramientas de forma engañosa para manipular al modelo) y la inyección de instrucciones a través de los resultados que un tool devuelve al agente. Ningún protocolo elimina estos riesgos por completo, la defensa está en capas: validación, sandboxing y supervisión humana.
De hecho, la seguridad no es solo prevenir acciones no autorizadas, también es saber qué está pasando. MCP incluye un mecanismo de logging estructurado en la spec y hay una propuesta activa para integrar OpenTelemetry de forma nativa, permitiendo trazas distribuidas de extremo a extremo (desde la petición del usuario hasta la ejecución del tool, pasando por el LLM).
En la práctica, herramientas como Langfuse ya permiten propagar contexto de tracing a través del campo _meta de MCP, Datadog ofrece un MCP Server en preview que permite a los agentes consultar directamente logs, métricas y trazas, y FastMCP 3.0 incluye integración nativa con OpenTelemetry. Es un área en evolución rápida, pero la dirección es clara: en producción, no basta con controlar lo que un agente puede hacer, necesitas también ver lo que está haciendo.
Agentes como servidores MCP: la composición que importa
Aquí es donde MCP se pone realmente interesante. Un agente no solo puede consumir servidores MCP, también puede exponerse como uno. Esto significa que un agente especializado (por ejemplo, uno que sabe generar informes financieros) puede ser llamado por otro agente exactamente igual que se llama a una herramienta.
Anthropic lo planteó desde el diseño inicial del protocolo, y OpenAI ya lo ha llevado a la práctica con un ejemplo concreto: ejecutar Codex CLI como servidor MCP y orquestarlo desde el Agents SDK en flujos multi-agente. No es que OpenAI haya adoptado MCP como su estándar (mantienen su propio ecosistema con Responses API y function calling nativo), pero el hecho de que lo soporten como opción complementaria dice mucho sobre hacia dónde va la industria.
Este patrón de agente como server MCP ofrece tres ventajas concretas:
- Modularidad: cada agente especializado se puede cambiar, actualizar o versionar sin romper el host, siempre que mantenga su interfaz MCP.
- Gobernanza: puedes controlar permisos y visibilidad por agente: qué expone, a quién, con qué consentimientos. Cada agente es una frontera de seguridad.
- Composición: un agente orquestador puede encadenar sub-agentes igual que encadena herramientas, lanzarlos en paralelo y consolidar respuestas de dominios distintos. Piensa en un orquestador que conecta un agente de documentación, un agente de CRM y un agente de reporting, los ejecuta simultáneamente y sintetiza los resultados, como si delegara llamadas a funciones concurrentes.
Y cuando los agentes necesitan hablar entre ellos: A2A
MCP resuelve cómo un agente accede a herramientas y datos. Pero ¿qué pasa cuando dos agentes necesitan colaborar como iguales, no como herramienta y consumidor? Ahí entra el Agent-to-Agent Protocol (A2A), un protocolo abierto impulsado por Google y donado a la Linux Foundation en junio de 2025.
La idea: cada agente publica una «Agent Card» con sus capacidades, y otros agentes pueden descubrirlo, negociar modalidades (texto, audio, vídeo) y colaborar en tareas que pueden durar horas. A2A no compite con MCP, lo complementa.
Hoy A2A va por la v0.3, con soporte de más de 150 organizaciones (Adobe, Salesforce, ServiceNow, SAP…) y SDKs para Python y TypeScript. Su adopción real aún va por detrás de MCP, pero el potencial de agentes especializados de distintos proveedores trabajando en paralelo e intercambiando contexto entre sí es enorme. Es el siguiente paso lógico del ecosistema.
Quién lo usa hoy
MCP no es solo teoría. A día de hoy, estos son algunos de los hosts y clientes que lo soportan:
- Claude Desktop y Claude Code (Anthropic): los primeros hosts nativos del protocolo.
- Cursor y Windsurf: IDEs de nueva generación con soporte MCP integrado para conectar herramientas de desarrollo.
- VS Code + GitHub Copilot: soporte MCP en modo Agent.
- Codex CLI (OpenAI): puede actuar tanto como cliente MCP (consumir herramientas) como servidor MCP (ser invocado por otros agentes).
En el lado de los servidores, el ecosistema crece rápido: hay servidores MCP para Google Drive, Slack, GitHub, Jira, bases de datos SQL, Notion, Stripe y decenas más. Muchos son comunitarios y open source.
Hacia dónde va esto
MCP es todavía un protocolo joven, su primera versión es de noviembre de 2024, y está evolucionando rápido. La especificación se actualiza con frecuencia, el ecosistema de servidores crece cada semana y cada vez más herramientas lo adoptan como estándar de integración.
Lo que está claro es la dirección: los modelos de lenguaje van a dejar de ser chatbots encerrados para convertirse en agentes que actúan en el mundo real. Y para que eso funcione de forma segura, escalable y sin reinventar la rueda cada vez, necesitamos estándares como MCP.
La pregunta para las empresas ya no es si sus sistemas se integrarán con agentes de IA, sino cuándo. Y quien tenga sus herramientas listas para enchufarse tendrá ventaja.
Por eso en Medalla Technology ayudamos a las empresas a entender y adoptar estas tecnologías de forma práctica y segura. Si quieres explorar cómo MCP puede integrarse en tu organización, hablemos.