MCP pasa por alto lecciones valiosas de los sistemas distribuidos

• MCP (Model Context Protocol) se presenta como una estandarización de la integración de herramientas de IA, pero tiene un problema: pasa por alto las mejores prácticas de sistemas distribuidos y RPC acumuladas durante 40 años
• Por eso, en entornos empresariales faltan funciones clave como la confiabilidad operativa, la seguridad de tipos, la seguridad, la observabilidad y la gestión de costos
• MCP no solo depende de librerías externas para funcionalidades esenciales, sino que además provoca fragmentación del protocolo, complejidad de integración y carga de gestión de auditoría y seguridad
• Requisitos operativos clave como trazabilidad distribuida, versionado de esquemas, descubrimiento de servicios y optimización de rendimiento siguen siendo insuficientes
• La adopción temprana de MCP en el entorno empresarial, impulsada por la fiebre de la IA, puede conducir a fallas críticas, riesgos operacionales, desarrollo duplicado y costos innecesarios

---

El riesgo de que la simplicidad de MCP provoque fallas

MCP (Model Context Protocol) se presenta como el "USB-C del mundo de la IA", destacando su simplicidad para reducir la barrera de entrada a la integración de herramientas de IA. Sin embargo, esa simplicidad termina ignorando las lecciones acumuladas en 40 años de sistemas distribuidos, lo que provoca fallas críticas en entornos de operación reales. Las empresas que lo adoptan ahora están construyendo sobre una base que carece, en esencia, de funcionalidades esenciales de sistemas RPC.

La peligrosa brecha entre expectativas y realidad

Los defensores de MCP lo presentan como infraestructura lista para producción, pero su filosofía de diseño prioriza la facilidad de desarrollo y carece de la robustez operativa necesaria. Puede conectar herramientas de IA en poco tiempo, pero cuando se usa a escala con millones de solicitudes en operaciones reales, quedan en evidencia fallas graves. La adopción se acelera por las expectativas excesivas sobre la IA sin la madurez arquitectónica necesaria, lo que incrementa el riesgo de fallos operativos.

Errores que se repiten en 40 años de historia

• UNIX RPC (1982) introdujo XDR (External Data Representation) e IDL (Interface Definition Language) para la compatibilidad de datos entre sistemas heterogéneos, como enteros de 32 bits, y para detectar errores de incompatibilidad de tipos en tiempo de compilación
  MCP ignora esta experiencia y solo ofrece JSON sin esquema y sugerencias no obligatorias. Los errores de tipos aparecen en tiempo de ejecución, y la IA puede generar fechas incorrectas o provocar errores de conversión y problemas de calidad de datos que son críticos en escenarios reales de finanzas, salud o manufactura

• CORBA (1991) usaba OMG IDL para garantizar la misma interfaz entre distintos lenguajes. MCP se implementa de forma separada por cada lenguaje, por lo que la serialización, el manejo de errores y otros aspectos no tienen consistencia entre lenguajes y librerías, lo que genera una pesadilla de integración

• REST (2000) logró escalabilidad y confiabilidad masiva con una estructura sin estado, aclaración semántica basada en verbos y encabezados de caché
  MCP tiene una separación ambigua entre estado y sin estado, y no cuenta con caché, distinción estándar del significado de solicitudes ni soporte de idempotencia. Escalar servidores, manejar reintentos y balancear carga se vuelve extremadamente difícil

• SOAP/WSDL contaba con contratos legibles por máquina, automatización y extensibilidad de seguridad
  MCP solo provee un esquema JSON básico y carece de contratos legibles por máquina, generación automática, seguridad de tipos y auditoría de seguridad. OAuth 2.1 se añadió tarde y solo al transporte HTTP, y stdio depende de variables de entorno, dejando controles de seguridad insuficientes

• gRPC (2016) incorporó nativamente trazabilidad, seguimiento distribuido, streaming bidireccional, deadlines y códigos de error estructurados
  MCP solo admite streaming unidireccional en formato de evento, lo que lo vuelve ineficiente para interacciones complejas. Faltan elementos esenciales como contexto de traza, deadlines y clasificación de errores

El riesgo de decir “usa solo esta librería”

Cada vez que se señalan fallas críticas, MCP responde añadiendo librerías de terceros (por ejemplo, mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator). Sin embargo, esto evidencia un punto de falla central del protocolo. Cuanto más se delegan funcionalidades esenciales hacia el exterior, más se agravan los problemas de fragmentación, inconsistencia, mantenimiento, seguridad y reparto de responsabilidades de integración
En entornos empresariales, en pocos meses crecen las cargas de estandarización, auditoría e integración, y también se disparan de forma anormal la capacitación de desarrolladores y la dependencia de terceros.

Capas de parches temporales que se acumulan

La versión de MCP de 2025–03–26 parece un cuaderno de notas de parches que corrigen fallas detectadas tarde, ya en producción. OAuth, gestión de sesiones, atributos de herramientas (annotation), notificaciones de progreso, entre otros, son solo adiciones tardías de funciones que debieron existir desde el inicio.
La distinción de atributos de herramientas también estuvo ausente al inicio, al igual que una autenticación que inicialmente se consideró innecesaria. Esto demuestra una falta de comprensión fundamental de los requisitos empresariales.

Pesadilla de depuración y rastreo operacional imposible

en entornos gRPC, el seguimiento distribuido y los IDs de traza permiten depurar de forma rápida y consistente
Con MCP, la ausencia de ID de correlación entre solicitudes, la inconsistencia de formato de logs y la necesidad de implementaciones propias hacen que la depuración y el rastreo de errores lleven días
También desde lo operativo y comercial, es imposible gestionar la asignación de costos y el uso (encabezados, conteo de tokens, cuotas, etc.).
En la nube, funcionalidades básicas ni siquiera están disponibles en MCP, por lo que rastrear costos de uso de IA y responsabilidades se vuelve prácticamente imposible

Principales problemas operacionales que aún quedan

• Sin descubrimiento de servicios, no es posible manejar disponibilidad, escalado multinube por región ni despliegues sin tiempos de inactividad
• La falta de versionado de esquema por herramienta deja el riesgo de que al actualizar una herramienta, todo el ecosistema de clientes falle sin aviso previo
• Límites de rendimiento: sobrecarga por JSON, ausencia de pooling de conexiones, deficiencias en protocolos binarios, compresión y patrones antiguos de comunicación por proceso

Riesgos graves al aplicar en entornos empresariales

Al entrar la IA en áreas con responsabilidad real de ingresos, seguridad y calidad (finanzas, salud, manufactura, soporte al cliente), aumentan los riesgos de adoptar MCP
Las organizaciones reemplazan patrones de integración robustos construidos a lo largo de muchos años y terminan parcheando de forma reactiva seguridad, auditoría, seguridad de tipos y estabilidad operacional
Un enfoque de “probar rápido y romper” que sirve solo en prototipos puede tener consecuencias críticas en servicios de importancia

Ruta de mejora y requisitos de largo plazo

• Corto plazo: tipado seguro, seguimiento distribuido (ID de correlación), autorización, formatos de auditoría estandarizados y versionado independiente de esquemas por herramienta deben ser obligatorios en el propio protocolo
• Operación: descubrimiento de servicios, pool de conexiones, transporte binario, deadlines y políticas estandarizadas de errores y reintentos
• Largo plazo: streaming bidireccional, gestión de cuotas y costos integrada, enforcement de SLA y orquestación de workflows para alcance empresarial

Conclusión

La diseño de MCP orientado a la simplicidad puede ser adecuado para integraciones de herramientas de IA de corto ciclo y carácter experimental, pero en entornos operativos empresariales puede traducirse en riesgo operativo y costos operativos críticos
La adopción se adelanta al subirse al boom de la IA y se repite una práctica parcheada: añadir después seguridad, observabilidad y estabilidad operativa en lugar de diseñarlos desde el inicio
Al final, existe el riesgo de que la fragmentación y el desarrollo duplicado que el protocolo pretendía evitar se reproduzca justamente sobre MCP
La industria de IA está en una encrucijada: repetir problemas ya resueltos al ignorar 40 años de evolución en sistemas distribuidos, o aprender de la historia
De continuar así, se repetirán implementaciones fallidas, fallas de seguridad y pesadillas operativas, y su costo lo pagará íntegramente el mundo empresarial

[GN⁺]

Opinión en Hacker News

• Al principio, al ver solo el título del artículo pensé que iba a ser una típica historia de show de seguridad. Pero al leerlo, noté que tiene ideas realmente buenas. Lo que más me llamó la atención fue esto: MCP ignora esas lecciones y usa pistas no obligatorias con JSON sin esquema, y la validación de tipos se hace en runtime o no se hace en absoluto. Por ejemplo, si una herramienta de IA espera un timestamp ISO-8601 y recibe un valor de epoch Unix, el modelo puede generar cualquier fecha sin fallar correctamente. En servicios financieros, una IA de trading podría interpretar mal números y ejecutar una operación con precisión decimal incorrecta; en salud, un tipo de dato de paciente convertido erróneamente puede recomendar una dosis de medicación equivocada. En manufactura, perder precisión de datos de sensores durante la serialización a JSON puede derivar en problemas de control de calidad. Desde que trabajo con LLM a diario, este tipo de problemas los veo con frecuencia. En el futuro, imagino que en algún sistema con MCP habrá un incidente grande: en el reporte de caída se verá que el servidor MCP emitió datos raros, el LLM los tomó y produjo una salida alucinada, y eso llevó a problemas cada vez mayores. Al juntar errores humanos, la naturaleza de los LLM sin manejo de excepciones (alucinaciones) y la cultura de las startups de lanzar servicios rápido, es inevitable que surja una nueva clase de bug. Y cuando eso pase, los usuarios de Twitter hablarán sin parar de una AGI hackeando el código de lanzamiento de misiles; esa escena también sería bastante divertida.

• Hablando sinceramente, antes de 2023 pensaba que los fallos técnicos tipo Star Trek parecían tan de ciencia ficción que eso jamás iba a pasar. Pero desde que aparecieron los LLM, siento que esto sí va a pasar de verdad. No me queda claro qué relación tiene la integración de LLM con la ingeniería, y dudo que sea razonable delegar el control total de la infraestructura de una empresa a una entidad externa. Además, con el problema de reproducibilidad que mencionas, decir que algo funciona ‘de algún modo’ ya no se puede llamar ingeniería.

• No entendí bien la crítica del autor. MCP sí soporta JSON Schema, así que la respuesta del servidor debe seguir ese schema. Si el schema exige ISO-8601 y el servidor envía epoch Unix, eso es una violación de protocolo clara. El texto dice que, aunque MCP soporte JSON Schema, no se puede generar un cliente type-safe, pero eso no coincide con la realidad, porque ya existen muchos generadores de código para JSON Schema.

• El problema PEBKAC (error de usuario) ya existe, y los LLM lo llevan a otro nivel al automatizarlo.

• Sobre el punto de que una conversión de tipo de datos incorrecta puede causar mala prescripción en salud, yo lo vi de primera mano haciendo telemetría médica y entendí lo importante que es parsear bien timestamps. Tal vez por eso empecé a escribir tests unitarios. También recalculé y corregí timestamps en headers cuando no había NTP. Esas medidas venían por revisiones de incidentes y la responsabilidad por negligencia médica. Por ejemplo, la diferencia entre la hora en que un paciente recibió un fármaco justo antes de una parada cardíaca y después puede salvar o quitar una vida. Como en el caso reciente de Royal Mail en Reino Unido, un solo error de datos puede arruinar una vida, y en datos médicos, un minuto puede cambiar el mundo.

• MCP tiene como objetivo el transporte y la gestión de contexto. Es decir, la responsabilidad razonable de implementar interfaces como definición y validación de esquemas recae en el usuario. Es similar a la crítica de que HTTP no soporta validación JSON: una obviedad.

• MCP dice que será el USB-C del mundo de IA, pero, irónicamente, esto parece más bien un caso que muestra lo que está mal en USB-C que una victoria de MCP. USB-C puede conectar casi todo, pero el cumplimiento del estándar es pésimo, igual que el parsing inconsistente de JSON o el incumplimiento de protocolo en MCP. Como el mundo real de tener muchos tipos de cable USB-C, la apariencia de universalidad oculta una complejidad tremenda. Creo que sería mejor tener APIs/protocolos bien separados.

• El ejemplo extremo del fallo de USB-C fue cuando Apple eliminó los puertos USB-A en el nuevo Mac mini con M4. Un puerto que se ve igual entrega un rendimiento totalmente distinto, y los usuarios se enteran después del anuncio del producto. Antes, en desktops/laptops con Apple Silicon, se podía esperar Thunderbolt 40Gbps en todos los USB-C; ahora algunos son USB3 10Gbps. Para saber cuál es cuál, hay que revisar la especificación o mirar el icono. Si Apple hubiera dejado algunos puertos USB-A, la limitación de 10Gbps sería visible de inmediato, pero en vez de eso solo diluyó más el valor de marca de USB-C. Al final, casi todos los dispositivos USB-C terminan conectándose a USB-A con adaptador, y la versión USB-C suele ser más cara, menos común y, además, a menudo de menor calidad. Pero vivimos en un mundo donde el hype y el fandom superan a la practicidad y usabilidad.

• Honestamente, vi esa idea (USB-C = universalidad en apariencia, opacidad en la práctica) y me reí bastante. Como que sí cumplieron el objetivo, o algo así.

• Sobre SOAP, hay un comentario que dice que aunque es verboso, entendió algo que MCP no entiende. En la práctica, SOAP tampoco se entendía del todo. De hecho, mantenido sistemas SOAP legacy no hay nada de qué hablar bien de él. No puede ser un rol modelo para nadie.

• SOAP fue literalmente una catástrofe gigante. Es increíble cómo hicieron algo sencillo tan complejo: XML ya era complicado y también definiciones ambiguas como WSDL o multi-part HTTP; sin interoperabilidad garantizada entre lenguajes (por ejemplo, SOAP entre servidor .NET y cliente Java). Cuando pasa el tiempo, la gente recuerda solo lo bueno, pero a mí me tocó elegir trabajar media vida con APIs JSON sin schema antes que SOAP por un mes. Personalmente, creo que protobuf y capnp están mucho mejor.

• REST (en la práctica JSON-RPC) y GraphQL todavía intentan emular lo que SOAP y SOA ya ofrecían. Da pena cómo con cada tecnología nueva se tiran por la borda incluso sus partes buenas.

• Los protocolos con la palabra Simple nunca fueron tan simples. Siento que pronto veremos algo tipo SMCP.

• Encontré un enlace súper útil y preciso sobre SOAP para compartir: https://harmful.cat-v.org/software/xml/soap/simple. A mí me gusta la tecnología basada en XML, y en particular la capacidad de composición de tipos y validación de XML Schema sigue siendo inigualable. Pero SOAP da la impresión de haber terminado como un monstruo innecesario. Solo se necesitaba una especificación simple de llamada remota, y terminó siendo una especificación que intenta definirlo todo sin resolver bien nada. SOAP dice soportar todo: distintos protocolos de transporte (incluso SOAP over email), varios tipos de RPC y UDDI, RPC autosuficientes, pero en la práctica cosas clave como autenticación, caching y códigos de respuesta HTTP quedaron al cargo del usuario.

• Irónicamente, lo que me llevó a rechazar SOAP para siempre fue una presentación técnica de SOAP que vi en esa época. Entre el mismo lenguaje, funcionaba de manera aceptable; con lenguajes distintos, era terrible. Creo que ahí también está por qué Microsoft le gustaba tanto SOAP.

• CORBA apareció en 1991 con la idea de que en entornos heterogéneos no alcanza con implementar un protocolo por cada lenguaje; y es cierto que OMG IDL evitaba problemas de consistencia de interfaces y serialización al generar bindings idénticos en múltiples lenguajes. Pero sigo sin ver si fue realmente un caso de éxito.

• El ecosistema actual de APIs centradas en JSON se ve como una reacción a los fracasos de CORBA y SOAP. Diría que más que olvidar las lecciones de CORBA, lo que se hizo fue rechazarlo deliberadamente.

• Trabajé en un lugar donde CORBA se usaba muy bien. Creo que el éxito venía de tener un ingeniero senior con mucha experiencia en CORBA dentro del equipo.

• En 1998 apliqué a un trabajo en AT&T que usaba CORBA y fue mi última experiencia con eso (y desde entonces no lo volví a ver, salvo una descarga de JDK que se ponía lenta). En esa entrevista, el entrevistador dijo que no le gustaba mi código concurrente, y no pude convencerlo de una alternativa aunque había race condition; después quedó claro que, por el Java Memory Model, mi respuesta era correcta.

• CORBA hizo muchas cosas bien, pero era un producto de las redes de telecom tradicional de finales de los 80 y la ola de OOP. Por eso asumía que la red era transparente, confiable y simétrica. En la realidad no es así: hay timeouts, reintentos, congestión de red y caídas del sistema. El binding de CORBA en C++ era espantoso porque era pre-STL, y otros lenguajes salían mejor.

• En proyectos técnicamente brillantes pero comercialmente fracasados, igual se puede reconocer lo bien que estaban.

• Lo que se está perdiendo en la discusión de MCP, la lección que sí aprendió bien, es que toda función avanzada introduce complejidad y empuja a que en la operación real se elija lo simple. Por eso ganó JSON over HTTP. Incluso en grandes tech, migrar a protocolos de serialización más potentes como gRPC puede tardar años y fallar varias veces en el camino. El papel real de MCP, para mí, es estandarizar un contrato simple de API JSON y facilitar la generación de tokens y de estilos de llamada a herramientas para LLM.

• Me preguntaba qué son los HTTP blobs. Al final parece que solo quería explicar por qué JSON le ganó a XML.

• MCP no es perfecto, pero sí aprendió bien una lección de décadas de historial RPC: la complejidad es lo que más dificulta la adopción y el uso (igual que el ascenso de JSON sobre XML). SOAP era demasiado complejo para la interoperabilidad entre sistemas y XML con sus schemas también era demasiado verboso. CORBA tenía bibliotecas y frameworks complejos, y para los lenguajes modernos de la época era evitable. gRPC es rápido, pero menos legible y requiere mapeo. Hoy, el esqueleto de RPC es REST y JSON. Los estándares arriba mencionados desaparecieron o, para extremos de alto rendimiento, gRPC quedó como opción limitada. REST y JSON terminaron siendo la corriente dominante porque la simplicidad ganó, y MCP también está diseñado en esa línea.

• Buenos comentarios en general. Siento que estamos malinterpretando MCP. Lo importante es la desalineación general de qué es un agente y hacia dónde va en la industria. Muchas plataformas web creen que el agente debe incrustarse en infraestructura de red distribuida y que su objetivo es conectar con MCP a todos los agentes dentro de un contenedor como parte de una service mesh. Mi opinión es que plantear que los SDK/frameworks de agentes web-native deben desplegarse como aplicaciones servidor es un error; eso no son agentes, ni siquiera en etapa inicial de evolución. Los harness reales de agente solo los pueden hacer unos pocos proveedores como Frontier Labs, y esto se moverá hacia la personalización (por ejemplo, un solo servidor MCP para Claude Desktop en mi máquina). MCP servers originalmente eran para esa instancia única y ese tipo de harness.

• El problema de MCP no es que esté mal diseñado para enterprise, sino el mal uso de LLM. Por ejemplo, que un AI en finanzas ejecute trades con error de precisión decimal no es un problema de protocolo, sino de haber puesto trading en un LLM sin restricciones. También, un LLM que interpreta mal un formato de fecha y genera una salida alucinada es problema de introducir LLM en entorno crítico.

• Ojalá alguien explicara claramente por qué necesitamos MCP en vez de Swagger o proto.

  • OpenAPI (Swagger) o Proto (protobuf) no cubren completamente el rol de MCP. Teóricamente, sí se podía poner MCP sobre ellos, pero para los casos de uso locales de MCP la suposición de comunicación de Swagger no encaja y protobuf no incluye protocolo de comunicación por defecto, por lo que exige diseño extra. Aunque reemplaces JSON-RPC, al final casi toda la especificación MCP permanece y la complejidad aumenta.

  • MCP es una tecnología nueva.

  • MCP soporta respuestas en streaming. Podrías implementarlo con polling o estado de sesión, pero sería un parche ineficiente.

• Cuando OpenAI dice que el mes pasado le facturaron $50,000 por uso de API, a veces no puedes saber qué herramienta MCP de qué equipo causó ese costo, qué llamada puntual, usuario o caso de uso estuvo detrás. En IA, la mayoría de la tecnología suele ir detrás de los problemas y alcanzarlos tarde. Pero como con frameworks web, blockchain y compañía, cuando algo es demasiado grande no se puede conocer todo desde el inicio; la brecha también se cierra poco a poco. Estoy de acuerdo en que hay que seguir compartiendo ideas y estado de alerta en IA. Es realmente una época emocionante.

• Cuando hay que elegir entre un diseño mejor y uno suficientemente bueno, creo que siempre gana lo suficientemente bueno. Se pueden seguir mencionando ejemplos: Multics vs Unix, SOAP en XML vs REST en json, el fracaso de XHTML, el propio JavaScript, y así. Por eso me preparo para que la humanidad siga reimplementando lo suficientemente bueno y tapando con parches temporales cada vez que surgen problemas, sobreviviendo así.

  • Esto es la repetición de un fenómeno conocido de Worse is Better (https://en.m.wikipedia.org/wiki/Worse_is_better). Ha sido demostrado una y otra vez con el tiempo. Yo también suelo inclinarme por soluciones ‘mejores’, pero la realidad no siempre va así.

  • xforms 2.0 merece un minuto de silencio. Un mundo en el que podríamos haber vivido: validación de formularios web correcta, microdatos...