En Cloudappi llevamos suficiente tiempo diseñando e integrando APIs como para reconocer este patrón en cuanto se manifiesta. Un protocolo nace con estado (sesión, contexto persistente, notificaciones push) porque resuelve un problema legítimo de eficiencia y de experiencia en tiempo real.
Con la escala llega la letra pequeña: balanceadores que no identifican a qué nodo pertenece una sesión, reconexiones que dejan el estado a medias, clientes que permanecen a la espera de un evento que el servidor nunca llega a enviar. En algún momento, un comité de especificación concluye que la solución consiste en regresar a un modelo stateless basado en polling. Hemos observado este ciclo en SOAP, en REST, en WebSockets y en gRPC. Lo observamos ahora en MCP, a raíz del changelog de la especificación publicado el 28 de julio de 2026.
Una oscilación que no es nueva
HTTP nació stateless casi por accidente de diseño. SOAP acumuló sesiones, extensiones WS-* y contratos pesados hasta que REST lo desplazó. Después llegaron WebSockets y gRPC prometiendo tiempo real. Cada iteración repite el mismo argumento: el estado compartido mejora la latencia pero multiplica la superficie de fallo distribuido. Cuando ese coste se vuelve visible a escala, el péndulo regresa hacia stateless.
MCP no constituye una excepción; es su ejemplo más reciente. El punto de fricción se manifiesta donde resultaba previsible: detrás de balanceadores, en despliegues multi-instancia, en clientes que reconectan. El changelog constata esa deuda técnica.
Qué cambia realmente
No es un ajuste cosmético. Así se lee el diff:
| − | Las sesiones desaparecen del protocolo (Mcp-Session-Id fuera; el estado se convierte en handle explícito). |
| − | El handshake desaparece (initialize/initialized fuera; versión y capacidades viajan en _meta por request). |
| + | Aparece server/discover como RPC obligatorio de identidad/capacidades. |
| + | subscriptions/listen sustituye al GET+SSE y a resources/subscribe/unsubscribe. Se gana consistencia, se pierde resumibilidad (Last-Event-ID fuera). |
| + | El patrón MRTR sustituye las llamadas push del servidor por reintento controlado por el cliente vía InputRequiredResult/inputResponses. |
| − | Se deprecian Roots/Sampling/Logging, HTTP+SSE y OAuth Dynamic Client Registration, bajo una política formal de ciclo de vida (Active/Deprecated/Removed, ventana de 12 meses). |
Implicaciones para organizaciones con MCP en producción
No es una actualización de versión más: si tu cliente o servidor dependen de sesión, resources/subscribe, sampling/createMessage o resumibilidad SSE, hay piezas de arquitectura que dejan de tener sentido conceptual. Es rediseño, no un parche.
Una valoración: ¿madurez o falta de rodaje?
Las dos cosas a la vez: es una decisión de madurez (reduce fallos distribuidos, disciplina de ciclo de vida), pero también evidencia de que MCP se publicó antes de validar su modelo de estado a escala real. Quien construyó sobre los cimientos de 2024-2025 pagará la migración.
Nuestra recomendación para equipos con MCP en producción:
| 1 | Audita ya, migra con calendario. |
| 2 | Adopta server/discover y resultType cuanto antes. |
| 3 | Diseña el estado como handles explícitos desde ahora. |
| 4 | Supervisa de cerca la ventana de deprecación. |
| 5 | No lo trates como un problema exclusivo del SDK cliente. |
¿Hablamos de tu integración MCP?
En Cloudappi entendemos la interoperabilidad de APIs, Cloud e IA como una disciplina central de nuestro trabajo. Si tu equipo está evaluando cuándo y cómo migrar, podemos ayudarte a analizar tu caso concreto.
Revisa tu arquitectura MCP con nuestro equipo