MCP 2026-07-28: adiós al handshake y a las sesiones en la mayor revisión del protocolo

El protocolo MCP ya no tiene estado en su capa de protocolo. La especificación 2026-07-28, la mayor revisión desde que Anthropic lo abrió, elimina el handshake initialize/initialized y la cabecera Mcp-Session-Id: cualquier petición puede aterrizar en cualquier instancia detrás de un balanceador round-robin corriente, sin almacenamiento compartido.

David Soria Parra, responsable del mantenimiento de la especificación en Anthropic, lo resumió así en una emisión del 23 de julio de 2026: "El cambio más importante que hemos hecho a la especificación, posiblemente desde que añadimos authorization". Y añadió que "muchas de las cosas que hacían que MCP fuera MCP ya no están".

Cabeceras en lugar de estado

El diseño nuevo empuja la información al propio mensaje. Cada petición viaja con la versión de protocolo, la identidad del cliente y sus capacidades dentro de _meta. Streamable HTTP exige además las cabeceras Mcp-Method y Mcp-Name en todas las peticiones, para que un gateway, un rate limiter o un WAF enruten y autoricen sin abrir el cuerpo JSON; una petición cuyas cabeceras no cuadren con el cuerpo no llega al handler. La contrapartida es un fallo silencioso: las claves de _meta van con prefijo completo, io.modelcontextprotocol/protocolVersion, y una errata no lanza ningún aviso, simplemente no hace nada.

El protocolo añade server/discover, opcional, para consultar capacidades antes de actuar. Y sustituye el stream bidireccional permanente que usaban sampling/createMessage, elicitation/create y roots/list por Multi Round-Trip Requests: el servidor responde con resultType input_required y las preguntas, el cliente se las traslada al usuario y reenvía la petición original con las respuestas. Supabase lo cuenta de forma concreta: la elicitación llevaba tiempo en su hoja de ruta, pero su MCP corre sin estado y no encajaba; con MRTR pueden confirmar con el usuario el coste de un proyecto antes de crearlo. Los listados —tools/list, prompts/list, resources/list— se pueden cachear, con ttlMs y cacheScope.

El campo de batalla real es el despliegue

Las cifras que acompañan a la versión dejan claro dónde está el problema. Un informe de seguridad revisó más de 5.200 servidores MCP: el 88% exige credenciales, pero solo el 8,5% usa OAuth; el 53% se queda en una API key estática y el 79% pasa esa clave por variable de entorno. Autenticación que no caduca, no está ligada a un servidor concreto y acaba en un log sin que nada lo impida. El mismo informe localiza 492 servidores expuestos a internet sin autenticación ni cifrado, con 1.402 herramientas accesibles, más del 90% permitiendo leer datos directamente; en una comprobación posterior la cifra subió a 1.467. Otro dato pesa más: el 86% de los servidores MCP corre en la máquina del desarrollador y solo el 5% en producción.

La elección de transporte es la primera decisión de arquitectura. stdio no escala en horizontal porque es un único proceso. Cloud Run y ECS con Fargate lo dejan claro: con stdio el servidor falla en silencio; con Streamable HTTP y un ALB delante, funciona. Fly.io mantiene conexiones HTTP persistentes de serie. Según una guía de despliegue que cita a The New Stack, alrededor del 70% de los despliegues en producción ya usa Streamable HTTP y el 30% restante sigue en stdio, casi todo herramientas locales. stdio no es seguro por ser local —su autenticación es la variable de entorno— y Streamable HTTP no obliga a OAuth: la autorización sigue siendo opcional en la especificación.

El cambio de fondo ataca lo que frenaba el escalado: sin sesiones en el servidor, MCP deja de necesitar almacenamiento compartido y se despliega como cualquier API. Al mover enrutado y autorización a cabeceras, da a los gateways un punto donde decidir sin fiarse del cuerpo. Queda por ver a qué ritmo clientes y servidores implementan la versión 2026-07-28; hasta entonces convivirán dos formas de hablar el mismo protocolo.