El mes pasado pasaste una tarde conectando unas cuantas herramientas internas a MCP (Model Context Protocol, el estándar de facto para conectar aplicaciones de IA a sistemas y datos externos). Servidores configurados uno a uno, permisos ajustados, todo funcionando. Y esta semana ves la noticia: MCP anunció un nuevo roadmap — “se eliminan las sesiones a nivel de protocolo”, “se reemplazan las peticiones iniciadas por el servidor”. Tu primer pensamiento probablemente sea: otra vez, ¿otra migración? Respira. Este artículo desglosa qué dice realmente el roadmap oficial publicado el 22 de agosto, qué cambios ya llegaron con la especificación 2026-07-28 y por qué los usuarios de Hermes ya están en el nuevo tren.

Qué anunció MCP: un roadmap de cinco prioridades

El 22 de agosto, los dos mantenedores principales de MCP — David Soria Parra y Den Delimarsky — publicaron el post oficial The New MCP Roadmap, con su correspondiente actualización en la página del roadmap. Es la actualización formal del roadmap de marzo (evolución del transporte, comunicación de agentes, maduración de la gobernanza, preparación empresarial): la mayor parte del trabajo de los últimos cinco meses ya aterrizó en la especificación 2026-07-28, y el nuevo roadmap concentra lo que viene en cinco áreas prioritarias:

1. Primitivas de mensajería agéntica: las cargas de trabajo modernas ya no encajan en el patrón petición-respuesta. El roadmap quiere mover Tasks (operaciones asíncronas de larga duración) al cuerpo de la especificación, más eventos iniciados por el servidor (webhooks y canales, para que los clientes no queden sondeando resultados), subscriptions/listen y notificaciones de progreso.
2. Unificación y refuerzo del transporte HTTP nativo: desde 2026-07-28, un servidor MCP remoto es “igual que cualquier carga HTTP” — aplican tus balanceadores, serverless con escala a cero y health checks. El siguiente paso es unificar los servidores locales sobre Streamable HTTP sobre stdio.
3. Identidad de agentes y seguridad empresarial: la autorización MCP hoy asume a una persona aprobando en el navegador, pero cada vez más llamadores son cargas en la nube sin humano presente. El roadmap apunta a DPoP (RFC 9449 Proof of Possession), Workload Identity Federation, intercambio estándar de tokens, con participación continua en los grupos de trabajo IETF OAuth y WIMSE.
4. Primitivas mejoradas: las respuestas de tools/call deberían llevar un contrato claro en vez de múltiples formas; y para que el modelo no pague por un catálogo de cien herramientas antes de que el usuario haga una sola pregunta, un esfuerzo de descubrimiento progresivo deja que el servidor ofrezca una entrada pequeña y revele más a medida que la conversación se enfoca.
5. Mejor experiencia de desarrollo en los SDK: ergonomía y conformidad en todos los SDK oficiales.

Un efecto práctico: los SEP que caen dentro de estas áreas reciben revisión acelerada. Si estás considerando una propuesta, este es el mapa para posicionarte.

Qué llegó ya con la especificación 2026-07-28: cuatro cambios grandes

El roadmap dice que “la mayor parte de los cambios llegó con la release 2026-07-28”. ¿Qué exactamente, para un desarrollador en el día a día?

1. El protocolo se volvió stateless. Con SEP-2575 (Stateless MCP) y SEP-2567 (Sessionless MCP), la sesión a nivel de protocolo y el handshake de inicialización desaparecieron. Un servidor MCP remoto es ahora un servicio HTTP más: balancea sin sticky sessions, escala a cero si quieres. Si tu servidor necesita estado entre llamadas, crea un handle explícito desde una herramienta y haz que el modelo lo pase como argumento — más transparente que sesiones ocultas en el transporte.

2. MRTR reemplazó las peticiones iniciadas por el servidor. En la especificación vieja, los servidores podían llamar de vuelta al cliente (por ejemplo, para confirmar un parámetro) — incómodo en despliegues stateless y detrás de firewalls corporativos. El patrón Multi Round-Trip Requests (SEP-2322) funciona así: el servidor devuelve resultType: "input_required" junto con las peticiones que necesita responder, y el cliente reintenta la llamada original con las respuestas adjuntas en inputResponses. Elicitation, sampling y roots se movieron a este modelo.

3. Descubrimiento y caché. El cliente puede llamar a server/discover para conocer versiones y capacidades soportadas antes de conectar; los resultados de listas llevan pistas de caché y orden determinista (SEP-2549), así los clientes pueden cachear catálogos de herramientas y las cachés de prompt aguas arriba se mantienen estables entre reconexiones.

4. Enrutamiento por cabeceras y refuerzo de autorización. Los nombres de método y herramienta viajan en las cabeceras HTTP Mcp-Method y Mcp-Name, así los gateways pueden enrutar y autorizar solo con cabeceras; la autorización ganó validación de issuer, credenciales de cliente ligadas al issuer y Client ID Metadata Documents (CIMD), con Enterprise-Managed Authorization convertida en extensión estable. AWS ya aterrizó Tasks en Bedrock AgentCore y el Agents SDK de Cloudflare soporta la especificación desde el primer día — esto es infraestructura de producción, no un experimento.

Por qué Hermes ya está en el nuevo tren

“Ya a bordo” no es copy de marketing — se puede verificar en el código. Hermes trae mcp 2.0.0, cuyas notas de release dicen que implementa la revisión 2026-07-28. La nueva especificación no es algo que Hermes esté persiguiendo; es contra lo que ya corren sus ejecuciones diarias. Característica por característica, en tools/mcp_tool.py:

• MRTR: el código maneja explícitamente resultType: "input_required", reconociendo servidores modernos con el nuevo patrón
• server/discover: en modo stateless, Hermes sondea server/discover primero, con reintento legacy para servidores de SDK viejos — ambas generaciones conectan
• Elicitation: un handler de elicitation/create enruta las solicitudes en modo formulario por el flujo de aprobación existente de Hermes (aprueba desde Feishu/Telegram/Slack)
• Transportes: stdio, HTTP/StreamableHTTP y SSE, todos cubiertos
• OAuth: gestión completa de cliente OAuth, emparejada con la skill de remote gateway
• Dirección inversa: hermes mcp serve convierte a Hermes en un servidor MCP, así cualquier cliente MCP — Claude Code, Cursor, Codex — puede conectarse a conversaciones, enviar mensajes y aprobar solicitudes

Suma el recarga en caliente /reload-mcp, un watchdog para stdio y chequeos de seguridad MCP, y la historia MCP de Hermes es una implementación completa de la nueva especificación, no un “soportamos el protocolo” de mínimos.

Configurar MCP en Hermes

Si aún no has conectado un servidor MCP, añade un bloque mcp_servers a ~/.hermes/config.yaml — funcionan tanto stdio como remoto:

mcp_servers:
  filesystem:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/data"]
  my-remote-server:
    url: "https://mcp.example.com/mcp"
    headers:
      Authorization: "Bearer your-token"

• command + args: servidor stdio local (lanzado como subproceso, con watchdog para reiniciarlo)
• url: servidor remoto Streamable HTTP / SSE, con cabeceras personalizadas
• Tras editar, ejecuta /reload-mcp para recargar en caliente o reinicia Hermes; hermes mcp serve expone a Hermes en la dirección inversa

Para la referencia completa de campos (selección de transporte, OAuth, timeouts), mira la referencia de configuración MCP; para los trucos cotidianos y variables de contexto, nuestra guía de config MCP y variables de contexto es un buen punto de partida.

Qué significan los siguientes pasos del roadmap para los usuarios de Hermes

Varias direcciones del roadmap se mapean directo a cómo se usa Hermes:

• Tasks entrando a la especificación + webhooks: las tareas MCP se vuelven un primitivo estándar. La maquinaria de cron y tareas en segundo plano de Hermes es madura — un carril bidireccional natural cuando aterricen las Tasks MCP, dejando que otros agentes invoquen tus trabajos programados.
• DPoP e identidad de agentes: los agentes en la nube consiguen autorización MCP sin humano en el circuito. Un Hermes 24/7 en un VPS es exactamente esa forma — cuando madure la identidad de “agente actuando por un usuario”, los agentes de larga vida como Hermes serán los primeros beneficiados.
• Descubrimiento progresivo de herramientas: no más pagar por un catálogo gigante por adelantado. Hermes ya hace recorte de toolsets y optimización de esquemas; esta dirección hace mejores los servidores con superficies de herramientas grandes.

Resumen

El nuevo roadmap de MCP trae mucho, pero se reduce a tres frases: el protocolo ahora es stateless y HTTP nativo; el próximo semestre se enfoca en primitivas de mensajería agéntica, identidad de agentes y experiencia de desarrollo; los SEP se priorizan contra estas cinco áreas. Para los usuarios de Hermes, la parte reconfortante es que la nueva especificación no está en “tiempo futuro” — tu Hermes ya corre con ella a diario. Para los detalles a nivel de protocolo, lee el post oficial del roadmap y el anuncio de la especificación 2026-07-28; para ver qué más puede hacer Hermes con MCP, este recorrido SEO-MCP es un buen lugar para empezar.