MCP Just Announced a New Roadmap — and Hermes Is Already on the New Spec

Last month you spent an afternoon wiring a few internal tools into MCP (Model Context Protocol, the de facto standard for connecting AI applications to external systems and data). Servers configured one by one, permissions set, everything working. Then this week you see the news: MCP announced a new roadmap — “protocol-level sessions removed”, “server-initiated requests replaced”. Your first thought is probably: here we go again, another migration? Take a breath. This post breaks down what the official roadmap published on August 22 actually says, which changes already shipped in the 2026-07-28 specification, and why Hermes users are already on the new train.

What MCP announced: a five-priority roadmap

On August 22, MCP’s two lead maintainers — David Soria Parra and Den Delimarsky — published the official blog post The New MCP Roadmap, with a matching update on the roadmap page. It’s the formal update to the March roadmap (transport evolution, agent communication, governance maturation, enterprise readiness): most of the past five months of work already landed in the 2026-07-28 specification, and the new roadmap narrows what’s next into five priority areas:

  1. Agentic messaging primitives: modern agent workloads no longer fit the request-and-response pattern. The roadmap wants Tasks (async long-running operations) moved into the spec proper, plus server-initiated events (webhooks and channels, so clients aren’t left polling for results), subscriptions/listen, and progress notifications.
  2. HTTP-native transport unification and hardening: since 2026-07-28, a remote MCP server is “no different from any other HTTP workload” — your familiar load balancers, scale-to-zero serverless, and readiness probes all apply. Next step is unifying local servers onto Streamable HTTP over stdio.
  3. Agent identity and enterprise-ready security: MCP authorization today assumes a person approving in a browser, but more and more callers are cloud workloads acting without a human present. The roadmap targets DPoP (RFC 9449 Proof of Possession), Workload Identity Federation, standard token exchange, with continued engagement in the IETF OAuth and WIMSE working groups.
  4. Improved primitives: tools/call responses should carry one clear contract instead of multiple forms; and to stop the model paying for a hundred-tool catalog before the user asks a single question, a progressive discovery effort lets a server offer a small entry point and reveal more as the conversation narrows.
  5. Improved SDK developer experience: ergonomics and conformance across every official SDK.

One practical side effect: SEPs falling inside these priority areas get expedited review. If you’re considering a proposal, this is the map to position against.

What already shipped in the 2026-07-28 spec: four big changes

The roadmap says “the bulk of the changes landed in the 2026-07-28 specification release.” What exactly, for a working developer?

1. The protocol went stateless. With SEP-2575 (Stateless MCP) and SEP-2567 (Sessionless MCP), the protocol-level session and initialization handshake are gone. A remote MCP server is now just an HTTP service: load-balance without sticky sessions, scale to zero if you like. If your server needs state across calls, mint an explicit handle from a tool and have the model pass it back as an argument — more transparent than hidden transport-level sessions.

2. MRTR replaced server-initiated requests. In the old spec, servers could call back into the client (e.g. to confirm a parameter) — awkward on stateless deployments and behind corporate firewalls. The Multi Round-Trip Requests pattern (SEP-2322) works like this: the server returns resultType: "input_required" along with the requests it needs answered, and the client retries the original call with answers attached in inputResponses. Elicitation, sampling, and roots all moved to this model.

3. Discovery and caching. A client can call server/discover to learn supported versions and capabilities before connecting; list results carry cache hints and deterministic ordering (SEP-2549), so clients can cache tool catalogs and upstream prompt caches stay stable across reconnects.

4. Header-based routing and authorization hardening. Method and tool names travel in the Mcp-Method and Mcp-Name HTTP headers, so gateways can route and authorize on headers alone; authorization got issuer validation, issuer-bound client credentials, and Client ID Metadata Documents (CIMD), with Enterprise-Managed Authorization becoming a stable extension. AWS already landed Tasks in Bedrock AgentCore, and Cloudflare’s Agents SDK supports the spec from day one — this is production infrastructure, not an experiment.

Why Hermes is already on the new train

“Already on board” isn’t marketing copy — you can verify it in the code. Hermes ships with mcp 2.0.0, whose release notes state it implements the 2026-07-28 revision. The new spec isn’t something Hermes is chasing; it’s what daily runs execute against. Feature by feature, in tools/mcp_tool.py:

  • MRTR: the code explicitly handles resultType: "input_required", recognizing modern servers using the new pattern
  • server/discover: in stateless mode Hermes probes server/discover first, with a legacy retry for older-SDK servers — both generations connect
  • Elicitation: an elicitation/create handler routes form-mode requests through Hermes’ existing approval flow (approve right from Feishu/Telegram/Slack)
  • Transports: stdio, HTTP/StreamableHTTP, and SSE all covered
  • OAuth: full OAuth client management, paired with the remote gateway skill
  • Reverse direction: hermes mcp serve turns Hermes into an MCP server itself, so any MCP client — Claude Code, Cursor, Codex — can connect to conversations, send messages, and approve requests

Add /reload-mcp hot reload, a stdio watchdog, and MCP security checks, and Hermes’ MCP story is a full implementation of the new spec, not a “we support the protocol” minimum.

Configuring MCP in Hermes

If you haven’t wired an MCP server yet, add an mcp_servers block to ~/.hermes/config.yaml — both stdio and remote work:

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: local stdio server (spawned as a subprocess, with a watchdog to restart it)
  • url: remote Streamable HTTP / SSE server, custom headers supported
  • After editing, run /reload-mcp to hot-reload, or restart Hermes; hermes mcp serve exposes Hermes in the reverse direction

For the full field reference (transport selection, OAuth, timeouts), see the official MCP config reference; for everyday integration gotchas and context-variable tricks, our guide on MCP config and context variables is a good starting point.

What the roadmap’s next steps mean for Hermes users

Several roadmap directions map directly onto how Hermes is used:

  • Tasks entering the spec + webhooks: MCP tasks become a standard primitive. Hermes’ cron and background-task machinery is mature — a natural two-way lane once MCP Tasks land, letting other agents invoke your scheduled jobs.
  • DPoP and agent identity: cloud agents get MCP authorization without a human in the loop. A 24/7 Hermes on a VPS is exactly this shape — when “agent acting on behalf of a user” identity matures, long-lived agents like Hermes are the first beneficiaries.
  • Progressive tool discovery: no more paying for a giant catalog upfront. Hermes already does toolset trimming and schema optimization; this direction makes large tool-surface servers nicer for everyone.

Summary

The new MCP roadmap packs a lot, but it reduces to three sentences: the protocol is now stateless and HTTP-native; the next half-year focuses on agentic messaging primitives, agent identity, and developer experience; SEPs are prioritized against these five areas. For Hermes users, the comforting part is that the new spec isn’t “future tense” — your Hermes already runs on it daily. For the protocol-level details, read the official roadmap post and the 2026-07-28 spec announcement; to see what else Hermes can do with MCP, this SEO-MCP walkthrough is a solid place to start.