What jumped out at me isn’t the roadmap itself so much as the shape of it: MCP is no longer talking like a clean tool protocol with a few adjacent ambitions. It’s now trying to become the layer where agents, auth, discovery, transport, and server behavior all meet. That’s a big bet. Maybe the right bet. But it also raises the usual question with protocol work: are we standardizing the thing people actually need, or are we slowly turning one protocol into a suitcase for every unsolved problem in the stack?
The strongest part of this update is the honesty about where the rough edges are. The authors don’t pretend that “tool calling works” means the job is done. They point straight at result handling, progressive discovery, mid-flight steering, and server-initiated events. That feels grounded. Anyone building with Claude or other agents knows the pain points aren’t just “can I call a tool?” They’re “how do I keep the interaction coherent when the loop stretches out, the server has more to say later, and the model shouldn’t see 100 tools on day one?” That’s real protocol design work, not marketing.
I’m especially interested in the push around HTTP-native transport unification. The claim is basically that a remote MCP server can now look like any other HTTP service, and they want to extend that simplicity to other deployment modes too. If they can really hold that line, it’s the sort of boring infrastructure win that developers quietly love. But I do wonder how far “one transport” can go before it starts fighting local ergonomics. Local stdio and remote HTTP are not identical animals. Unification sounds nice until the common abstraction starts hiding the things you actually need to tune.
The security section is where the roadmap gets more serious. I think the move toward agent identity is overdue. Browser-based approval works fine for a human in the loop, but it gets awkward fast once the caller is a cloud workload, a delegated sub-agent, or some other non-human actor with narrower authority. The roadmap’s preference for standards-based identity instead of pasted API keys and long-lived tokens is the right instinct. Still, this is also the part where roadmaps can get aspirational very quickly. DPoP, workload identity federation, token exchange, OAuth bodies, WIMSE — all of that sounds directionally correct, but the hard part is getting a path that normal developers can actually use without becoming OAuth hobbyists.
The bit about improved primitives is the one I’d keep an eye on if I were building MCP servers today. Tool result handling sounds unglamorous until you’ve watched a model get different output shapes from different clients and nobody can predict what’s going to be surfaced. Standardizing that contract is the kind of cleanup that pays off immediately. The “progressive discovery” idea also makes sense. A hundred tools on first contact is just too much surface area. The model pays for all of it, and the selection quality drops. That part is refreshingly pragmatic.
What I’m less certain about is the breadth of the roadmap. There’s a lot here: messaging primitives, transport, identity, primitives, SDKs, governance, proposal prioritization. It reads like a protocol that is healthy enough to have multiple sustained problem tracks, which is good, but also like a project that risks spreading its attention thin. If I were evaluating MCP as a developer, I’d want to know not just that these are the priorities, but which ones are expected to matter in the next SDK I touch versus sometime later when the standards dust settles.
The most encouraging signal is probably the governance tone. The maintainer ladder, working groups triaging SEPs, feature lifecycle, deprecation policy — that’s the unsexy machinery that tells you a protocol project is trying to behave like infrastructure rather than a demo. And that matters. A lot of “agent protocols” sound exciting right up until you need versioning discipline and someone has to say no.
If I were building against this stack, I’d watch the agent identity work and the result-contract cleanup first. Those seem like the places where MCP either becomes easier to trust or stays annoyingly fuzzy. The rest is important, but those two will probably decide whether this feels like a protocol you can base real products on.
Reference: The New MCP Roadmap
