En pocas palabras: La nueva hoja de ruta del Model Context Protocol (MCP) define cinco áreas prioritarias para la próxima release: mensajería agéntica, transporte HTTP unificado, identidad de agentes con seguridad empresarial, mejora de SDKs y priorización de SEPs, con el objetivo de preparar el protocolo para agentes reales en producción.
Los Core Maintainers del Model Context Protocol publicaron en julio de 2026 una hoja de ruta actualizada con cinco áreas prioritarias: mensajería agéntica, transporte HTTP unificado, identidad de agentes con seguridad empresarial, mejora de SDKs y priorización de propuestas (SEPs). El objetivo declarado: preparar al protocolo para agentes reales corriendo en producción.
La hoja de ruta es el plan oficial de trabajo del Model Context Protocol (MCP), el estándar abierto que conecta asistentes y agentes de IA con herramientas, datos y APIs externas. La desarrollaron los Core Maintainers del protocolo junto a los grupos de trabajo de la comunidad, y cubre la próxima release de la especificación y más allá. Cada área tiene maintainers responsables y uno o más Working Groups detrás.
En 30 segundos
- Los Core Maintainers publicaron la hoja de ruta, con cinco áreas prioritarias y grupos de trabajo abiertos a contribuidores.
- El transporte se unifica en HTTP nativo: un servidor MCP remoto pasa a ser un workload HTTP común, hosteable en la infraestructura que ya tenés.
- La identidad de agentes se estandariza con DPoP, Workload Identity Federation y el grant ID-JAG, en reemplazo de las API keys “pegadas”.
- Llegan eventos iniciados por el servidor (webhooks y channels) para eliminar el polling, y la extensión Tasks entra a la especificación formal.
- Los SEPs dentro de las áreas prioritarias tienen revisión acelerada; los que quedan afuera compiten por un tiempo de revisión escaso.
¿Qué cambia en MCP para el desarrollo de agentes?
Lo que antes figuraba en el horizonte del roadmap anterior ahora es prioridad formal: eventos iniciados por el servidor, mejoras en los tipos de resultado e identidad de agentes, según el anuncio oficial y su cobertura en The New Stack. Es decir, el protocolo deja de resolver el “conectar un tool” y se pone a resolver el “operar un agente”.
Un poco de contexto para el que llegó tarde: Anthropic presentó MCP a fines de 2024, y en poco menos de dos años el estándar creció tanto que los problemas ya son de producción, no de adopción. Los loops corren más tiempo, los servidores quieren enviar resultados sin que se los pidan, y la seguridad pensada para un humano con navegador se queda corta cuando el que llama es un workload en la nube. Ese es el telón de fondo de esta actualización.
Los cinco pilares de la hoja de ruta
El documento se organiza en cinco áreas, cada una con Core Maintainers responsables y uno o más Working Groups que la llevan adelante. En dos líneas cada una:
- Mensajería agéntica: primitivas para loops largos, resultados en streaming y corrección de rumbo a mitad de tarea.
- Transporte HTTP nativo unificado: un solo transporte para servidores remotos y locales, sobre HTTP estándar.
- Identidad de agentes y seguridad empresarial: estándares OAuth en lugar de API keys y tokens de larga vida.
- Experiencia de desarrollo en los SDKs: ergonomía, conformidad con la spec y documentación clara en todas las plataformas.
- Priorización de propuestas: revisión acelerada para los SEPs que caen dentro de estas áreas.
Ojo con un detalle: los cinco pilares tienen grupos de trabajo activos o en formación, y todos buscan contribuidores. Si querés influir en cómo queda la spec, esta es la ventana.
¿Cómo van a comunicarse los agentes sin polling?
Con eventos iniciados por el servidor. Ponele que tu agente tiene que reindexar una base completa: levantás el job, el servidor procesa por tandas, el loop corre veinte minutos, tu cliente se queda preguntando cada dos segundos si ya terminó, y mientras tanto nadie sabe si el proceso sigue vivo o se murió a los tres minutos, porque el patrón request-response nunca contempló que una tarea pueda vivir más que la paciencia de un timeout HTTP. Más contexto en seguridad empresarial con Microsoft Intune.
La respuesta del roadmap tiene tres piezas. Primero, los server-initiated events: webhooks y channels para que el servidor avise cuando hay resultados, en lugar de que el cliente ande consultando. Segundo, una revisión de composición entre los Working Groups para que las primitivas nuevas funcionen bien entre sí (no sirve tener cinco mecanismos que se pisan). Tercero, la extensión Tasks, que venía como experimental y ahora se madura para entrar en la especificación. A esto se suma algo que ya existe en el protocolo: las notificaciones de progreso, que permiten seguir una tarea larga sin morir de espera.
¿Y qué es “corregir el rumbo” en criollo? Decirle al servidor a mitad de tarea “pará, cambiá esto” sin cancelar todo y arrancar de cero. Cualquiera que haya cancelado un job de veinte minutos por un error en el prompt sabe por qué eso importa.
¿Qué es el transporte HTTP unificado en MCP?
Es la idea de que un servidor MCP remoto no se trate distinto de cualquier otro workload HTTP: lo hosteás, lo escalás y lo operás con la misma infraestructura que ya usás para tus APIs. El modelo ya probó que escala (que no es poco), dice el roadmap, y ahora busca estirarlo a otros modos de despliegue, incluidos los servidores locales.
En la práctica esto significa que no necesitás infraestructura especial. Levantás el servidor MCP al lado de tus servicios, con el balanceador y el monitoreo que ya tenés, ya sea en un cloud grande o en un VPS de un proveedor local como donweb.com. Y unificar en un solo transporte tiene un efecto secundario piola: menos combinaciones cliente-transporte-servidor para testear y menos código duplicado en los SDKs.
El detalle para los que tienen servidores locales por STDIO: el documento dice que el modelo se va a extender para cubrirlos, pero todavía no especifica cómo. Tomalo con pinzas hasta que haya spec.
¿Cómo funciona la identidad de agentes en MCP?
A agosto de 2026, el flujo de autorización vigente de MCP (spec 2025-06-18) está pensado para una persona que aprueba el acceso en un navegador. Funciona para clientes interactivos. Pero buena parte de los llamadores ahora son agentes corriendo como workloads en la nube, con identidad propia, actuando en nombre de un usuario que no está presente, o delegando autoridad más acotada a sub-agentes. El roadmap quiere que los servidores MCP reconozcan y confíen en esas identidades de forma estandarizada, sobre estándares existentes en lugar de API keys “pegadas” y tokens de larga vida.
El plan concreto pasa por cuatro frentes:
- DPoP (Demonstrating Proof of Possession): finalizarlo y empujar su adopción, para que un token solo sirva desde quien lo solicitó.
- Workload Identity Federation: un camino bien definido para que un agente con identidad de workload actúe con autoridad delegada.
- ID-JAG y Enterprise-Managed Authorization: el grant detrás de la autorización gestionada por la empresa, clave para delegar a sub-agentes.
- Intercambio estándar de tokens y trabajo con los grupos de OAuth del IETF, para que los estándares base evolucionen con lo que la identidad de agentes necesita.
Esta es, para mí, el área más importante de las cinco. La identidad es lo que frena a los equipos de seguridad de cualquier empresa grande: nadie quiere firmar un agente con un token eterno en un archivo de configuración. Si MCP resuelve esto bien, se abre la puerta corporativa de una. Lo explicamos a fondo en cómo funciona ChatGPT por dentro.
¿Qué cambia en el manejo de herramientas y en los SDKs?
El tool calling es la parte de MCP que más tocan los desarrolladores, y según los maintainers se sostuvo bien. Donde flojea es en los resultados: una respuesta puede traer el mismo output en más de una forma, y el que desarrolla el servidor no tiene forma de saber cuál de esas formas le va a mostrar el cliente al modelo. La meta es un contrato único y claro para los resultados.
El otro problema es la escala. Conectás un servidor con cien tools y el modelo paga esa superficie completa antes de que el usuario haya hecho una sola pregunta. Peor: la selección de herramientas se degrada cuando la lista crece. Por eso arrancan un esfuerzo de descubrimiento progresivo: la idea es que el servidor arranque con un punto de entrada chico y vaya revelando más catálogo conforme la conversación se acota. (Suena obvio escrito así; que nadie lo haya estandarizado hasta ahora dice algo de lo joven que es todo esto.)
En SDKs, la inversión va por ergonomía, conformidad con la especificación y documentación clara en cada plataforma y lenguaje soportado. El motivo es nuevo y tiene gracia: muchos desarrolladores hoy arman clientes y servidores MCP apuntando un agente de código a las librerías. O sea que tus “lectores” son modelos de lenguaje, y una API ambigua o un doc desactualizado se traduce directo en código roto.
¿Cómo proponer cambios a MCP mediante SEPs?
Los Specification Enhancement Proposals (SEPs) que caen dentro de las cinco áreas prioritarias tienen revisión acelerada y la mejor chance de aceptación. Los que quedan afuera no se rechazan por defecto, pero el tiempo de revisión de los maintainers es escaso y va primero al roadmap. Traducción: si querés que tu propuesta prospere, anclala en un pilar.
El procedimiento recomendado: identificá el área prioritaria que le corresponde, presentala ante el Working Group relevante y trabajá con sus miembros para darle forma. El roadmap nombra a los Core Maintainers responsables de cada área. Y si todavía no tenés una propuesta formal, hay tres puertas de entrada: unirte a un Working Group o Interest Group, comentar o abrir un SEP en el repositorio oficial del proyecto en GitHub, o arrancar una extensión experimental en el repositorio de extensiones antes de formalizar nada.
MCP antes y después: qué cambia con la hoja de ruta
Esta tabla resume el estado actual frente a la dirección que marca el documento. Aclaración honesta: es un roadmap, no un changelog; varias de estas cosas todavía no están en la spec. Sobre eso hablamos en modelos de lenguaje que razonan.
| Área | Antes | Con la hoja de ruta |
|---|---|---|
| Mensajería | Request-response; el cliente consulta (polling) para saber si hay novedades | Eventos iniciados por el servidor: webhooks y channels; extensión Tasks en la spec |
| Transporte | Varios transportes según el caso (remoto vs. local) | Unificación en un transporte HTTP nativo, extendido también a servidores locales |
| Identidad | Aprobación manual en el navegador; API keys y tokens de larga vida | Identidad estandarizada de agentes: DPoP, Workload Identity Federation, ID-JAG |
| Resultados de tools | El mismo output puede llegar en varias formas, sin contrato claro | Un contrato único de resultados y descubrimiento progresivo de tools |
| SDKs | Ergonomía y documentación desparejas entre plataformas | Inversión en ergonomía, conformidad con la spec y docs en todos los lenguajes |
¿Por qué la hoja de ruta importa para tu stack?
Porque MCP ya es la capa de integración de facto de los agentes: OpenAI y Google lo sumaron a sus ecosistemas durante 2025, Cloudflare permite desplegar servidores MCP remotos, y el protocolo resuelve el viejo problema n×m de las integraciones. Sin un estándar, conectar n agentes con m herramientas son n×m integraciones a medida; con MCP, n más m. Para un equipo que conecta el mismo agente con Salesforce, BigQuery y APIs internas, la diferencia entre reescribir cada conector y configurar servidores MCP es tiempo de mercado.
¿Y las alternativas? El function calling nativo sigue existiendo, pero es específico de cada proveedor. El protocolo A2A de Google, presentado en 2025 y hoy alojado en la Linux Foundation, resuelve otra cosa: la coordinación entre agentes, no entre agentes y herramientas. En un stack real suelen convivir: A2A para que los agentes hablen entre sí, MCP para que toquen tus sistemas.
Para equipos en Latinoamérica el punto práctico es el hosting: un servidor MCP remoto es un workload HTTP, y eso lo podés correr en la infraestructura que ya tengas contratada. La barrera de entrada baja un escalón.
Errores comunes al leer la hoja de ruta
Tomarla como calendario de lanzamientos. El documento marca dirección para la próxima release de la especificación “y más allá”, sin fechas. Si tu planificación de producto depende de fechas concretas de MCP, estás leyendo mal el documento: lo que hay es prioridad, no cronograma.
Seguir emitiendo tokens de larga vida para agentes. Si hoy tu integración depende de una API key que no expira, estás acumulando deuda de seguridad que la spec futura te va a obligar a migrar. El roadmap es explícito: DPoP y federación de identidad por encima de las llaves pegadas. Empezá a mirar Workload Identity ahora, no cuando te lo exija un cliente.
Exponer todo el catálogo de tools de una. El propio documento admite que la selección de herramientas empeora cuando la lista crece y que el modelo paga la superficie completa. Diseñá servidores con entradas acotadas y catálogo progresivo, aunque la spec todavía no lo exija. Cubrimos ese tema en detalle en el ecosistema de Google al detalle.
Mandar un SEP sin área prioritaria ni Working Group detrás. Sin anclaje en los cinco pilares, tu propuesta compite por un tiempo de revisión que ya está copado por el roadmap. Primero el Working Group, después el papel.
Preguntas Frecuentes
¿Qué es la hoja de ruta de MCP?
Es el plan oficial de trabajo del Model Context Protocol, publicado por los Core Maintainers junto a los grupos de trabajo de la comunidad. Organiza los próximos meses en cinco áreas: mensajería agéntica, transporte HTTP unificado, identidad de agentes, mejora de SDKs y priorización de propuestas.
¿MCP es gratis y dónde está disponible?
Sí, MCP es un protocolo abierto y gratuito. La especificación, los SDKs y los SEPs viven en repositorios públicos de GitHub, y el roadmap se publica en el blog oficial de modelcontextprotocol.io. No hay licencias ni planes de pago.
¿Cuándo entran en vigencia los cambios anunciados?
El roadmap no anuncia fechas: marca la dirección para la próxima release de la especificación y más allá. Algunas piezas ya existen, como las notificaciones de progreso; otras, como los webhooks, channels y la extensión Tasks, se están madurando en los grupos de trabajo antes de entrar a la spec.
¿Cómo funciona la identidad de agentes en MCP?
Se estandariza con DPoP (Demonstrating Proof of Possession), Workload Identity Federation y el grant ID-JAG de Enterprise-Managed Authorization, todos sobre estándares OAuth del IETF. La idea es que un servidor MCP reconozca y confíe en un agente que corre en la nube, sin API keys pegadas ni tokens de larga vida.
¿MCP reemplaza a function calling o al protocolo A2A?
No, resuelven planos distintos. Function calling es una capacidad nativa de cada modelo; MCP es la capa abierta que conecta agentes con herramientas y datos; A2A, presentado por Google en 2025, coordina agentes entre sí. En producción suelen convivir.
Conclusión
Con esta hoja de ruta, los maintainers de MCP dejaron en claro por dónde va el protocolo: menos fricción de infraestructura, identidad de verdad para los agentes y un contrato de desarrollo más predecible. Para los que construimos con esto todos los días, las dos áreas a vigilar son identidad (DPoP y federación) y descubrimiento progresivo, porque son las que destraban el uso corporativo real.
¿Qué hacer ahora? Si desarrollás servidores MCP, pensá en HTTP nativo y catálogos acotados desde el diseño. Si trabajás en una empresa, empezá a evaluar Workload Identity con tu equipo de seguridad. Y si querés incidir en la spec, esta es la ventana: los Working Groups se están formando y un SEP bien anclado en los pilares tiene la mejor recepción en años.