MCP 2026-07-28: el protocolo se vuelve stateless y refuerza OAuth

El 28 de julio de 2026 se publicó la nueva especificación de Model Context Protocol, y no es una actualización menor de superficie. Es una reescritura del modelo de transporte: MCP deja de ser un protocolo bidireccional con estado y pasa a ser, en su núcleo, un protocolo de petición y respuesta sin estado. Claude añadió soporte el mismo día del anuncio.

Si mantienes un servidor MCP propio o has integrado alguno en tu tooling interno, hay cambios que rompen compatibilidad y que conviene entender antes de actualizar dependencias sin mirar.

El cambio de fondo: adiós a las sesiones con estado

Hasta ahora, cada conexión MCP arrancaba con un handshake initialize / initialized, y el servidor mantenía el estado de esa sesión detrás de una cabecera Mcp-Session-Id. La nueva especificación elimina las dos cosas.

Las consecuencias prácticas:

• Cualquier instancia del servidor puede responder a cualquier petición, sin sesiones “pegajosas” ni un almacén de sesión compartido entre réplicas.
• La versión del protocolo y las capacidades del cliente ya no se negocian en un handshake inicial: viajan en el campo _meta de cada petición individual (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities).
• Los endpoints de listado (tools/list, resources/list, prompts/list) dejan de variar por conexión y pueden llevar hints de caché, porque ya no dependen de un estado de sesión particular.
• Cuando un servidor necesita mantener estado entre llamadas, ahora lo hace con handles explícitos que él mismo genera y que pasan como argumentos normales de una tool, no como estado implícito de la conexión.

El objetivo es que un servidor MCP se pueda desplegar y escalar como cualquier servicio HTTP sin estado: detrás de un balanceador, en múltiples réplicas, incluso en funciones serverless. Es el mismo movimiento que ya vivió el resto de la industria al abandonar el modelo de sesión pegajosa en favor de arquitecturas stateless con estado externalizado.

Enrutamiento por cabeceras y el fin de las llamadas bidireccionales abiertas

El nombre del método y el de la tool ahora también viajan en cabeceras HTTP propias, Mcp-Method y Mcp-Name. Un gateway puede enrutar y autorizar tráfico leyendo esas cabeceras directamente, sin tener que inspeccionar el cuerpo de cada petición.

El otro cambio importante afecta a las llamadas que antes requería el servidor iniciar hacia el cliente, como sampling o elicitation. Antes exigían mantener un stream bidireccional abierto todo el tiempo. Con Multi Round-Trip Requests (MRTR), el servidor responde con un InputRequiredResult que incluye las preguntas pendientes (inputRequests) y un estado opaco (requestState). El cliente recoge las respuestas y vuelve a invocar la llamada original añadiendo inputResponses. Todo dentro del ciclo normal de petición y respuesta, sin conexión persistente.

OAuth 2.1: los servidores MCP pasan a ser resource servers formales

Este es probablemente el cambio con más impacto de seguridad. La especificación alinea la autorización de MCP con OAuth 2.1 y OpenID Connect, y designa formalmente a los servidores MCP como resource servers OAuth.

En la práctica:

• Los servidores MCP deben implementar OAuth 2.0 Protected Resource Metadata (RFC 9728), para que un cliente pueda descubrir automáticamente el servidor de autorización correcto.
• Los clientes MCP deben implementar Resource Indicators (RFC 8707), que obligan a especificar de forma explícita para qué servidor MCP está pensado un token. Esto cierra una clase de vulnerabilidad conocida: un servidor malicioso ya no puede reutilizar un token emitido para otro servidor distinto.
• Se deprecia Dynamic Client Registration (DCR) en favor de Client ID Metadata Documents, aunque DCR se mantiene disponible por compatibilidad al menos doce meses más.
• Las credenciales quedan ligadas al emisor del servidor de autorización que las emitió. Si un recurso migra a otro servidor de autorización, el cliente tiene que volver a registrarse.

Quien haya montado autenticación OAuth a mano en un servidor MCP propio antes de este cambio va a tener que revisar ese código: la especificación anterior dejaba demasiado margen de interpretación en este punto, y era una fuente habitual de implementaciones inseguras.

Apps y Tasks salen del núcleo y se convierten en extensiones

La especificación introduce un framework de extensiones formal, con el objetivo declarado de mantener el núcleo del protocolo pequeño y mover funcionalidad opcional fuera de él.

• Tasks deja de ser una función experimental del núcleo y pasa a vivir en la extensión io.modelcontextprotocol/tasks, con un tasks/get basado en polling y un nuevo tasks/update.
• MCP Apps estandariza cómo un servidor MCP entrega interfaces interactivas (dashboards, formularios, visualizaciones de datos) a la aplicación que lo aloja. El núcleo base del protocolo se mantiene restringido a texto y datos estructurados; la UI embebida vive en esta extensión.

Es una decisión de diseño razonable: evita que el núcleo del protocolo crezca indefinidamente cada vez que alguien propone una funcionalidad nueva, y permite que un cliente implemente solo las extensiones que realmente necesita.

Qué rompe y qué toca migrar

Un par de cambios adicionales, más pequeños pero igual de rompedores si dependes de ellos:

• El código de error resource-not-found pasa del código propietario -32002 al código estándar de JSON-RPC -32602.
• Cualquier lógica que dependiera del handshake initialize o de la cabecera Mcp-Session-Id deja de funcionar directamente contra un servidor que implemente la nueva especificación.

Entre la publicación de la release candidate (21 de mayo) y la especificación final (28 de julio) hubo una ventana de diez semanas pensada para que mantenedores de SDKs e implementadores de servidores pudieran validar los cambios contra cargas de trabajo reales. Si mantienes un servidor MCP en producción, esa ventana ya se ha cerrado: toca revisar qué SDK usas y si ya soporta la especificación nueva antes de que algún cliente empiece a asumirla como la única disponible.

---

Lo que más me interesa de esta actualización no es ningún cambio concreto, sino la dirección de fondo. MCP nació como un protocolo pensado para conectar un asistente a herramientas locales, con sesiones largas y conexiones persistentes. Esta especificación lo empuja hacia el mismo modelo que ya usa el resto de infraestructura web moderna: sin estado, autenticado con estándares ya probados y con la superficie del núcleo lo más pequeña posible. Es la señal de que MCP está dejando de ser un protocolo de demo para asumirse como infraestructura que hay que operar en serio.