MCP pasa a ser sin estado: la especificación finalmente elimina el último bloqueo empresarial

Una nueva revisión del *Model Context Protocol* elimina el requisito de sesión con estado —el elemento que hacía incómodo escalar MCP detrás de un equilibrador de carga—. Pequeño cambio sobre el papel; grande en el despliegue.

En términos sencillos. El Protocolo de Contexto del Modelo —la especificación que permite a los asistentes de IA llamar a herramientas externas— acaba de lanzar una revisión que elimina el requisito de una conexión con estado entre cliente y servidor. Este es el cambio que los equipos de infraestructura empresarial han estado esperando.

Por qué el estado era un problema

El transporte original del MCP asumía una sesión persistente cliente-servidor. Si tu asistente necesitaba llamar a una herramienta, el asistente y la herramienta compartían un canal en vivo durante la interacción. Funcionaba en una laptop; era incómodo a escala.

La incomodidad surge tan pronto como pones un equilibrador de carga frente a él. Una sesión con estado significa que cada llamada posterior debe llegar al mismo nodo backend. Esto elimina el patrón de despliegue más económico en infraestructura empresarial: distribuir solicitudes en un grupo sin estado, escalar automáticamente según la carga y tolerar la pérdida de nodos. Terminas construyendo parches de afinidad de sesión, enrutamiento persistente o, peor aún, gestores de conexión que se convierten en puntos únicos de fallo.

Qué cambia realmente la nueva especificación

Según los informes, el transporte revisado permite a los servidores anunciar un modo sin estado. En la práctica:

# antes (parafraseado)
POST /mcp/session → session_id
POST /mcp/call { session_id, tool, args } # debe llegar al mismo nodo
POST /mcp/close { session_id }

# después - modo sin estado
POST /mcp/call { tool, args, ctx } # cualquier nodo, sin sesión

El ctx es el elemento que transporta lo que el servidor necesita sobre los giros anteriores, enviado por el cliente. Es el mismo patrón al que llegaron las APIs REST hace veinte años: la ausencia de estado comprada con solicitudes ligeramente más grandes.

Bajo el capó: el compromiso que ahora tienes

Sin estado no es gratis. Dos cosas pasan al cliente:

• Gestión del contexto. El cliente ahora es la fuente de verdad para cualquier estado por conversación que una herramienta necesite. Cargas útiles más grandes y una nueva clase de error: olvidar propagar.
• Idempotencia. Una vez que cualquier nodo puede servir cualquier llamada, los reintentos se vuelven plausibles en más lugares. Los autores de herramientas deben hacer que sus llamadas sean idempotentes o lidiar con ejecuciones dobles.

Para la mayoría de los despliegues empresariales, este intercambio vale la pena. Para asistentes de baja latencia donde los bytes del viaje de ida y vuelta importan, es un costo real.

Qué señala esto

El hilo del ecosistema MCP ha sido sobre la infraestructura madurando de "calidad de prototipo" a "podemos poner esto detrás de un equipo de SRE". El transporte sin estado es el paso concreto en esa dirección. También te dice dónde los autores de la especificación ven el crecimiento: dentro de las empresas, detrás de proxies, no en máquinas individuales de desarrolladores.

Entonces, ¿qué?

Para un desarrollador: si implementaste una integración MCP y sufriste con la afinidad de sesión, la solución ahora está bendecida por la especificación en lugar de ser personalizada. Para un decisor: MCP acaba de volverse amigable para adquisiciones. Espera que los proveedores anuncien "nativo en MCP" de la misma manera que antes anunciaban "nativo en REST".