MCP actualiza su hoja de ruta y apunta a lo que frena los agentes en producción: tareas asíncronas, identidad de agentes y un único transporte HTTP

Los mantenedores del Model Context Protocol publicaron el 22 de agosto una hoja de ruta renovada con cinco áreas prioritarias para los próximos seis a doce meses. Leídas en conjunto, dibujan un protocolo que ya no necesita demostrar el concepto y ahora se dedica a resolver lo que de verdad bloquea los despliegues en producción: el trabajo de larga duración, la autenticación de agentes y una historia de transporte que había dejado de tener sentido.

El área más importante es la mensajería agéntica. MCP ha acumulado tres respuestas solapadas a “el servidor todavía no ha terminado” — Tasks, subscriptions/listen y las notificaciones de progreso — repartidas entre grupos de trabajo distintos. Los mantenedores nombran el riesgo sin rodeos: tres primitivas que no comparten ciclo de vida, modelo de cancelación ni superficie de errores. Este ciclo se compromete a los eventos iniciados por el servidor, webhooks incluidos, para que los servidores avisen a los clientes cuando el trabajo asíncrono termina en lugar de obligar a un polling caro desde el cliente. La extensión Tasks (SEP-2663) sigue avanzando hacia su inclusión en el núcleo del protocolo.

La identidad es la segunda gran apuesta. La autorización de MCP se diseñó para una persona aprobando accesos desde un navegador. Cada vez más, quien llama es un workload en la nube con identidad propia, actuando por un usuario que no está presente — o creando subagentes que deberían recibir menos autoridad que su padre. Los servidores actuales dependen de API keys pegadas y refresh tokens de larga vida. El nuevo grupo de trabajo de Agent Identity finalizará DPoP (Demonstrating Proof of Possession) y construirá la delegación sobre estándares existentes: Workload Identity Federation (SEP-1933), el grant de aserción ID-JAG y el intercambio de tokens de RFC 8693, en coordinación con los grupos OAuth del IETF. Si tu servidor MCP todavía se autentica con un token en una variable de entorno, esta es la parte de la especificación que conviene vigilar.

El plan de transporte es el más contundente. La versión del 28 de julio convirtió un servidor MCP remoto en un workload HTTP normal — pero cada función nativa de HTTP sigue necesitando un segundo diseño específico para stdio, y los SDK mantienen dos pipelines de transporte. La solución propuesta: Streamable HTTP como binding único, hablado como HTTP/2 sobre stdin/stdout en los servidores locales. Un solo modelo de transporte, con la práctica HTTP estándar encima, incluida una caché basada en ETags para los resultados de tool calls.

Completan la lista un rediseño del confuso retorno dual de tools/call (content frente a structuredContent), el descubrimiento progresivo para que los clientes aprendan las herramientas según las necesitan, y un experimento para generar los SDK directamente desde la especificación con una suite de conformidad.

Nada de esto es un compromiso firme — los mantenedores lo dicen explícitamente. Pero los SEP dentro de estas áreas reciben revisión acelerada, lo que convierte el roadmap en un mapa fiable de hacia dónde va el escaso tiempo de revisión del protocolo. Para quien construye agentes sobre MCP, la dirección está clara: menos primitivas que compongan mejor, y una identidad capaz de superar una auditoría de seguridad empresarial.

Fuentes

Lecturas relacionadas