The MCP roadmap was updated on August 22nd, and I read it the way I read every roadmap that comes out of a fast-moving protocol: looking for the moment where the new thing stops being new and starts being infrastructure. This one has that moment all over it. There are five priority areas — agentic messaging primitives, HTTP-native transport unification and hardening, agent identity and enterprise-ready security, improved primitives, and improved SDK developer experience — and four of the five are problems the API space has been chewing on for a decade or more, arriving now at MCP’s door with new names on them. That is not a criticism. It is the most encouraging document MCP has published, because a protocol only earns these problems once people are using it for work that matters.
The clearest signal is the transport area. The stated goal is one transport model with standard HTTP practice on top of it, and the specific deliverable is HTTP over stdio — Streamable HTTP as the single binding, spoken over stdin and stdout for local servers. The reasoning given is that every HTTP-native feature currently needs a second stdio-specific design or it does not work locally, so the SDKs carry two pipelines and protocol metadata gets duplicated across HTTP headers and message fields that servers then have to cross-validate. That is the protocol conceding, on the record, that it is an HTTP protocol and that pretending otherwise is a tax. It is the same thing I meant when I said MCP is last-mile plumbing — the plumbing runs through the same pipes as everything else you have ever shipped. The caching item is that admission from another angle. The last revision added ttlMs and cacheScope to list results and resource reads, and now the roadmap wants ETags so tool call results can be versioned. ETags. We are about three sentences from conditional requests and Cache-Control, which is to say we are back inside HTTP, where cache invalidation has been simultaneously solved and unsolved since 1997.
I can report from the other side of that decision that it is the right one and that it costs you something. Both of my MCP servers run as ordinary HTTP workloads — API Gateway in front of Lambda, behind CloudFront — and the moment you rely on HTTP specifics to carry protocol information, you inherit the opinions of every intermediary between you and the client. My favorite scar: API Gateway’s REST flavor silently renames the WWW-Authenticate header coming out of a Lambda proxy integration to x-amzn-remapped-www-authenticate, with no toggle to turn it off. So my scope step-up challenge, which is a perfectly spec-compliant 403 with a scope hint on it, reaches clients with its name changed out from under it. Clients fall back to probing the well-known URIs and everything still works, but the per-call hint is gone, and there is no fixing it inside that stack. That is what “HTTP-native” actually means in production. It is worth it, and it is not free.
The identity area is the one I care most about, and it is the one where the roadmap is doing exactly the right thing by refusing to invent. The deliverables are DPoP, Workload Identity Federation, the Identity Assertion JWT Authorization Grant behind Enterprise-Managed Authorization, and RFC 8693 token exchange — coordinated with the IETF OAuth working group and WIMSE. Every one of those already exists. The framing is precise, too: MCP authorization assumes a person with a browser at consent time, and increasingly the caller is an agent, a cloud workload with its own identity acting for a user who is not present, or spawning sub-agents that should get narrower authority than their parent. That is the gap, stated better than I have stated it, and the fact that the answer is adoption rather than invention is the whole thing. I built both of my servers as OAuth 2.1 resource servers with RFC 9728 protected resource metadata and audience-bound tokens, running my own authorization server, because that was what the spec asked for and because the alternative — the pasted API key in an environment variable — is the pattern the roadmap is explicitly trying to retire. If you have been wondering whether the careful version of this was worth building, the roadmap just told you where the ecosystem is headed. It is headed at scoping what an agent is allowed to reach, enforced by the token rather than by the model’s good behavior.
Then there is progressive discovery, which is the item that hits closest to home. The goal is that clients learn a server’s tools and resources as they need them instead of ingesting the whole catalog up front. I run two MCP servers, and between them they expose one hundred and twenty-one tools — seventy-six on APIs.io and forty-five on API Evangelist. That number is a problem, and I knew it was a problem somewhere around tool thirty. An agent handed a hundred and twenty-one tool definitions is an agent handed a two-hundred-operation OpenAPI: technically complete, practically unusable, and expensive in context before a single call is made. My workaround was prompts. I have fifty-seven of them, twenty-eight on APIs.io and twenty-nine on API Evangelist, and they exist because a prompt is a front door — the agent arrives through “find me an API for this job” instead of reading seventy-six tool names and guessing. That works. It is also a convention I invented locally because the protocol did not have an answer, which is precisely the condition progressive discovery is meant to end. The same section wants to fix tools/call returning both content and structuredContent at the same time, which has produced diverging implementations — and that one is not a protocol problem at all, it is the same API design struggle every API has when it ships two ways to say the same thing and lets the client sort it out.
The messaging area is event-driven architecture arriving on schedule. Server-initiated events, channels and subscriptions, push delivery including webhooks, so a server can tell a client work has finished without the client paying for polling. The API world has been doing this for years and has AsyncAPI to describe it; I have 5,425 event channels catalogued across my network from providers who worked this out a long time ago. What is striking is that the roadmap names its own risk out loud — that Tasks, subscriptions/listen, and progress notifications become three different answers to “the server isn’t done yet” that do not share a lifecycle, a cancellation model, or an error surface. That is exactly what happens when asynchrony is added to a synchronous protocol after the fact instead of designed in, and calling it out early is more self-awareness than most specifications manage.
The SDK area is APIOps under a different name. The plan is to generate a Tier 1 SDK and its quickstart examples from the specification, validate both against a human-reviewed conformance test suite, and publish findings on which layers should be deterministic codegen versus model-assisted. That is the argument OpenAPI has been making for a decade: the contract is the source of truth and the artifacts are derived from it, so they get regenerated and revalidated with each release rather than repaired after it. The best line in the whole document is the closer on that section — treat spec clarity issues surfaced by generation failures as documentation bugs. Generation as a governance check on the specification itself. I have watched a lot of API teams take years to arrive at that idea, and some never do.
So what is not on it? Discovery across servers. The registry exists and works, and it graduated out of the roadmap, but a registry is a list of servers, not a map of capabilities, and nothing in the five priority areas addresses how an agent finds the right server among thousands. Progressive discovery is discovery within one server, which is a real and necessary thing and also not the same problem. I have 4,249 MCP server entries catalogued across my network at this point, and the question I get asked is never “how do I page through this server’s tools” — it is “which of these servers should I be talking to at all.” That is MCP discovery and governance, it is the reason describing a server in machine-readable form matters so much, and it stays outside the protocol’s scope for another cycle. Fair enough — a protocol is not obligated to solve discovery, and the API space did not solve it inside OpenAPI either. But somebody has to, and the sprawl is not slowing down.
The correlation I keep landing on is that this roadmap is a convergence document. Transport is HTTP. Identity is OAuth and IETF token exchange. Async is event-driven architecture. Tool sprawl is API design. Generated SDKs are APIOps. Discovery is discovery. MCP spent its first two years being treated as a new category, and this document is the sound of it becoming an API — with an HTTP binding, an authorization model borrowed from people who have been doing authorization for twenty years, a caching story, a conformance suite, and a set of design problems that every large API surface eventually gets. Which means the sixteen years of accumulated discipline about how you version, describe, secure, govern, and find APIs is not adjacent to the agentic conversation. It is the agentic conversation, and the roadmap just made that considerably harder to argue with.
