Desde que apareció el release candidate vi varias veces el mismo resumen: “MCP se vuelve stateless”. Es un buen título. También es incorrecto de una forma que importa para seguridad.

Desaparece la sesión del protocolo. El estado de la aplicación no desaparece. Alguien todavía tiene que protegerlo, autorizar el acceso y limpiarlo. Ahora queda claro que ese trabajo pertenece a la implementación del server.

Antes de seguir, una precisión de fecha. La especificación final está prevista para el 28 de julio. Hoy, el texto normativo sigue siendo el release candidate cerrado el 21 de mayo, con SDKs beta publicados a fines de junio. Ya se puede probar. Todavía hay que llamarlo borrador.

Qué se elimina realmente

En la revisión 2025-11-25, una conexión por Streamable HTTP comenzaba con un handshake initialize. El server podía devolver un Mcp-Session-Id y los pedidos siguientes llevaban ese identificador. El protocolo administraba una sesión de larga duración.

El release candidate 2026-07-28 elimina el handshake initialize/initialized y la sesión a nivel del protocolo. La versión, la información del cliente y sus capacidades pasan a la metadata de cada pedido. Un nuevo método server/discover permite que los clientes consulten las capacidades del server cuando las necesitan.

Pensemos en un carrito de compras o un navegador remoto. Ambos necesitan continuidad. El server puede devolver un ID y el modelo puede enviarlo más tarde como un argumento normal. Cualquier instancia puede procesar el siguiente pedido.

Es útil. También significa que el ID es input no confiable que vuelve desde el cliente. MCP ya no se ocupa de esa continuidad.

También cambia la interacción del server hacia el cliente. Un server solo puede pedir información mientras procesa un pedido del cliente. Las Multi Round-Trip Requests devuelven un InputRequiredResult con un requestState opaco; el cliente recoge la respuesta y vuelve a enviar el pedido original. Los prompts abiertos y no solicitados dejan de ser parte del flujo central.

Para Streamable HTTP, Mcp-Method y Mcp-Name hacen visibles las operaciones para los gateways sin necesidad de interpretar el body JSON-RPC. Los pedidos también llevan la versión del protocolo. El server debe rechazar el pedido cuando los headers de enrutamiento y el body no coinciden.

La mejora de seguridad es real

Ya no queda un Mcp-Session-Id para robar y reutilizar. El estado de seguridad tampoco queda asociado silenciosamente con una sola instancia. Un load balancer no necesita sticky routing solamente para satisfacer a MCP.

La interacción iniciada por el server también se acota. Ya no puede enviar un prompt cuando quiere; solo puede pedir información mientras procesa un pedido activo.

La autorización también se vuelve más explícita. La revisión endurece la validación del emisor de autorización, la vinculación de las credenciales registradas con ese emisor y la descripción de los tipos de cliente OpenID Connect y de los flujos de refresh tokens. Son mejoras importantes para desplegar OAuth. No vuelven seguro a un server MCP por defecto.

Son mejoras importantes. Eliminan mecanismos fáciles de usar mal. No vuelven seguro por defecto a un server MCP, y el borrador tampoco promete eso.

Dónde buscaría errores

El análisis de Akamai describe bien el intercambio. El secuestro de sesiones del protocolo pierde espacio. El estado de la aplicación, las interfaces interactivas y el trabajo de larga duración merecen más atención.

Estado devuelto por el cliente. Los IDs y valores de requestState cruzan un límite de confianza cada vez que vuelven. Un identificador predecible o sin firma puede permitir que un flujo retome otro. Si no está vinculado con el tenant, puede convertirse en un problema entre clientes. Firmalo o conservá el estado del lado del server, vinculalo con la operación y agregale vencimiento.

Metadata por pedido. Un campo no se vuelve confiable por vivir en _meta. Los campos reservados tienen significado para el protocolo. Los campos de la aplicación siguen siendo input del cliente. No autorizaría nada desde allí sin contexto autenticado del lado del server.

Headers de enrutamiento. Un gateway puede leer Mcp-Method y Mcp-Name mientras la aplicación lee el body JSON-RPC. Si no coinciden, rechazá el pedido. Dos capas no pueden tomar dos decisiones de seguridad sobre la misma operación.

MCP Apps. El iframe aislado es una separación útil. No detecta phishing, no garantiza un renderizado seguro y no impide que salgan datos visibles. Tratá la plantilla como código de un tercero, porque lo es.

Tasks. El trabajo puede continuar después del pedido que lo creó. Sin cuotas, deadlines y cancelación, un pedido barato puede abrir un proceso costoso en segundo plano. Acá confiabilidad y seguridad son el mismo problema.

Mi checklist antes de la publicación

El 28 de julio no obliga a migrar. Las versiones anteriores seguirán negociándose y las funciones deprecadas tienen una ventana de retiro. Igual usaría el release candidate para revisar estos supuestos ahora:

  • Tratar cada identificador de estado y cada campo de metadata definido por la aplicación como input no confiable. Proteger su integridad, vincularlo con un tenant y una operación, y aplicar vencimiento.
  • Validar los headers de enrutamiento contra el body JSON-RPC antes de autorizar o despachar.
  • Validar el emisor de autorización y la audiencia del recurso. Mantener las credenciales registradas vinculadas con el emisor que las creó.
  • Mantener secretos y datos personales fuera de la metadata enrutable y de los logs de infraestructura.
  • Definir límites de concurrencia, presupuestos, deadlines y cancelación para cada task de larga duración.
  • Revisar las plantillas de MCP Apps, la Content Security Policy y los datos expuestos antes de que un host las muestre.
  • Probar la negociación de versiones contra el release candidate y contra 2025-11-25. Los SDKs beta no migran automáticamente todas las aplicaciones a la nueva revisión.

Si las sticky sessions o un almacenamiento compartido formaban parte del modelo de seguridad, ese supuesto debe eliminarse. Pueden seguir siendo útiles para versiones anteriores, pero no son un límite de autorización.

El límite después de la sesión

Hace cuatro meses escribí sobre la capa de identidad que falta para los agentes. La nueva revisión hace más explícito el contexto de cada pedido y elimina una clase completa de mecánicas de sesión. Es un avance real.

Esta revisión confirma un patrón al que vuelvo seguido. A medida que MCP se vuelve más fácil de operar, las preguntas difíciles se acercan a la ejecución. ¿Quién emitió el pedido? ¿Qué tenant es dueño del estado? ¿La autorización cubre este recurso? ¿Cuánto trabajo va a permitir el server antes de decir que no?

El protocolo define el intercambio. La implementación tiene que hacer cumplir el límite.

Fuentes primarias

Estado revisado el 21 de julio de 2026. La especificación final está prevista para el 28 de julio, por lo que los detalles de implementación deben verificarse otra vez después de su publicación.