MCP sí es útil: como contrato de integración, no como cerebro
El protocolo estandariza cómo se enchufan modelos y herramientas. No arregla la búsqueda, el contexto compartido ni la seguridad que el hype le cuelga.
En este artículo
El Cuñado dice: MCP es el USB de la IA. Enchufas el agente al CRM, al correo y al wiki, y de golpe entiende la empresa, busca mejor que tu equipo de datos y no se pasa de frenada con los permisos.
La realidad es: MCP (Model Context Protocol) es un protocolo abierto que estandariza la integración entre aplicaciones LLM y fuentes de datos y herramientas externas. Tres roles: hosts (las apps con LLM que inician la conexión), clients (conectores dentro del host) y servers (servicios que aportan contexto y capacidades). La comunicación usa mensajes JSON-RPC 2.0. Encima, la especificación define conexiones con estado (stateful) y negociación de capacidades entre servidor y cliente. Consta en la versión 2025-11-25 de modelcontextprotocol.io.
Por qué importa saberlo: mezclar el enchufe con el cerebro es la forma más rápida de comprar humo con factura de ingeniería.
Lo que el contrato sí recorta
Atolio, en un análisis del 23 de abril de 2026, pone el valor donde está: MCP ataca el lío N×M. N sistemas que antes pedían M integraciones a medida. Con una interfaz universal (autenticación, descubrimiento de tools y formato de respuesta estandarizados) un agente conecta con cualquier herramienta compatible. Los grandes proveedores de modelos se han alineado con el estándar.
Quien haya mantenido un conector distinto por cada modelo y cada SaaS conoce esa factura. Y no vale reducirlo a cuatro mensajes JSON. Sobre JSON-RPC 2.0 la spec monta ciclo de vida, negociación de capacidades y primitivas. Los servidores pueden exponer:
- Resources: contexto y datos
- Prompts: mensajes plantilla
- Tools: funciones que ejecuta el modelo
Los clientes pueden ofrecer a los servidores Sampling, Roots y Elicitation.
En diciembre de 2025 Anthropic donó el protocolo a la Agentic AI Foundation, bajo la Linux Foundation, el mismo modelo de gobernanza independiente que Kubernetes o Node.js. La comparativa de plataformas de agentes de AIMultiple, actualizada el 18 de agosto de 2026, sitúa la revisión más grande de MCP el 28 de julio de 2026. Qué cambió esa revisión no consta en las fuentes consultadas; el texto que sí podemos leer es el de noviembre de 2025.
La spec, Atolio y el movimiento de gobernanza coinciden en lo básico: hay un contrato común para enchufar. Difieren en el tono. La spec describe mecanismos. Atolio ya está midiendo lo que ese contrato no cubre cuando lo pones dentro de una empresa.
El techo lo marca la herramienta más floja
MCP no mejora la búsqueda empresarial. Atolio lo deja escrito: le da al modelo acceso al índice que ya tiene cada herramienta y hereda sus limitaciones nativas.
El techo de calidad del agente lo marca la herramienta más débil.
Es consecuencia estructural de una arquitectura federada, no un fallo que el ecosistema vaya a parchear con otra revisión del protocolo. Si tu wiki busca mal, el agente busca mal en el wiki. El JSON-RPC llega limpio. El ranking sigue siendo el de siempre. Quien haya montado un pipeline de RAG de PDF a respuesta ya sabe que el transporte no arregla un índice mediocre.
Hay un segundo agujero del mismo diseño. MCP está pensado para conexiones punto a punto independientes. No hay capa de contexto compartida entre fuentes. Cada servidor procesa su fragmento de la consulta en aislamiento. Sin un grafo de identidad y colaboración que cruce herramientas, los agentes devuelven resultados localmente correctos y contextualmente incompletos cuando la pregunta toca varios sistemas.
La spec y Atolio no se pisan. Una define el enchufe. La otra describe qué pasa cuando enchufas N silos y pretendes una respuesta de empresa.
SHOULD no es MUST
La propia especificación reconoce que no puede imponer sus principios de seguridad a nivel de protocolo. Solo recomienda (SHOULD) a los implementadores construir flujos de consentimiento y autorización, controles de acceso y protecciones de datos. Si el host se salta el consentimiento, el protocolo no tiene policía.
Las tools se tratan como ejecución arbitraria de código. Las descripciones de comportamiento (anotaciones) se consideran no fiables salvo que vengan de un servidor de confianza. El host debe obtener consentimiento explícito del usuario antes de invocar cualquier herramienta. Eso no es un sello de producción. Es una advertencia escrita por quienes diseñaron el cable.
El análisis de sshh.io, de abril de 2025, señala un agujero que esa misma flexibilidad deja abierto: rug pulls. Un servidor MCP puede redefinir dinámicamente nombres y descripciones de herramientas después de que el usuario las haya confirmado. Para un catálogo que cambia, es práctico. Para un servidor que deja de ser de fiar, o nunca lo fue, es trivialmente explotable. Confirmaste "exportar informe". El nombre sigue. La función ya no es esa.
Más conexiones estándar también significan más superficie. El contrato no sustituye confianza en el servidor ni un flujo de consentimiento que alguien tiene que construir fuera del protocolo.
Un equipo de Princeton midió precisión y fiabilidad en 15 modelos con GAIA y τ-bench, con lanzamientos de principios de 2024 a mediados de 2026, y repitió cada tarea varias veces. Unos 24 meses de mejoras de precisión produjeron mejoras mínimas de fiabilidad; los autores lo atribuyen a todo el sector, no a un proveedor. Lo recoge AIMultiple. MCP no es el objeto de ese experimento. Da igual: un formato común para tools no arregla que el modelo falle distinto cada vez que le pides lo mismo.
El conector no es el trabajo
MCP sirve cuando dejas de soldar integraciones a medida y hablas un dialecto común: descubrimiento, formato, ciclo de vida.
Si estás comprando un agente para la empresa, "habla MCP" es el requisito mínimo de fontanería. Lo que decide el resultado es el índice detrás de cada server, quién implementa de verdad el consentimiento que la spec solo recomienda, y cómo resolvéis las preguntas que cruzan dos sistemas.
Si evalúas el producto por el conector, estás midiendo el enchufe.
Preguntas frecuentes
¿Qué es MCP y para qué sirve realmente?
MCP (Model Context Protocol) es un protocolo abierto que estandariza cómo una aplicación LLM se conecta con datos y herramientas externas. Define hosts, clients y servers, habla JSON-RPC 2.0 y añade conexiones con estado y negociación de capacidades. Sirve para unificar autenticación, descubrimiento de tools y formato de respuesta, de modo que un agente hable con cualquier servidor compatible. No hace que el modelo entienda mejor los datos.
¿MCP mejora la búsqueda en la empresa?
No. Según Atolio, MCP da al modelo acceso al índice de búsqueda que ya tiene cada herramienta y hereda sus límites. El techo de calidad lo marca la herramienta más débil, consecuencia de una arquitectura federada punto a punto. Si la pregunta cruza varios sistemas, además falta contexto compartido: cada servidor responde su fragmento y el conjunto queda incompleto.
¿El protocolo MCP garantiza que las tools se usen con seguridad?
No. La especificación admite que no puede imponer seguridad a nivel de protocolo: solo recomienda (SHOULD) consentimiento, autorización y controles de acceso. Trata las tools como ejecución de código arbitrario y pide consentimiento explícito antes de invocarlas. Un servidor puede además cambiar nombres y descripciones de tools después de que el usuario las haya aprobado.
¿MCP es solo JSON-RPC?
No. Sobre JSON-RPC 2.0 la spec define conexiones con estado, negociación de capacidades y primitivas: Resources, Prompts y Tools en el servidor; Sampling, Roots y Elicitation en el cliente. Eso es el contrato de integración. Lo que no aporta es una capa de contexto compartido entre servidores ni una mejora del índice de cada herramienta.
Fuentes · 5
Aprobado por El Búfalo, editor humano responsable.