El Model Context Protocol publicó el 28 de julio la revisión 2026-07-28, que sustituye a la 2025-11-25, y el anuncio la presenta como el cambio que convierte MCP en simples peticiones y respuestas sin estado. Para quien tiene servidores MCP en producción, es una migración: los propios responsables del protocolo dicen que el coste recae sobre todo en quienes dependían de los identificadores de sesión.
Qué cambia en el núcleo
El registro de cambios elimina el saludo inicial initialize y las sesiones del protocolo, incluida la cabecera Mcp-Session-Id. Ahora cada petición lleva en _meta su versión del protocolo, la identidad del cliente y sus capacidades. Los servidores tienen que implementar una llamada server/discover que anuncia lo que admiten, aunque los clientes no están obligados a usarla. El estado que un servidor todavía necesite entre llamadas viaja como identificadores explícitos que emite el servidor y que el cliente devuelve como argumentos normales de las herramientas.
Con eso cambian otras piezas:
- Cabeceras para enrutar. En Streamable HTTP son obligatorias las cabeceras
Mcp-MethodyMcp-Name, que deben coincidir con el cuerpo, para que las pasarelas puedan enrutar y autorizar sin leerlo. - Listas cacheables. Los resultados de
tools/list,prompts/listy de las listas de recursos declaran ahorattlMsy uncacheScope; los resultados privados no pueden compartirse entre contextos de autorización distintos. - Datos a mitad de petición. Los servidores ya no envían peticiones propias al cliente para pedir datos, muestreo o raíces. Devuelven un resultado marcado como
input_requiredy el cliente repite la petición original con las respuestas. - Un solo canal de suscripciones. Un único flujo
subscriptions/listensustituye al flujo HTTP GET y a las suscripciones a recursos, y ya no se puede reanudar un flujo cortado: hay que volver a enviar la petición. - Eliminado y en retirada. Desaparecen
pingylogging/setLevel. Las raíces, el muestreo y los registros quedan en retirada con al menos doce meses de aviso, y el registro dinámico de clientes se retira en favor de los documentos de metadatos del cliente.
Lo que no hace falta cambiar de golpe
La compatibilidad funciona por épocas. Un servidor puede atender sesiones antiguas con initialize y peticiones modernas con _meta desde el mismo punto de acceso, y la matriz de la propia especificación muestra dónde se rompe: un cliente sólo moderno falla contra un servidor antiguo, un cliente antiguo falla contra un servidor sólo moderno, y los clientes y servidores que admiten las dos épocas hacen de puente. Las extensiones, como las tareas de larga duración o MCP Apps, son opcionales, vienen desactivadas y quedan fuera del núcleo.
Cómo van los SDK oficiales
Según el anuncio, los cuatro SDK principales hablan la nueva revisión, y sus notas de versión dan el detalle. El SDK de Python 2.0.0 la admite y sirve todas las revisiones anteriores desde el mismo servidor. TypeScript la incluye en su línea 2.0, que sus notas describen como primera beta, con una herramienta de conversión automática y una guía de migración. El SDK de Go 1.7.0 la admite, pero en Streamable HTTP sólo si se activa su opción sin estado; si no, los clientes vuelven a 2025-11-25. C# 2.0.0 se alinea con la revisión y marca las funciones en retirada con avisos del compilador.
El orden práctico para un equipo: actualizar el SDK, revisar dónde el código depende de identificadores de sesión o de peticiones iniciadas por el servidor, y decidir si el servidor tiene que admitir las dos épocas mientras sigan en uso clientes antiguos.
Lecturas relacionadas
- Versiones y compatibilidad en la revisión 2026-07-28 — especificación de MCP
- Guía de migración del SDK de Python — MCP
- Meta convierte sus herramientas para desarrolladores en servicios MCP para agentes de IA — IA al Día