Qué es MCP en una frase: el Model Context Protocol es un estándar abierto que Anthropic publicó en noviembre de 2024 para que cualquier modelo de IA se conecte a tus herramientas y a tus datos por un mismo cable, en lugar de un conector a medida por cada integración. Baja el coste de conectar. No baja el coste de tener un proceso malo ni de tener los datos sucios. Esa es toda la tesis — el resto del artículo la desarrolla sin humo.
Qué es MCP (Model Context Protocol)
MCP significa Model Context Protocol. Es un protocolo abierto —especificación y código públicos— que define una forma estándar de que una aplicación de IA pida contexto (ficheros, registros de una base de datos, mensajes) e invoque acciones (herramientas, funciones) sobre sistemas externos. La analogía que todo el mundo repite es "el USB-C de la IA": un mismo enchufe para todo. Sirve para entenderlo y engaña si te la crees entera, porque un enchufe no arregla lo que hay al otro lado del cable. La especificación y los SDKs oficiales están en la documentación de MCP.
El problema real que resuelve: la integración N×M
Antes de MCP, conectar cada modelo con cada herramienta era un conector a medida. Con N modelos y M herramientas, acabas con N×M integraciones que mantener, cada una con su formato, su autenticación y su forma de romperse. MCP convierte ese N×M en N+M: cada herramienta expone un servidor MCP una vez, cada modelo habla MCP una vez, y en medio hay un contrato común. No es magia — es lo mismo que hizo un cargador universal por el cajón de cables. El ahorro es de integración, no de criterio.
| Eje | Sin MCP (conectores a medida) | Con MCP |
|---|---|---|
| Coste de integrar | N×M conectores propios | N+M (un protocolo) |
| Formato | Uno distinto por herramienta | JSON-RPC estándar |
| Mantenimiento | Cada cambio rompe un conector | El contrato absorbe el cambio |
| Reutilización | Casi nula entre proyectos | Un servidor sirve a varios clientes |
| Lo que NO resuelve | El proceso y los datos | El proceso y los datos |
Cómo funciona: cliente, servidor y tres primitivas
La arquitectura es cliente-servidor, inspirada en el Language Server Protocol que ya usan los editores de código. La aplicación de IA actúa de cliente MCP y abre una conexión con uno o varios servidores MCP, que exponen capacidades del mundo real. Los mensajes viajan en JSON-RPC 2.0 sobre distintos transportes. Lo que un servidor puede ofrecer se reduce a tres primitivas:
- Tools (herramientas): acciones que el modelo puede invocar —crear un ticket, consultar un pedido, mover una fila—. Es lo que la mayoría entiende por "el agente hace cosas".
- Resources (recursos): datos que el modelo puede leer como contexto —un documento, el resultado de una consulta, un fichero—. Lectura, no acción.
- Prompts: plantillas de interacción reutilizables que el servidor ofrece al cliente para tareas repetidas.
Hay SDKs oficiales en TypeScript, Python, Java, Kotlin y C#, así que montar un servidor MCP hoy es cuestión de horas, no de semanas. Y ahí está la trampa cómoda: como montarlo es fácil, es tentador creer que el trabajo está hecho cuando en realidad acaba de empezar.
Quién lo ha adoptado (y por qué eso importa)
MCP dejó de ser cosa de Anthropic muy rápido. A lo largo de 2025 lo adoptaron de forma nativa clientes de OpenAI, Google y Microsoft, entre muchos otros, y a finales de año Anthropic donó el protocolo a una fundación bajo el paraguas de la Linux Foundation con esos mismos actores como miembros fundadores (resumen del primer aniversario). Que un estándar lo sostengan competidores en vez de un solo dueño es justo lo que lo hace apostable: no dependes de que a una empresa le siga interesando. Para una empresa que decide dónde invertir, esa gobernanza compartida pesa más que cualquier demo.
Qué cambia de verdad para los agentes de empresa
Lo concreto: el pegamento entre tu agente y tus sistemas deja de ser un proyecto de integración por cada herramienta y pasa a ser una pieza reutilizable. Conectar un agente a tu CRM, a tu ERP o a tu base de datos deja de justificar por sí solo un presupuesto de cinco cifras. Eso es real y es bueno. Lo desarrollamos con detalle en la guía de conectar un agente de IA con tu CRM, donde el cable importa menos que decidir qué puede tocar el agente y qué no.
Pero conectar no es lo mismo que construir. Un servidor MCP te da el acceso; sigue faltando el agente que decide bien qué hacer con ese acceso, con sus guardarraíles, sus evals y su humano en el bucle donde el criterio pesa. Esa parte —la que de verdad hace el trabajo— no la resuelve el protocolo, y es la que desglosamos en cómo crear un agente de IA que funcione en producción.
Qué NO arregla un servidor MCP
Aquí es donde el entusiasmo se estrella contra el martes. Un servidor MCP conecta el modelo a tus datos exactamente como están. Si el proceso que hay detrás es un caos, MCP te da un caos accesible por API — más rápido, no mejor. Estos son los tres frentes que el protocolo no toca:
- El proceso. Si nadie ha decidido cómo se hace el trabajo hoy —quién lo toca, dónde se atasca, con qué criterio se decide—, MCP solo automatiza el desorden. Ese diagnóstico es la mitad del trabajo, y es lo que separa automatizar un proceso con agentes de comprar tecnología y rezar.
- Los datos. Un servidor MCP sobre datos duplicados, sin dueño y sin definición sirve respuestas seguras de sí mismas y equivocadas. La calidad del dato no la pone el protocolo; la pones tú antes.
- La gobernanza. Qué puede leer el agente, qué puede escribir, quién responde cuando se equivoca. MCP mueve el contexto; no decide los permisos por ti. Sin esa capa, un enchufe universal es también un agujero universal.
Cuándo tiene sentido montar un MCP (y cuándo es teatro)
- Tienes el proceso mapeado. Sabes qué tarea concreta va a tocar el agente y qué métrica debería moverse. Si no cabe en dos frases, todavía no toca protocolo.
- Vas a reutilizar la conexión. Un servidor MCP rinde cuando varios agentes o equipos lo van a usar. Para una integración única y de usar y tirar, a veces un conector directo es más honesto.
- Tienes la gobernanza decidida. Permisos, límites y responsable antes de abrir el cable, no después del primer susto.
- No lo montas para la demo. Si el objetivo es enseñar en una reunión que "ya hablamos MCP", eso es teatro con nombre técnico. El sistema se juzga un martes cualquiera, corriendo solo, no en la sala.
Dicho de otra forma: MCP es una muy buena noticia para quien ya tiene el trabajo hecho por dentro, y una trampa cara para quien creía que el cable era el problema. Nosotros usamos MCP donde ahorra semanas de integración, y no lo usamos para maquillar un proceso que aún no existe. Si el dolor es conectar la IA a los sistemas que ya usas y dejarlo midiendo, eso es infraestructura de IA para empresa; si es un caso concreto —por ejemplo meter IA en HubSpot sin romper nada—, mira IA para HubSpot. El protocolo es el medio. El trabajo, como siempre, es lo que se cobra.