MCP's New Roadmap Is a Manifesto

The MCP maintainers published an updated roadmap yesterday. It's written as a planning document — five priority areas, working groups, SEP references, the standard governance language. But read past the structure and it reads differently. It's a manifesto for what the protocol wants to be when it grows up.

And what it wants to be is the HTTP of agent-to-tool communication. Not a niche protocol for IDE plugins. Not an Anthropic-owned accessory. A genuine infrastructure layer that any agent, any tool, any identity system can speak.

I've been building against MCP for months. This roadmap tells me the maintainers have been paying attention to the same rough edges I've been hitting. Let me walk through what changed and why it matters.

The stateless shift is the sleeper hit

The July 28 release already shipped the biggest architectural change: protocol-level sessions and the initialization handshake are gone. This sounds like a backend cleanup note. It's not. It's the difference between MCP being a toy protocol and a real one.

Before: every MCP server held session state. You connected, negotiated capabilities, and the server remembered who you were. That works fine for a single-user Claude Desktop session. It falls apart the moment you try to load-balance across ten server instances behind a reverse proxy. Session affinity, state synchronization, connection drains — you're back to solving problems HTTP solved twenty years ago.

After: stateless servers. A server can scale to zero, spin up behind any load balancer, and never think about which client is talking to it. Combined with the new server/discover endpoint (call it before you do anything, learn versions and capabilities in one round trip) and cacheable list results, you get something that looks and feels like a well-designed REST API — because it is one.

This matters because the single biggest barrier to MCP adoption in production has been operational complexity. If you're a platform team evaluating whether to expose your internal APIs as MCP servers, stateless vs stateful is the difference between "add it to the existing Kubernetes service" and "build a whole new stateful infrastructure." The roadmap chose the right side.

Agent identity is the hard problem they're finally tackling

The roadmap's second priority area — agent identity and enterprise-ready security — is where the protocol starts to get interesting for non-trivial deployments.

Today's MCP authorization flow assumes a human sitting at a browser approving access. That's Claude Desktop clicking "Allow" on an OAuth screen. But more and more callers aren't humans. They're cloud workloads, scheduled agents, sub-agents spawned by other agents, all acting on behalf of a user who isn't present.

The roadmap calls out the specific standards they're targeting:

• DPoP (Demonstrating Proof of Possession) — binds tokens to a specific client, so a stolen token can't be replayed from another machine
• Workload Identity Federation — lets cloud workloads (AWS IAM roles, GCP service accounts, Azure managed identities) authenticate as MCP clients without long-lived secrets
• ID-JAG grant — the delegation mechanism behind Enterprise-Managed Authorization, letting an agent carry narrower authority than its caller

This is the right stack. OAuth isn't sexy, but agent-to-tool authorization without replay protection, without workload identity, and without delegation boundaries is not production-ready security — it's a demo. The roadmap acknowledges that building on top of existing IETF standards (OAuth, WIMSE) is the only path that gets adopted by organizations that already have security teams.

The interesting absence: no mention of API key auth deprecation. I suspect that's a political choice — too many early MCP deployments use API keys, and a hard deprecation would break them. But the subtext is clear: the long-term path goes through OAuth 2.1 flows and workload federation, not pasted keys in environment variables.

Tool scale is breaking the mental model

The "Improved Primitives" section addresses a pain point I feel every time I connect to a server with more than 50 tools:

"Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows."

This is the kind of honest admission you don't get from protocols that haven't been battle-tested yet. The current MCP design assumes every tool is equally relevant all the time. That assumption breaks at scale. If you've ever watched a model scroll through 80 tool definitions trying to find the right one, you know exactly what they're talking about.

The roadmap doesn't prescribe the solution yet, which is fair — this is hard. But it signals they're thinking about:

• Result type standardization — today a tools/call response can carry the same output in multiple formats, and server devs have no way to know which format the client will surface to the model. Standardizing the contract makes server development predictable.
• Selection mechanisms — unnamed but implied: something smarter than dumping the full tool list.

The transport unification play

The roadmap wants to unify on one transport: Streamable HTTP. Remote servers already speak it. The push is to make local servers speak Streamable HTTP over stdio, so there's one transport model whether the server is running on the same machine or in a different datacenter.

This is the right call. Having multiple transport modes (stdio, SSE, Streamable HTTP) has been a source of subtle bugs — something that works over stdio breaks over HTTP because the timing assumptions differ, or the error format differs, or rate limiting behaves differently. One transport, one mental model, one code path. The complexity moves into the transport implementation, not the application logic.

  graph TD
    subgraph "Before (Today)"
      A[Local MCP Server] -- stdio --> B[MCP Client]
      C[Remote MCP Server] -- Streamable HTTP --> B
      D[Another Remote] -- SSE --> B
    end
    subgraph "After (Roadmap)"
      E[Local Server] -- "Streamable HTTP over stdio" --> F[MCP Client]
      G[Remote Server] -- Streamable HTTP --> F
    end
  

What the roadmap doesn't say

A few things I was hoping to see that didn't make the cut:

• Standardized tool registries/discovery. The Server Card Working Group is working on .well-known metadata, but there's no mention of a registry where you can find "all MCP servers for databases" or "all MCP servers for email." The ecosystem needs one before MCP adoption can go wider than early adopters.
• Version pinning. If I build a workflow against MCP server v1.2, and the server upgrades to v2.0 with breaking changes, what happens? The server/discover endpoint helps but doesn't solve backward compatibility contracts.
• Pricing/rate limiting primitives. If MCP servers become a commercial ecosystem (they will), servers need a standard way to communicate cost constraints — "this tool costs $0.01 per call" or "you have 100 requests left today."

These are gaps the community will fill, but they're worth noting because they determine whether MCP stays a developer tool protocol or becomes a genuine marketplace protocol.

Bottom line

The MCP roadmap is the most honest protocol planning document I've read this year. It admits where the current design breaks (statelessness, tool scale, agent identity), it names the specific standards it's building on (DPoP, WIF, OAuth 2.1), and it doesn't overpromise timelines. The unification on one transport model and the shift to stateless servers are the right architectural calls.

MCP is no longer an Anthropic experiment. It's an infrastructure bet that's growing up fast. The roadmap signals that the people building it understand what production deployment actually requires — and they're making the unsexy, correct choices. That's worth paying attention to.