MCP 2026-07-28: qué cambia en el Model Context Protocol

La especificación 2026-07-28 del Model Context Protocol (MCP), publicada el 28 de julio de 2026, convierte el protocolo en uno sin estado: desaparecen las sesiones y el saludo inicial, y cada petición se describe sola. Además depreca Roots, Sampling y Logging, mueve las tareas a una extensión y endurece la autorización. Si tienes servidores o clientes MCP en producción, hay trabajo de migración: un cliente que solo habla la versión nueva no se entiende con un servidor antiguo.

Qué es MCP (Model Context Protocol), en un párrafo

MCP es un estándar abierto para conectar asistentes y agentes de IA con herramientas y datos externos: un servidor MCP expone «herramientas» (consultar un pedido, crear un ticket) y recursos, y cualquier cliente compatible (un IDE, un asistente, un agente propio) puede usarlos sin una integración a medida para cada uno. Desde diciembre de 2025 el proyecto forma parte de la Agentic AI Foundation, bajo la Linux Foundation; las decisiones técnicas siguen en manos de sus mantenedores. Es la pieza que usamos cuando integramos IA con los sistemas de una empresa. Si quieres probarlo en tu equipo, aquí explicamos cómo conectar un servidor MCP a Claude Code.

Qué cambia en la especificación MCP 2026-07-28

Según la página oficial de cambios, frente a la versión anterior (2025-11-25):

• Sin sesiones. Se eliminan las sesiones a nivel de protocolo y el encabezado Mcp-Session-Id. Si necesitas estado entre llamadas, el servidor entrega un identificador explícito que el cliente envía como argumento normal de la herramienta.
• Sin saludo inicial. Desaparece el intercambio initialize / notifications/initialized. Cada petición lleva en _meta la versión del protocolo y las capacidades del cliente, y un servidor nuevo debe implementar server/discover.
• El servidor ya no pregunta por su cuenta. roots/list, sampling/createMessage y elicitation/create dejan de ser peticiones del servidor al cliente. Ahora el servidor responde «necesito más datos» (input_required) y el cliente repite la petición con las respuestas.
• Notificaciones en un solo flujo. subscriptions/listen reemplaza el endpoint GET y resources/subscribe, y se elimina la reanudación de flujos SSE: si un flujo se corta, el cliente vuelve a pedirlo.
• Encabezados nuevos en HTTP. Las peticiones POST de Streamable HTTP llevan Mcp-Method y Mcp-Name, útiles para enrutar y filtrar en balanceadores y gateways.
• Tareas como extensión. Las tareas largas salen del núcleo a la extensión io.modelcontextprotocol/tasks, con consulta periódica (tasks/get) en lugar de una llamada bloqueante.
• Caché explícita. Los resultados de listas y lecturas declaran cuánto tiempo pueden guardarse (ttlMs) y para quién (cacheScope).
• Trazas. Se documenta cómo propagar el contexto de OpenTelemetry (traceparent, tracestate, baggage) dentro de _meta. Es una convención, no una obligación nueva.

Lo que queda deprecado

Roots, Sampling y Logging quedan deprecados. Siguen funcionando durante la ventana de deprecación (al menos 12 meses, según la nueva política de ciclo de vida), pero las implementaciones nuevas no deberían adoptarlos. Las alternativas que propone la especificación: pasar carpetas o archivos como parámetros de la herramienta en lugar de Roots, llamar directamente a la API del proveedor del modelo en lugar de Sampling, y escribir logs en stderr u OpenTelemetry en lugar de Logging. El transporte HTTP+SSE, deprecado desde la versión 2025-03-26, entra en la nueva política de ciclo de vida.

Autorización más estricta

• El servidor de autorización debería enviar el parámetro iss (RFC 9207) y el cliente debe validarlo cuando viene.
• Las credenciales quedan atadas al servidor de autorización que las emitió: no se reutilizan con otro.
• El registro dinámico de clientes (DCR) se depreca a favor de los Client ID Metadata Documents (CIMD); DCR sigue disponible por compatibilidad.

Qué significa para quien tiene servidores MCP en producción

La ventaja es operativa. Un servidor sin sesiones se puede desplegar detrás de un balanceador normal, escalar en varias instancias o correr como función serverless sin «afinidad de sesión»: cualquier instancia atiende cualquier petición. Los nuevos encabezados y la caché explícita también facilitan poner un gateway delante.

El costo está en la compatibilidad entre eras. Según la matriz de la página de versionado, entre dos implementaciones modernas no hay problema. Si el cliente y el servidor están en eras distintas, solo funciona si uno de los dos soporta ambas («dual-era»): un cliente que solo habla la versión moderna falla con un servidor antiguo, y un cliente antiguo falla con un servidor que solo habla la moderna, porque los clientes antiguos no tienen forma de adaptarse.

Los cuatro SDK oficiales de nivel 1 (TypeScript, Python, Go y C#) ya hablan la nueva versión. Algunos cambios de nombre a tener en cuenta: en Python el paquete mcp pasó a la versión 2 y FastMCP se llama ahora MCPServer; en TypeScript el SDK se separó en @modelcontextprotocol/server y @modelcontextprotocol/client, con un codemod para migrar.

Checklist de migración

1. Inventario. Lista tus servidores y clientes MCP, la versión del SDK de cada uno y quién los consume (internos, clientes, herramientas de terceros).
2. Busca dependencias de sesión. Cualquier lógica que use Mcp-Session-Id o guarde estado por conexión debe pasar a identificadores explícitos en los argumentos.
3. Revisa Roots, Sampling y Logging. Si los usas, planifica el reemplazo dentro de la ventana de 12 meses.
4. Actualiza el SDK a la versión que soporta 2026-07-28 y sigue su guía de migración oficial.
5. Decide la estrategia de compatibilidad. Si no controlas a todos tus clientes, tu servidor debería soportar las dos eras durante la transición.
6. Revisa la autorización. Validación de iss, credenciales por emisor y, si haces registro dinámico, el paso a CIMD.
7. Prueba con el cliente real (el IDE o asistente que usan tus equipos), no solo con pruebas unitarias.
8. Observa. Aprovecha la propagación de trazas para seguir una llamada desde el agente hasta tu sistema.

Qué significa para una empresa que integra IA con sus sistemas

Si tu empresa conecta asistentes o agentes de IA con su ERP, su CRM o sus bases de datos mediante MCP, este cambio no es urgente para mañana, pero sí para el próximo año: los SDK nuevos ya tienen versión estable (el paquete mcp de Python publicó la 2.0.0 el mismo 28 de julio) y las funciones deprecadas tienen una ventana de deprecación de al menos 12 meses. Es buen momento para revisar también qué permisos tiene cada herramienta expuesta, porque la migración obliga a tocar ese código de todos modos.

Si quieres que revisemos tus servidores MCP o diseñemos la integración desde cero, escríbenos: trabajamos de forma remota con empresas de cualquier país.