Una mirada crítica a MCP

• MCP(Model Context Protocol) proporciona una forma de integración estandarizada para que los LLM interactúen con el mundo exterior
• Recientemente han aparecido estándares similares como ACP de IBM y A2A de Google, y las implementaciones de MCP junto con las herramientas relacionadas están creciendo rápidamente
• Sin embargo, se señalan problemas de prácticas de ingeniería inmaduras, como confusión en el diseño, documentación insuficiente y falta de una especificación real del protocolo
• Los métodos de transporte propuestos actualmente, como HTTP+SSE y Streamable HTTP, aumentan la complejidad y los problemas de seguridad, y se recomienda usar WebSocket como alternativa
• Los protocolos más recientes están añadiendo inconsistencia y una complejidad excesiva en autorización y gestión de sesiones

---

Revisión de MCP y tendencias recientes

• MCP es un protocolo abierto creado para estandarizar cómo las aplicaciones proporcionan contexto a los modelos de lenguaje grandes (LLM)
• En el último mes, MCP ha surgido como un estándar clave para convertir a los LLM en agentes, y su uso e implementación se están expandiendo rápidamente
• Están apareciendo con rapidez estándares ortodoxos con objetivos similares, como ACP de IBM y A2A de Google

Problemas en las prácticas de ingeniería y en la especificación del protocolo

• En varios puntos se hace evidente el bajo nivel de implementación real y documentación
• Las grandes empresas tecnológicas invierten enormes recursos en el entrenamiento de modelos, pero sus SDK y documentación tienen baja calidad y generan confusión entre los usuarios
• MCP muestra problemas parecidos: parte de su diseño es poco razonable y faltan especificaciones, ejemplos y lineamientos

Debate sobre los protocolos de transporte

Método de transporte stdio

• Stdio es un método tradicional que conecta directamente en local al servidor MCP y al cliente mediante tuberías (stdout, stdin)
• Hay menos manejo complejo de sockets y menos problemas dependientes del sistema operativo, y permite una configuración del entorno sencilla con variables de entorno y flujos de entrada/salida

Métodos HTTP+SSE / Streamable HTTP

• Con la intención de adaptarse a la era web y responder también a entornos basados en HTTP, se adoptaron los métodos HTTP+SSE y Streamable HTTP
• Sin embargo, aunque buscan reemplazar a WebSocket, estos métodos terminan generando más ambigüedad, confusión de diseño y complejidad
• Como una misma sesión y conexión pueden crearse y cerrarse de varias formas, esto impone una gran carga sobre la gestión de estado y la seguridad del servidor

Dificultades en casos reales de implementación de servidores/clientes MCP

• Se notan claramente carencias de soporte en varios lenguajes, como la ausencia de un SDK oficial para Go
• La documentación y la especificación son poco claras, por lo que muchas veces hay que implementar mediante ingeniería inversa
• Aunque los servidores de ejemplo son en su mayoría de Python y JavaScript, aplicarlos en entornos de producción es difícil por problemas de dependencias y portabilidad
• Al implementar un servidor, SSE/Streamable HTTP intenta hacerse pasar por sockets, pero en la práctica es difícil mantener de forma consistente el estado de sesión y conexión, y se requiere infraestructura adicional como colas de mensajes

Estructura y problemas de HTTP+SSE y Streamable HTTP

Modo HTTP+SSE

• El cliente abre una sesión SSE con el servidor y, al hacer solicitudes de escritura a un endpoint separado, el servidor devuelve una respuesta 202 y envía la respuesta a través de la conexión SSE existente
• Se requiere mantener la sincronización de la conexión de sesión y del estado, pero este proceso está mal documentado y su complejidad operativa es muy alta

Modo Streamable HTTP

• La creación de sesión, la apertura de SSE y la entrega de respuestas se mezclan de varias maneras, por lo que un mismo flujo de solicitud~respuesta no mantiene consistencia
• La coexistencia de múltiples gestiones de estado y distintos endpoints y encabezados se convierte en un obstáculo serio para la implementación real y la escalabilidad

Implicaciones generales

• Junto con el aumento de la complejidad técnica, crecen la carga cognitiva y el mantenimiento para los desarrolladores, y surgen problemas de incompatibilidad y comportamiento impredecible entre distintas implementaciones de servidores y clientes
• El servidor debe rastrear todo el estado y la situación de las conexiones, y en entornos distribuidos se vuelve aún más difícil escalar de forma eficiente y sincronizar el estado

Implicaciones de seguridad

• Los métodos de conexión y sesión, variados y granulares, aumentan las vulnerabilidades de seguridad en la gestión de estado, como secuestro de sesión, ataques de repetición y denegación de servicio (DoS)
• Los múltiples puntos de entrada y formas de respuesta amplían la superficie de ataque y pueden permitir ocultar actividad maliciosa mediante flujos no previstos

Confusión en el protocolo de autorización

• La especificación actual aplica reglas inconsistentes, como exigir OAuth2 solo cuando el transporte es HTTP, mientras que en el transporte STDIO se permite usar variables de entorno de forma arbitraria
• Esto genera confusión y falta de lógica, por ejemplo al forzar una implementación compleja de OAuth2 únicamente para el transporte HTTP

Propuestas de mejora

• Se necesita simplificar hacia un solo protocolo JSON RPC, centrando los métodos de transporte de forma práctica únicamente en Stdio y WebSocket
• Lo deseable es mapear las variables del entorno Stdio a encabezados en HTTP, y la entrada y salida a los flujos bidireccionales de WebSocket, respectivamente
• Así se pueden eliminar el seguimiento innecesario de sesiones, la gestión de estado y una gran cantidad de manejo de excepciones
• WebSocket debería convertirse en la opción estándar para todo transporte basado en HTTP, y también puede resolver los complejos problemas de sincronización de estado

Comparación con protocolos alternativos y tendencias del mercado

• ACP de IBM y A2A de Google ofrecen un diseño de transporte más simple y funciones de descubrimiento de agentes en términos de interoperabilidad entre agentes
• Pero, en esencia, en su mayoría pueden integrarse como herramientas separadas dentro del entorno de construcción de MCP
• Como la continua aparición de nuevos protocolos puede derivar en una proliferación de estándares, priorizar la simplicidad del transporte es importante para el crecimiento de la industria

[GN⁺]

Opiniones en Hacker News

• Estoy convencido de que la razón por la que la documentación escrita por los vendors de LLM es tan confusa es porque la están escribiendo usando LLM, y ese es un enfoque muy malo; usar LLM para trabajo de especificación es mucho peor que usarlos para redactar buena documentación. El proceso mismo de escribir una especificación es la parte clave: importa que diseñadores humanos detecten cuidadosamente fallas y vacíos y cubran casos. En la especificación de MCP se nota la falta de ese tipo de reflexión humana; ese estilo plano tan característico, la dispersión y la estructura basada en listas son exactamente el tipo de resultado que produce un LLM.
  • En el caso de la documentación de DeepSeek, el problema más bien es que tiene demasiados errores de ortografía y gramática. Es muy raro que una empresa que trabaja con lenguaje todo el día y que incluso tuvo en algún momento el mejor LLM en inglés del mundo no pueda producir documentación con un nivel de profesionalismo que se vea realmente profesional.
  • Yo también siento fuertemente que esta especificación fue escrita por un LLM. Toda la evidencia apunta a eso. Sospecho que la mayoría de estos productos ya están hechos para presumirles a los inversionistas, de cara a una IPO, que promedian el resultado aparentemente más plausible.
  • Si eso es cierto, sería realmente una lástima. Anthropic tiene gente muy talentosa, así que es triste ver que algo así ocurra en un componente central de un ecosistema importante.
  • Recién ahora se me ocurre que los vendors de AI coding podrían tener un incentivo para hacer la documentación deliberadamente incomprensible. Si logran generar código que los humanos no entiendan y que solo su propia IA pueda interpretar, podrían volver a los usuarios completamente dependientes de su servicio específico de IA. Si en dos años no logran reemplazar por completo a los programadores reales, esta estrategia terminará por hacer desaparecer a los consumidores y hundir también su propio mercado. Al final solo quedaría un enorme montón de código imposible de traducir entre humanos e IA.
  • Cuando leo prosa escrita por LLM, no creo que el problema de perder la concentración sea solo mío; siento que ese texto repetitivo y sin contexto que producen las máquinas no contiene pensamiento profundo y cada vez genera más fatiga emocional. Y cuando un LLM como este termina escribiendo incluso especificaciones técnicas, inevitablemente se cuelan contenidos que ni el propio autor entiende. Eso me preocupa cada vez más.
  • La documentación de DeepSeek, en general, no me pareció tan mala. Se siente hecha rápido, pero está en un nivel aceptable. Eso sugiere que puede haber excepciones a la idea de que toda documentación escrita por LLM es mala.
• Últimamente el campo de los LLM está imitando paradigmas de software a toda velocidad, casi como usando un truco. Ya hubo muchos ejemplos en el pasado sobre cómo exponer funciones remotas, como DLL, gRPC, SOAP, IDL y dCOM, pero da la impresión de que el mundo actual de los LLM ni siquiera sabe que existen. Espero que con el tiempo esto madure más, pero al final igual tendrán que resolver las tareas pendientes.
  • Seguro madurará en unos meses, pero al ver el ecosistema temprano de Python recuerdo cómo ciertos errores terminan asentándose en capas inferiores del stack y luego todos construyen nuevas herramientas encima. Lo más triste esta vez es que el ecosistema de IA está avanzando igual pese a que ya existe una historia previa de errores idénticos.
  • Cuando vi MCP por primera vez pensé en COM/DCOM, y también me acordé del viejo DLL Hell. Voy a observar cómo evoluciona MCP.
  • Todavía no encontré una explicación que me deje claro qué es exactamente MCP, y me pregunto con qué concepto de los lenguajes de desarrollo del pasado se podría comparar.
  • Quiero señalar que en este tipo de protocolos estrictos y declarativos se pierde el espacio de significado potencial y la fortaleza semántica de los LLM. Tal vez sería más intuitivo poner simplemente un archivo agents.json en la raíz web y que los agentes lo resuelvan automáticamente mediante conversación semántica. En ese caso, HTTP terminaría siendo la entrada y salida estándar de los agentes.
  • Creo que todos los ejemplos que se mencionaron son apropiados.
  • Me pregunto si MCP está basado en JSON-RPC.
• Estoy de acuerdo con el contenido general del post, sobre todo con esa experiencia desconcertante de no poder encontrar información sustancial en el sitio de MCP. Los RFC son difíciles de leer, pero son mucho mejores que un simple “solo usa el SDK”.
  • Ojalá más gente reconociera la importancia de este blog. Habría que pausar un poco la adopción de MCP y volver a revisar si realmente existe una base técnica sólida. Hay mucho entusiasmo, pero cuando uno entra de verdad a la etapa de implementación termina decepcionado. Varias decisiones centrales, como el uso de WebSockets, resultan cuestionables y, aunque no todo, sí da la impresión de algo armado a las apuradas como solución provisional.
  • Es una pena que no haya una especificación clara en el sitio. Parece que la mitad de la especificación hubiera salido de Sonnet, y no está descrito con claridad cómo funciona realmente el protocolo. En comparación, la especificación de GraphQL está muchísimo mejor escrita.
• Actualmente, gran parte del trabajo en IA está siendo llevado por matemáticos, científicos (de datos), estudiantes y entusiastas amateurs. Visto desde el estándar de un ingeniero de software profesional, muchas cosas todavía no maduran más allá del nivel de un proyecto de fin de semana.
  • Yo creo que en realidad los ingenieros de software profesionales sí están haciendo buena parte del trabajo.
• MCP debió haber ido desde el inicio por HTTP stateless. La mayoría de los servidores no necesitan mantener estado; con guardar estado globalmente o tener un identificador de sesión sería suficiente.
  • No entiendo la estructura de interacción real de MCP. Quisiera saber por qué no es stateless y por qué hay que mantener la conexión abierta.
  • No tengo mucha experiencia personal, pero si cierras la conexión después de una solicitud, entonces tienes que volver a conectarte para la siguiente. Mantener una sesión abierta o cerrarla depende de varias variables, como el patrón de uso y el consumo de memoria.
• Estoy creando un servicio MCP basado en Ruby on Rails llamado ninja.ai; es una app store que instala servidores MCP con un clic. Instala servidores de Model Context Protocol en el dispositivo cliente usando Tauri. También ofrece servidores MCP en la nube con Rails. Soy crítico de HTTP+SSE y de Streamable HTTP; para comunicación bidireccional en tiempo real, WebSockets me parece mejor, y como el soporte de SSE en Rails es limitado, terminé migrando el endpoint al servidor web Falcon. Me intriga por qué los ingenieros de Shopify eligieron Streamable HTTP; quizá fue por restricciones de infraestructura o despliegue. También vale la pena notar que la capa de transporte de MCP está abstraída, así que futuras implementaciones podrían adoptar WebSockets o WebRTC sin problema.
• Soy el operador de uno de los registros de MCP (glama.ai/mcp/servers). Coincido parcialmente con el autor, pero el protocolo todavía está en una etapa muy temprana y puede cambiar bastante en adelante. Recibió mucho más interés del esperado: pasó de unas decenas de servidores al principio a miles muy rápido, aunque solo una parte realmente funciona, así que paso mucho tiempo filtrándolos. Es un fenómeno causado porque MCP atrajo atención pública antes de madurar. Aun así, últimamente el ecosistema —frameworks de código, registros, clientes con soporte para MCP— está creciendo a una velocidad sorprendente. Ver un cambio así en apenas medio año no tiene precedentes. Si la tendencia sigue, creo que el panorama es prometedor. También ofrezco una recopilación de materiales útiles para quienes están empezando.
  • Si cometes errores al diseñar un protocolo al inicio, cargas con ellos para siempre, así que hay que construir la spec con humildad. Una vez que una estructura tipo Goldberg como SSE queda ahí, puede volverse permanente sin posibilidad de corregirla. A nivel enterprise, cualquier cambio que rompa el protocolo es muy difícil, así que uno puede quedar atrapado durante mucho tiempo con decisiones iniciales sin poder modificarlas.
  • Que el protocolo MCP siga evolucionando con el tiempo me parece totalmente natural. Lo raro sería esperar un alto grado de completitud desde el principio. Más que nada, la estandarización de APIs agénticas es un cambio realmente poderoso. Hay que experimentarlo para entender lo impresionante que es escribir y desplegar código y que la IA lo reconozca y lo use automáticamente de inmediato.
  • Mi preocupación es si, con esta velocidad, MCP va a adoptar demasiado pronto un diseño de capa de transporte que debería durar mucho tiempo. Me recuerda casos como la fragmentación de estándares en las browser wars de los 90, que tardó muchísimo en resolverse, o cómo IE11 sobrevivió durante demasiado tiempo.
• La controversia relacionada con la autenticación ya se está actualizando. En colaboración con Anthropic y la comunidad de seguridad, se implementó en MCP la separación entre el resource server (RS) y el authorization server (AS). Mientras se formaliza la nueva versión del protocolo, se publicó provisionalmente una especificación preliminar.
  • Me pregunto qué porcentaje de la spec de MCP proviene de salida de LLM. Me intriga si lo que detectamos intuitivamente como señal de alerta viene de ahí.
  • Mi postura es relativamente neutral, pero me molesta que parezca una copia rápida de un borrador de OAuth y que, al usar HTTP, se vuelva una estructura obligatoria sin margen de elección. En realidad se podría haber organizado de forma más clara permitiendo que cliente y servidor tuvieran soporte opcional para OAuth2 por separado.
• Sobre el lanzamiento de Streamable HTTP en MCP, alguna vez abrí un issue preguntando si no se podría convertir todo simplemente en requests HTTP. La especificación de MCP parece prometedora como solución general para conectar LLM con herramientas, pero en la práctica enfrenta muchas dificultades: autenticación, streaming, comandos personalizados por herramienta, validación de confianza de las herramientas, etc. En realidad me parece más simple integrar todo con solo una REST API. OpenAI o Gemini también dijeron que adoptarían MCP, pero espero que pronto choquen con inconsistencias en capas que la spec no desea, como la UI o la interacción, y que terminen apareciendo problemas de incompatibilidad con la marca o incluso de robo de autenticación.
  • Aunque Anthropic haya creado MCP, su escala sigue siendo claramente menor comparada con ChatGPT. Me cuesta imaginar que grandes empresas como OpenAI o Google acepten durante mucho tiempo una especificación en la que un equipo externo define los límites de la experiencia de usuario. Ya pasó antes con ChatGPT Plugins, que fracasó no por mala ingeniería sino por los límites de la experiencia del consumidor. Aun así, sí estoy dispuesto a confiar en la fuerza de una comunidad sólida.
  • Después de publicar el blog, yo mismo dejé un issue similar. Como es algo realmente importante, siento que si se cometen errores será muy difícil revertirlos.
• Me sorprende que MCP esté despegando tanto, pero en fin, es la tendencia. Me gustaría escuchar en qué sentido es mejor MCP comparado con la especificación de OpenAPI.
  • Creo que gran parte de la popularidad de MCP viene de que recientemente la usabilidad de herramientas con LLM sí mejoró de verdad. Los plugins de OpenAI en 2023 fracasaron porque en ese momento los LLM todavía no eran lo bastante confiables usando herramientas, mientras que MCP llegó con mucho mejor timing.
  • Otro factor importante es que arrancar un servidor MCP es muy fácil y la barrera de entrada es baja. A medida que crecen las herramientas, también aumenta el texto que hay que enviarle al LLM; si proporcionas OpenAPI junto con detalles de cada ruta y mensajes descriptivos, Claude también puede integrarlo muy bien.
  • Una de las razones por las que MCP importa es que OpenAPI es documentación estática, así que el LLM tiene que hacerse cargo de todo el proceso de generación de requests, mientras que un servidor MCP reduce esa carga gracias a la abstracción. Como resultado, desde el punto de vista del LLM, es más fácil, más rápido y más seguro.
  • No creo que MCP sea perfecto, pero sí tiene varias ventajas sobre OpenAPI para LLM. Para empezar, las herramientas de MCP se pueden especificar de forma mucho más corta y simple, mientras que las especificaciones de OpenAPI son demasiado grandes y terminan ocupando demasiado contexto del LLM. Como los LLM en realidad no construyen llamadas sino que generan texto de salida, el enfoque de MCP resulta más natural. Además, MCP es mucho más flexible frente a estructuras dinámicas, como agregar o cambiar herramientas, y así supera las limitaciones estáticas de OpenAPI. Claro que también tiene problemas, especialmente en la capa de transporte, donde todavía hay bastante margen de mejora, aunque las bibliotecas principales están bastante bien implementadas.