MCP publica una hoja de ruta centrada en HTTP y la identidad

Los Core Maintainers del Model Context Protocol (MCP), el estándar abierto alojado por la Agentic AI Foundation (AAIF) de la Linux Foundation, publicaron una hoja de ruta actualizada que fija el rumbo del protocolo para la próxima versión de la especificación y más allá. Según informó el medio tecnológico japonés Publickey, la hoja de ruta se organiza en cinco áreas prioritarias: mensajería para agentes, unificación del transporte en torno a HTTP, identidad de agentes y seguridad lista para empresa, mejora de las herramientas básicas, y una mejor experiencia de desarrollador en los SDK. El blog oficial de MCP confirma que la hoja de ruta fue elaborada conjuntamente por los Core Maintainers y la comunidad de Working Groups, y que "fija la dirección del trabajo sobre el protocolo para los próximos meses".

MCP nació en noviembre de 2024 como un protocolo propuesto por Anthropic para conectar sus modelos Claude con fuentes de datos y herramientas externas. El 9 de diciembre de 2025, la Linux Foundation anunció que había recibido la donación del protocolo y creó la Agentic AI Foundation para gobernar su evolución, con Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft y OpenAI como miembros platino. Según el anuncio de la Linux Foundation, MCP se convirtió en uno de los proyectos de código abierto de más rápido crecimiento del último año, con más de 97 millones de descargas mensuales de SDK y más de 10.000 servidores activos, integrado de forma nativa en ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot y Visual Studio Code. En julio, la extensión "Enterprise-Managed Authorization" (EMA) alcanzó la versión estable y el protocolo pasó a conexiones sin estado, una actualización mayor que facilita los despliegues a gran escala.

Cinco áreas prioritarias

Según la publicación oficial "The New MCP Roadmap", esta actualización continúa la hoja de ruta anterior publicada en marzo, que tenía cuatro prioridades: evolución y escalabilidad del transporte, comunicación entre agentes, maduración de la gobernanza y preparación para la empresa. La mayor parte del progreso de los últimos cinco meses llegó con la versión de especificación del 28 de julio de 2026 (2026-07-28). Se eliminaron las sesiones a nivel de protocolo y el saludo de inicialización, permitiendo que los servidores escalen horizontalmente sin mantener estado (SEP-2575, SEP-2567); los clientes ganaron una llamada `server/discover` para conocer las capacidades de un servidor antes de conectarse; y los resultados de listas se volvieron cacheables (SEP-2549).

• Mensajería para agentes: construir eventos iniciados por el servidor (webhooks y canales) para que los clientes dejen de sondear en busca de resultados, y madurar la extensión Tasks (SEP-2663) hasta su inclusión en la especificación principal
• Unificación del transporte en torno a HTTP: extender Streamable HTTP también a los servidores locales, usando HTTP/2 sobre stdio para conservar el multiplexado sin perder las garantías de un subproceso
• Identidad de agentes y seguridad lista para empresa: finalizar Demonstrating Proof of Possession (DPoP) y definir la identidad y delegación de agentes mediante Workload Identity Federation (SEP-1933) e intercambio de tokens ID-JAG, en lugar de claves de API pegadas o tokens de larga duración
• Mejora de las herramientas básicas: estandarizar la forma de las respuestas de `tools/call` e introducir el descubrimiento progresivo, para que un modelo no tenga que cargar todo el catálogo de herramientas de un servidor antes de que el usuario haga una sola pregunta
• Mejor experiencia de desarrollador en los SDK: perfeccionar la ergonomía de las API y la precisión de la documentación, ya que muchos desarrolladores —y cada vez más los propios agentes de IA— escriben código de cliente o servidor MCP directamente a partir de los SDK

Qué resuelve esto para las empresas

El modelo de autorización actual de MCP asume que una persona aprueba el acceso en un navegador. El blog oficial señala que una proporción creciente de quienes llaman son ahora agentes que se ejecutan como cargas de trabajo en la nube con su propia identidad, actúan en nombre de un usuario ausente o delegan una autoridad más limitada a subagentes. El trabajo sobre identidad busca dar a los servidores MCP una forma estandarizada de reconocer y confiar en esas identidades de agentes, apoyada en estándares existentes en lugar de claves de API pegadas, coordinándose con los grupos de trabajo IETF OAuth y WIMSE en la mecánica de intercambio de tokens subyacente. La unificación en torno a HTTP importa igual de operativamente: un servidor MCP remoto construido sobre Streamable HTTP ya no se distingue de cualquier otra carga de trabajo HTTP, lo que permite a las empresas alojarlo y escalarlo sobre la misma infraestructura —balanceadores de carga, gateways, observabilidad— que ya usan para sus API, en vez de construir una tubería a medida para un protocolo aparte.

Sobre la priorización, el blog oficial es explícito: las propuestas (SEP) que encajan en una de las cinco áreas prioritarias reciben una revisión acelerada, mientras que las demás no se rechazan automáticamente pero enfrentan plazos más largos y una barra de justificación más alta, ya que la capacidad de revisión de los mantenedores es limitada y se dirige deliberadamente a estas cinco áreas.

Por qué importa para los equipos que construyen agentes

MCP ya es el conector que usan la mayoría de los grandes productos de IA —ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code— para llegar a herramientas externas, lo que convierte esta hoja de ruta en mucho más que un documento interno de ingeniería: señala hacia dónde se dirige el estándar de facto de la conectividad entre agentes y herramientas. Para las empresas que conectan agentes de IA con sus sistemas internos, el trabajo de unificación HTTP debería reducir el coste operativo de ejecutar servidores MCP a gran escala, al eliminar la necesidad de infraestructura separada para despliegues basados en stdio o WebSocket. El trabajo de identidad aborda un riesgo muy concreto que los equipos ya cargan: claves de API compartidas entre servicios o que siguen siendo válidas después de que un empleado cambia de puesto. Una forma estandarizada de acotar y revocar las credenciales propias de un agente, respaldada por registros de auditoría, sustituye el intercambio informal de claves por algo que un equipo de seguridad puede gobernar de verdad. Las organizaciones que hoy autentican sus conexiones MCP con tokens de larga duración deberían tomar esto como una señal temprana para planear una migración en cuanto se publique este trabajo de identidad y delegación.