En el mundo vertiginoso de la inteligencia artificial y la interacción entre grandes modelos de lenguaje (LLMs) y el entorno, surge la necesidad de protocolos estandarizados que faciliten la comunicación eficiente y poderosa entre agentes inteligentes y los múltiples sistemas que les rodean. El Protocolo de Contexto de Modelo (MCP, por sus siglas en inglés) pretende ser la respuesta a esa necesidad, ofreciendo un marco para que los modelos de lenguaje funcionen como agentes capaces de interactuar con archivos, bases de datos, servicios web y otras herramientas externas. Sin embargo, un análisis crítico de MCP revela importantes aspectos que ponen en entredicho su usabilidad, eficiencia y sostenibilidad a largo plazo en un campo tan dinámico y demandante. MCP se conceptualiza como una especie de "USB-C para aplicaciones de inteligencia artificial", permitiendo estandarizar cómo distintas AI pueden conectarse a múltiples fuentes de datos y herramientas. Esta comparación, aportada por Anthropic —la empresa que impulsa desde sus bases el desarrollo del protocolo—, resume muy bien la aspiración de MCP: ser el conector universal para agentes inteligentes en el ecosistema tecnológico.
Sin embargo, a pesar del noble objetivo y la creciente adopción de MCP por parte de actores clave, la implementación práctica y la ingeniería detrás del protocolo apunta a serios problemas. Una de las quejas más contundentes proviene de la falta de prácticas maduras de desarrollo y documentación profesional. Aunque grandes compañías invierten miles de millones en entrenar y ajustar sus modelos, termina pareciendo que la elaboración y el soporte del protocolo quedan en manos de equipos menos experimentados, dejando documentación deficiente con escasa orientación para desarrolladores reales que intentan implementar MCP. Esta carencia genera frustración, malos entendidos y reduce la adopción real y efectiva. Desde el punto de vista técnico, el protocolo se basa en JSON-RPC con métodos predefinidos orientados al uso conjunto con un modelo de lenguaje.
En cuanto a los canales de transporte para la comunicación, MCP propone esencialmente tres alternativas: la comunicación a través de stdio (entrada y salida estándar), HTTP con Server-Sent Events (SSE), y una variante llamada Streamable HTTP. De estas, la implementación recomendada y más clara parece ser stdio, que aprovecha tubos estándar entre procesos para mandar y recibir mensajes JSON, reservando la salida de errores estándar para registro y depuración. Aunque el transporte por stdio es sencillo, liviano y compatible con la mayoría de sistemas, no está exento de críticas. Principalmente, empuja un uso bidireccional del stdio que no es habitual en los paradigmas estándar de Unix/Linux, donde a menudo se prefieren sockets o canales dedicados para comunicación simultánea y concurrente. No obstante, la simplicidad y promisorio funcionamiento "out-of-the-box" que ofrece stdio hace que muchos desarrolladores lo prefieran para comenzar rápido.
El apartado más controvertido quizá sea la implementación HTTP basada en SSE y la denominada Streamable HTTP. En lugar de elegir una solución ampliamente aceptada como WebSockets para lograr comunicación bidireccional en tiempo real entre cliente y servidor, MCP opta por emular funcionalidades similares sobre SSE, lo que complica el diseño y añade capas innecesarias de abstracción y manejo de estado. Lamentablemente, esta decisión no ha sido convincente para todos, y en muchos debates públicos se ha señalado que esta aproximación introduce una complejidad innecesaria y puede provocar problemas de escalabilidad y seguridad a medida que el protocolo se use en escenarios más complejos y distribuidos. Al adentrarse en la implementación práctica del servidor MCP —y la documentación cirugicamente escasa que lo acompaña— muchos desarrolladores se encuentran enfrentando la necesidad de revertir y deducir cómo debería comportarse realmente el protocolo. No hay ejemplos claros de cómo se desarrolla una conversación o flujo completo entre agente y cliente, lo que supone un empeño extra para cualquiera que quiera apoyar esta tecnología en su propia infraestructura.
Además, los ejemplos oficiales están llenos de dependencias y ecosistemas que no fácilmente se adaptan a entornos de trabajo profesionales, como ocurriría con las dependencias pesadas en Python o JavaScript, que tienden a causar problemas de incompatibilidades o incertidumbres. Otro punto fuerte de debate es el manejo del estado en la modalidad HTTP/SSE. El servidor debe mantener un complejo estado de sesiones persistentes que cruzan solicitudes HTTP y conexiones SSE, lo que exige mecanismos robustos de gestión y sincronización, y en muchos casos requiere la integración con colas de mensajes para responder eficazmente. Esta arquitectura afecta la tolerancia a fallos, la escalabilidad y abre la puerta a vulnerabilidades potenciales si no se maneja cuidadosamente.- En el plano de la seguridad, el protocolo presenta requisitos muy específicos y algo contradictorios en cuanto a la autorización.
Mientras que el transporte a través de HTTP está obligado a manejar OAuth2 y esquemas similares, la comunicación vía stdio puede obviar tales complicaciones y confiar en variables del entorno para la autenticación. Esta disparidad puede resultar confusa y no siempre justificable, ya que igual se requiere seguridad sólida sin importar el canal de comunicación. La diferencia también obliga a implementar infraestructuras más complejas y fragmentadas para un mismo servicio. Todas estas elecciones técnicas y organizativas hacen que MCP, en su estado actual, resulte forzar a la comunidad a pelear con decisiones de diseño que podrían haberse evitado o mejorado. Por ejemplo, la recomendación para emplear WebSockets habría proporcionado una solución nativa y extendida para la comunicación bidireccional sobre HTTP, que sería más simple de implementar, mantener y expandir, además de coincidir con las prácticas modernas y testeadas de la industria.
Es importante también examinar que MCP no es el único protocolo emergente en esta área. Recientemente, IBM lanzó el Agent Communication Protocol (ACP) y Google presentó Agent2Agent (A2A), que son alternativas orientadas a cómo exponer agentes a modelos de lenguaje o incluso interconectar múltiples agentes en redes más complejas. Sin embargo, estos protocolos parecen solaparse en muchos aspectos con MCP o incluso podrían considerarse extensiones o módulos adicionales dentro de un ecosistema construido sobre MCP. Las soluciones de IBM y Google aportan, en términos técnicos, una infraestructura de transporte posiblemente más sólida y mecanismos para descubrir agentes, áreas donde MCP podría mejorar mucho. De hecho, incluso IBM admite que ACP puede actuar como una herramienta complementaria integrada dentro de servidores MCP, sugiriendo que MCP podría convertirse en el estándar base con adaptaciones para abarcar nuevas necesidades.
A pesar de las dificultades, el sector parece apostar significativamente por MCP y su filosofía, dado que tiene la ventaja de ser agnóstico al transporte y abierto a implementar canales personalizados según la necesidad, fomentando la innovación y la adaptabilidad. Esto significa que el futuro podría ver nuevos enfoques, optimizaciones y protocolos refinados que rescaten la esencia de MCP pero mejoren su experiencia de uso, eficiencia y seguridad. Para avanzar, la comunidad debería dar prioridad a simplificar el protocolo, optimizar los casos de uso más comunes y evitar el exceso de complejidad con múltiples formas de llevar a cabo las mismas funciones. La calidad de la documentación y la presencia de SDKs robustos en lenguajes de alto desempeño y multiplataforma, como Go o Rust, son también puntos que deben ser activos para impulsar su adopción y éxito. La interoperabilidad, la seguridad coherente y la optimización para los entornos locales, de red o distribuidos deben guiar las siguientes versiones del protocolo.
En última instancia, el objetivo debe ser dotar a los modelos de lenguaje con agentes que puedan interactuar con el mundo de forma rápida, segura, y flexible, sin sacrificar la estabilidad ni la experiencia del desarrollador. En resumen, aunque MCP representa un paso audaz hacia la estandarización en la comunicación de agentes IA, el protocolo actual requiere ajustes y mejoras significativas antes de poder considerarse una solución industrial madura y confiable. La experiencia hasta ahora revela que, sin un enfoque más centrado en las buenas prácticas de ingeniería y la integración de tecnologías adecuadas como WebSockets, la adopción generalizada y la creación de ecosistemas sostenibles podrían verse comprometidas. Las alternativas como ACP y A2A y la posibilidad de crear transportes personalizados destacan que el área está lejos de asentarse, pero también que la colaboración y el refinamiento colectivo pueden llevar a una evolución prometedora para los agentes inteligentes en la inteligencia artificial.
