Introducción
El 22 de agosto de 2026, los mantenedores del Model Context Protocol publicaron su hoja de ruta para los próximos seis a doce meses. Apenas un mes después de la especificación 2026-07-28 —que había introducido un núcleo stateless para servidores remotos—, este documento estructura cinco áreas de trabajo prioritarias y formaliza una gobernanza por grupos de trabajo. El objetivo es claro: convertir un protocolo prometedor en un estándar de integración confiable para equipos enterprise.
El fin de la doble pila de transporte
El problema es conocido por cualquier equipo que haya desarrollado un servidor MCP: los servidores remotos utilizan Streamable HTTP, los locales se comunican por stdio, y los SDKs mantienen dos pipelines distintos, con las diferencias de comportamiento que eso implica. La solución adoptada es HTTP/2 over stdio —el protocolo HTTP encapsulado directamente en la comunicación stdin/stdout de un subproceso local, conservando las garantías de ciclo de vida de la gestión de procesos tradicional. Para los equipos de desarrollo, esto se traduce en herramientas de testing y CI unificadas, y en la eliminación de toda una clase de errores vinculados a esa dualidad.
Este trabajo incorpora también los ETags para el almacenamiento en caché de resultados de herramientas y recursos, en línea con los TTL introducidos en julio. El resultado esperado: menos llamadas redundantes sin necesidad de lógica adicional del lado del cliente.
La identidad de los agentes, sin los antipatrones actuales
El segundo eje es el más relevante para los equipos de seguridad. Las integraciones MCP siguen apoyándose con demasiada frecuencia en claves API compartidas o en refresh tokens de larga duración —precisamente lo que una auditoría SOC 2 o una política zero-trust identifica como inaceptable.
La hoja de ruta apunta a dos mecanismos complementarios. DPoP (RFC 9449) vincula un token a la clave privada efímera del cliente mediante una firma JWT: un token interceptado queda inutilizable, sin necesidad de operar una PKI ni gestionar certificados. El Workload Identity Federation (SEP-1933), por su parte, permite a un agente en la nube obtener permisos a través de su identidad de carga de trabajo, sin credenciales almacenadas. Estos trabajos se coordinan con los grupos IETF OAuth y WIMSE, abriendo una convergencia con los stacks de identidad enterprise ya desplegados en la mayoría de las organizaciones.
Descubrimiento progresivo y rediseño de la interfaz de herramientas
La interfaz tools/call devuelve simultáneamente content y structuredContent, lo que ha generado implementaciones divergentes entre servidores y clientes. El rediseño previsto clarifica la semántica de una vez por todas.
Aún más relevante para la arquitectura: el descubrimiento progresivo permitirá a los clientes cargar las herramientas de un servidor a medida que las necesiten, en lugar de ingerir el catálogo completo al arrancar. Para un servidor que expone cientos de herramientas, esto representa un cambio arquitectónico directo, con un impacto medible en la latencia inicial y en la saturación del contexto de los modelos.
Una gobernanza abierta a los contribuyentes
El documento formaliza el marco de las Specification Enhancement Proposals (SEPs) con una regla clara: las SEPs alineadas con un área prioritaria se benefician de una revisión acelerada. Cada área cuenta con un Working Group con mantenedores designados públicamente. Para los equipos que quieran incidir en la evolución del protocolo, el camino está ahora documentado: primero el Working Group, luego la SEP formal.
SDKs generados desde la especificación
Los SDKs actuales se mantienen de forma manual y tienden a divergir de la especificación entre versiones. El objetivo de este ciclo es generar un SDK de referencia directamente desde la spec, validado contra una suite de pruebas de conformidad publicada. Menos desviación, menos correcciones post-release y ejemplos de inicio coherentes con la versión en producción.
Qué anticipar desde ahora
Esta hoja de ruta no impone una migración inmediata, pero define las decisiones estratégicas a tomar desde hoy. Alinear las implementaciones con Streamable HTTP permite absorber la transición a HTTP/2 over stdio sin rupturas. Evaluar DPoP para las cargas de trabajo en la nube evita construir sobre patrones que el estándar irá haciendo obsoletos. Para los equipos con necesidades específicas, los Working Groups están abiertos y la ventana para influir en la próxima especificación está disponible.