MCP publica la especificación 2026-07-28 con núcleo sin estado

Fuentes: MCP ships the 2026-07-28 specification with a stateless protocol core, arstechnica.com

La organización detrás del Model Context Protocol (MCP) publicó oficialmente la versión 2026-07-28 de su especificación, un cambio estructural que transforma el protocolo de bidireccional con estado a request/response sin estado. El anuncio coincide con un momento de adopción sin precedentes: los SDK de nivel 1 superan en conjunto cerca de 500 millones de descargas mensuales, y los paquetes de TypeScript y Python cruzaron recientemente la barrera de los mil millones de descargas acumuladas, según datos publicados en el blog oficial del proyecto.

El núcleo de la actualización es una decisión arquitectónica de calado. Hasta ahora, cada conexión MCP requería un intercambio initialize/initialized y mantenía un identificador de sesión (Mcp-Session-Id), lo que obligaba a enrutar las solicitudes a la misma instancia del servidor. Con la nueva especificación, esa dependencia se elimina: cada petición viaja de forma autónoma, incluyendo versión del protocolo, identidad del cliente y capacidades dentro de los metadatos _meta. Si un cliente necesita conocer las capacidades del servidor antes de operar, existe una nueva RPC opcional server/discover, pero su uso no es obligatorio. En la práctica, esto significa que cualquier petición puede aterrizar en cualquier instancia detrás de un balanceador round-robin básico, sin necesidad de almacenamiento compartido.

Otra pieza central es MRTR (Multi Round-Trip Requests), el mecanismo que sustituye a las peticiones server-to-client que antes requerían un stream bidireccional permanentemente abierto, como elicitation/create, sampling/createMessage y roots/list. Ahora, cuando una herramienta necesita información del usuario a mitad de llamada —por ejemplo, una confirmación o un parámetro faltante—, el servidor responde con resultType: "input_required" junto con las preguntas pendientes, y el cliente reintenta la llamada original con las respuestas adjuntas en inputResponses.

La especificación incorpora además enrutado basado en cabeceras HTTP (Mcp-Method y Mcp-Name), lo que permite a gateways, limitadores de tasa y WAFs operar sobre cabeceras en lugar de inspeccionar cuerpos JSON. Las respuestas a tools/list, prompts/list, resources/list y resources/read ahora llevan hints de caché (ttlMs y cacheScope), permitiendo a los clientes almacenar catálogos de herramientas de forma estable.

En el plano de seguridad y autorización, el documento introduce validación de emisor según RFC 9207 para cerrar un hueco de confusión entre servidores de autorización, vincula las credenciales de cliente al emisor que las emitió, y formaliza la depreciación del Dynamic Client Registration (DCR) en favor de los Client ID Metadata Documents (CIMD). DCR seguirá funcionando por compatibilidad, pero será eliminado en una versión futura. Roots, Sampling y Logging también quedan obsoletos, con un periodo de gracia mínimo de doce meses.

El framework de extensiones se consolida con la entrada de Tasks (junto a extensiones ya existentes como MCP Apps y Enterprise Managed Authorization), moviendo Tasks fuera del núcleo experimental hacia io.modelcontextprotocol/tasks, con endpoints tasks/get y tasks/update basados en sondeo, y un canal subscriptions/listen para notificaciones.

Los SDK oficiales de TypeScript, Python, Go y C# ya soportan la nueva versión desde el día del anuncio, con notas de migración detalladas para los cambios incompatibles. El SDK de Rust ofrece soporte en beta. La organización reconoce que existirán costes de migración, especialmente para quienes dependían de identificadores de sesión, pero asegura haber incorporado feedback temprano de pruebas para suavizar el proceso.

En conjunto, la 2026-07-28 no es una actualización incremental: redefine los supuestos fundamentales del protocolo para alinearlo con las exigencias de escalabilidad y fiabilidad que plantea su creciente adopción en flujos agentic. La dirección estratégica está clara: menos estado implícito en el transporte, más visibilidad para el modelo, más control para gateways e infraestructura, y un horizonte de deprecación predecible de doce meses que permite a los equipos planificar migraciones en lugar de reaccionar a ellas.