MCP 2026-07-28: qué cambia con la mayor revisión del protocolo y cómo preparar tu servidor

MCP 2026-07-28: qué cambia con la mayor revisión del protocolo y cómo preparar tu servidor

Respuesta directa: el 28 de julio de 2026 se publica la revisión más grande del Model Context Protocol (MCP) desde su lanzamiento. El cambio central es que MCP pasa a ser sin estado (stateless): desaparecen el handshake initialize/initialized y el Mcp-Session-Id, de modo que cualquier petición puede aterrizar en cualquier instancia del servidor sin routing pegajoso ni almacén de sesiones compartido. Alrededor de esa decisión llegan un framework de extensiones, las MCP Apps (UI en iframe), un rediseño de Tasks, endurecimiento de la autorización y deprecaciones. Contiene cambios que rompen compatibilidad de forma intencionada. Si tienes un servidor MCP en producción, esto te afecta antes de que acabe el mes.

Este artículo es un mapa técnico de lo que cambia, qué se rompe y qué deberías revisar en tu stack. No es una lista de deseos: la RC está congelada desde el 21 de mayo de 2026 y la especificación final sale el 28 de julio, con una ventana de validación de diez semanas para los SDK de Tier 1.

La foto de un vistazo

Área	Antes (2025-11-25)	2026-07-28
Sesión	initialize/initialized + Mcp-Session-Id	Sin estado: capabilities viajan en _meta en cada request
Elicitación multironda	SSE abierto esperando respuesta	InputRequiredResult + reintento con requestState
Routing HTTP	Inspeccionar el body	Headers Mcp-Method y Mcp-Name
UI	No estándar	MCP Apps (HTML en iframe sandboxed)
Trabajo largo	Tasks como feature experimental del core	Tasks como extensión
Roots / Sampling / Logging	En el core	Deprecados

El núcleo sin estado: adiós a la sesión

El cambio de fondo es conceptual. Hasta ahora, un cliente MCP abría una sesión con un handshake y arrastraba un Mcp-Session-Id en cada petición. Eso obligaba a mantener estado en el servidor y a que todas las peticiones de una sesión cayeran en la misma instancia (sticky sessions) o compartieran un store.

La 2026-07-28 elimina el handshake (SEP-2575) y el identificador de sesión (SEP-2567). La información del cliente y sus capacidades viajan ahora en _meta en cada request. La consecuencia práctica es que cualquier petición puede procesarla cualquier instancia: escalas MCP como escalas cualquier servicio HTTP sin estado, detrás de un balanceador normal, sin afinidad de sesión.

Es una buena noticia para operar en Cloud Run, Kubernetes o cualquier autoescalado horizontal. El coste es que patrones que asumían continuidad de sesión desaparecen y hay que rediseñarlos.

Elicitación sin mantener el stream abierto

El patrón anterior para pedir datos al usuario a mitad de una tool call era mantener un stream SSE abierto mientras el servidor esperaba. En un mundo sin estado eso no encaja: si la respuesta puede caer en otra instancia, el stream colgado no sirve.

La solución (SEP-2322) es un ida y vuelta explícito. El servidor responde con InputRequiredResult, que incluye inputRequests y un requestState. El cliente reúne las respuestas y reemite la llamada original con inputResponses y el requestState devuelto. Cualquier instancia puede retomar el reintento porque todo el contexto viaja en la petición. Menos conexiones colgadas, más tolerancia a fallos.

Routing y caché a nivel de infraestructura

Dos cambios pequeños con impacto operativo grande:

• Headers de routing (SEP-2243): el transporte Streamable HTTP ahora exige Mcp-Method y Mcp-Name. Balanceadores, gateways y rate-limiters pueden enrutar y aplicar políticas sin abrir el body. Es la diferencia entre un gateway tonto y uno que entiende qué operación está pasando.
• Guías de caché (SEP-2549): los resultados de listados y recursos incluyen ttlMs y cacheScope, para que la capa de caché sepa qué puede guardar y durante cuánto.

Si operas MCP a escala, estos dos SEPs son los que te ahorran dinero y latencia.

El framework de extensiones

En lugar de meter todo en el core, la 2026-07-28 introduce extensiones identificadas por IDs en reverse-DNS, negociadas mediante un mapa de capacidades entre cliente y servidor, con sus propios repositorios ext-*, mantenedores delegados y versionado independiente de la especificación.

La idea es sana: el core se mantiene pequeño y estable, y lo que evoluciona rápido (o es opcional) vive fuera sin arrastrar a todo el protocolo en cada cambio. MCP Apps y Tasks son las dos primeras extensiones de peso.

MCP Apps: UI servida por el servidor

MCP Apps (SEP-1865) permite que un servidor entregue interfaces HTML que el host renderiza en un iframe sandboxed. Las tools declaran sus plantillas de UI por adelantado, de modo que el host puede prefetch, cachear y revisar seguridad antes de ejecutar nada. La UI renderizada se comunica con el host por el mismo JSON-RPC que el resto del protocolo, así que toda acción iniciada desde la UI pasa por la misma ruta de auditoría y consentimiento que una tool call directa.

Es el camino estándar para dar interfaz a un servidor MCP sin salirse del modelo de permisos. Si venías montando UIs a mano, esto lo normaliza.

Tasks pasa a ser extensión

Tasks llegó como feature experimental del core en 2025-11-25. El uso real destapó suficiente necesidad de rediseño como para moverlo a una extensión (SEP-2663). Ahora el ciclo de vida encaja en el modelo sin estado: el servidor puede responder a un tools/call con un handle de tarea, y el cliente lo conduce con tasks/get, tasks/update y tasks/cancel. La creación es dirigida por el servidor: el cliente anuncia la extensión y el servidor decide cuándo una llamada se ejecuta como tarea.

Un detalle que importa: tasks/list desaparece porque no se puede acotar de forma segura sin sesiones. Si dependías de listar tareas del lado servidor, hay que rediseñar ese flujo.

Autorización más cerca de OAuth/OIDC

Seis SEPs endurecen la alineación con OAuth 2.0 y OpenID Connect. Los más relevantes:

• SEP-2468: el cliente debe validar el parámetro iss según RFC 9207.
• SEP-837: el cliente declara application_type al registrarse.
• SEP-2352: las credenciales se atan al issuer; hay que re-registrar al migrar.
• SEP-2350: acumulación de scopes en el step-up.
• SEP-2351: aclaración del sufijo de descubrimiento .well-known.

Si ya tratabas tu servidor MCP como un recurso OAuth serio, es más confirmación que sorpresa. Si atajabas por el camino corto, aquí es donde te pillan.

Deprecaciones: roots, sampling y logging

Bajo la nueva política de ciclo de vida (SEP-2577), tres features quedan deprecadas —solo anotadas, siguen funcionando durante la versión publicada dentro de un año—:

• Roots → se sustituyen por parámetros de tool o configuración del servidor.
• Sampling → integración directa con la API del LLM en su lugar.
• Logging → stderr u OpenTelemetry.

Adicionalmente, los esquemas de tools soportan ya JSON Schema 2020-12 completo, con composición y condicionales (SEP-2106), y el error de recurso ausente cambia de -32002 a -32602 (SEP-2164). El W3C Trace Context (traceparent, tracestate, baggage) se estandariza en _meta (SEP-414) para trazabilidad distribuida.

Checklist de migración para un servidor en producción

Antes del 28 de julio, sobre tu servidor:

1. Quita la dependencia de sesión. Deja de exigir initialize y de emitir/leer Mcp-Session-Id. Mueve capabilities e info de cliente a _meta.
2. Reescribe la elicitación al patrón InputRequiredResult + requestState. Ningún stream SSE colgado esperando input.
3. Emite y consume los headers Mcp-Method y Mcp-Name; añade ttlMs/cacheScope donde tenga sentido.
4. Revisa tu OAuth: validación de iss, application_type en el registro, atado de credenciales al issuer.
5. Migra Tasks a la extensión y elimina cualquier uso de tasks/list.
6. Marca roots/sampling/logging para retirada y planifica sustitutos.
7. Actualiza el error code de recurso ausente a -32602.

Cuándo NO migrar de golpe

Con honestidad: no todo el mundo tiene que reescribir su transporte esta semana.

• Si tu servidor MCP es interno y de baja escala (una sola instancia, sin balanceador), el beneficio del stateless es marginal a corto plazo. Migra por mantenibilidad, no por urgencia.
• Los métodos deprecados siguen funcionando durante la versión de este año. No hay que arrancar roots/sampling/logging de forma precipitada; hazlo con plan.
• Espera a que tu SDK de referencia publique soporte estable (Tier 1 durante la ventana de diez semanas) antes de migrar en producción. Migrar contra una RC y luego contra el final es hacer el trabajo dos veces.

El punto de dolor real es la elicitación con SSE y cualquier lógica que asumiera sesión: eso sí conviene abordarlo pronto porque el rediseño no es trivial.

Conclusión

La 2026-07-28 no es un parche: es MCP reconstruido para escalar como infraestructura HTTP normal, con un core pequeño y extensiones que evolucionan por su cuenta. Para un equipo de producto, la lectura es que MCP deja de ser un experimento con estado frágil y se convierte en algo que puedes operar como cualquier otro servicio. El coste de entrada es una migración con cambios que rompen; el retorno es un stack de agentes más simple de escalar y auditar.

En Dribba llevamos tiempo construyendo y operando servidores MCP en producción —incluido dejar dribba.com operable por agentes— y ayudamos a equipos a llevar sus integraciones de agentes a estándares serios. Si estás valorando cuándo y cómo migrar tu servidor a la nueva especificación, hablémoslo.

Para profundizar en el modelo mental de MCP, ver MCP en producción: cuándo usarlo, Seguridad de MCP: proteger tu stack de agentes y A2A vs MCP: protocolos de agentes.