The New MCP Roadmap: Progressive Discovery and Agent Auth

Official Sources#

Last updated: August 23, 2026

The Model Context Protocol maintainers published an updated roadmap on August 22, 2026, written by lead maintainers David Soria Parra and Den Delimarsky. It lays out five priority areas for upcoming specification releases: agentic messaging primitives, HTTP-native transport unification, agent identity and enterprise security, improved primitives, and SDK developer experience. Two of those land squarely on problems we feel running our own MCP-based skills platform: tool catalogs that eat context before a user has asked anything, and an authorization story written for humans clicking through browsers. Here is what changes if you build MCP servers or agent platforms, and what stays open.

Where the roadmap starts from#

The new priorities build on the 2026-07-28 specification release, which we covered in depth in our migration guide for the breaking changes. The roadmap post recaps what shipped there: protocol-level sessions and the initialization handshake are gone (SEP-2575, SEP-2567), so a server can scale horizontally without holding state. Clients can call server/discover to learn a server's supported versions and capabilities up front, and list results are now cacheable (SEP-2549). Tasks were reworked into an official extension (SEP-2663), a Multi Round-Trip Requests pattern (SEP-2322) replaced server-initiated requests so elicitation works on stateless servers, and Client ID Metadata Documents became the preferred client registration path. If you have not migrated off the session-based model yet, start with our stateless migration guide, because everything below assumes it.

Tool-list bloat meets progressive discovery#

This is the theme most server authors will feel first. In the improved primitives section, the maintainers name the economics directly:

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.

Their answer is a progressive discovery effort, still in its opening phase: "a server can offer a small entry point and reveal more of its catalog as the conversation narrows." Note the framing - the post says they are starting this effort. There is no named SEP and no mechanism in the text yet, so treat every design detail you read elsewhere as speculation until proposals land.

For anyone who has watched a flat tool list crowd out the actual task in a context window, the direction matters more than the missing details. We made this bet on our own platform: our argument for delivering skills over MCP with progressive disclosure is that an agent should pay context only for what the task needs, which is the same instinct the maintainers are now formalizing at the protocol level. The companion problem in the same section is result handling: a tools/call response can carry the same output in multiple forms today, and a server developer has no way to know which form a given client will put in front of the model. The roadmap promises one clear contract. Both changes push in the same direction as designing intent-shaped tools that compress whole workflows rather than mirroring your REST surface one endpoint at a time.

Authorization for agents that never open a browser#

The second big theme is spelled out plainly in the agent identity section:

MCP authorization today is built around a person approving access in a browser.

That assumption breaks exactly where the industry is growing: agents running as cloud workloads with their own identity, acting for a user who is not present, or delegating narrower authority to sub-agents. The stated goal is a standardized way for MCP servers to recognize and trust agent identities, "built on existing standards rather than pasted API keys and long-lived tokens." Concretely, the roadmap names four workstreams:

• Finalizing Demonstrating Proof of Possession (DPoP, RFC 9449) and driving its adoption, so a stolen bearer token is not enough.
• An opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange.
• Continued engagement with the IETF OAuth and WIMSE working groups so the underlying standards evolve with what agent identity needs.

What does this unlock in practice? Long-running autonomous agents and server-to-server calls that currently require someone to babysit an OAuth consent screen, plus principled sub-agent scoping - a planner agent handing a narrow, expiring credential to an executor instead of its full authority. Much of the groundwork already exists: Enterprise-Managed Authorization is now a stable extension, and we looked at why zero-touch OAuth matters for enterprises. If you are evaluating the interim landscape while the spec work lands, our comparison of agent auth platforms covers the build-versus-buy side.

Long-running agents get first-class primitives#

The agentic messaging area starts from the observation that modern workloads no longer fit request-and-response: loops run longer, servers push streamed results, and users want to steer work mid-flight. MCP already grew Tasks (now an extension), subscriptions/listen, and progress notifications. Ahead lies server-initiated events - webhooks and channels, so clients are not left polling - plus a composition review across the Agents, Transports, and Triggers & Events working groups to make sure the pieces work together, and maturing Tasks enough to move from extension into the core specification. If you operate headless fleets, this is the area to watch: it is the difference between an agent that polls your server every thirty seconds and one you can notify when a job finishes.

One transport, stretched further#

On transport, the roadmap declares victory on unification for remote servers: "a remote MCP server is now no different from any other HTTP workload," hostable on whatever infrastructure you already run APIs on. The remaining stretch is covering other deployment modes, including local servers speaking Streamable HTTP semantics over stdio, so client and server code stops forking per transport. A final area rounds out the roadmap: SDK developer experience, with investment in ergonomics, conformance testing, and documentation - increasingly urgent because many developers now build MCP clients and servers by pointing a coding agent at the libraries, so clear APIs and accurate docs decide whether generated code works.

What the community said#

The Hacker News thread ran pro and skeptic in parallel. On the optimistic side, one HN commenter argued that directionally every server will adopt agent identity because manually clicking through a browser is a bottleneck that serious users will tolerate less and less, and the migration work itself will increasingly be done by agents. On transport unification, another commenter welcomed the HTTP-native turn with a blunt verdict on history: "Introducing a bespoke new protocol was one of the more bone-headed things MCP did on initial release."

The strongest skepticism targeted the progressive discovery item. One HN commenter called it "kind of late to the party," saying they had already implemented lazy loading of MCP tools in a couple of harnesses and were moving to an "everything as code" model instead - a recurring counter-pattern where agents write code against APIs rather than consuming curated tool lists. Others asked how many MCP servers would realistically implement the full authorization stack of DPoP, token exchange, and workload federation, or questioned whether an MCP endpoint beats a plain REST API plus a well-documented OpenAPI file at all. Those are fair challenges, and the roadmap's own proposal prioritization section is partly an answer: SEPs inside these five areas get expedited review, while out-of-area proposals are not rejected but compete for scarcer maintainer attention.

What stays unresolved#

Being precise about what the roadmap does not settle:

• No dates. The post covers "the next specification release and beyond" without naming when that release ships or which items make it in.
• Progressive discovery has no mechanism yet. It is described as an effort being started, not a designed feature.
• Agent identity depends on outside standards - DPoP finalization and adoption, Workload Identity Federation, and IETF WIMSE work all have their own timelines.
• Adoption is voluntary and likely uneven. Nothing forces existing servers to implement any of this, which is exactly the fragmentation concern raised in the thread.

FAQ#

When does the next MCP specification revision land?#

The roadmap says the five priority areas cover "the next specification release and beyond" but gives no date. SEPs within the priority areas get expedited review, which is the closest thing to a timeline in the post.

What is progressive discovery in MCP?#

A proposed approach where a server exposes a small entry-point set of tools first and reveals more of its catalog as the conversation narrows, instead of pushing its entire tool list into the model's context on connect. The maintainers describe it as an effort they are starting, with no mechanism specified yet.

Why is browser-based MCP authorization a problem?#

Because more callers are autonomous cloud workloads, scheduled jobs, and sub-agents with nobody present to click a consent screen. The roadmap wants standardized agent identities built on OAuth-ecosystem standards like DPoP and token exchange instead of pasted API keys and long-lived tokens.

Do I need to implement DPoP in my MCP server right now?#

No. The roadmap says the work includes "finalizing" DPoP and driving its adoption, so it is forward-looking. Today's 2026-07-28 authorization spec remains what governs, and Enterprise-Managed Authorization is available now as a stable extension.

Is stdio going away?#

Not per the roadmap. The opposite: the proposal is to stretch Streamable HTTP semantics down to local stdio-based servers so there is one transport model instead of several, simplifying both sides.

Does progressive discovery replace skills platforms?#

It complements them. Skills packages solve knowledge packaging with progressive disclosure; the roadmap effort would let servers apply the same economics to tool catalogs at the protocol level. Expect both layers to matter.

Will SEPs outside the five priority areas be rejected?#

No. The roadmap says proposals outside the areas are not automatically rejected, but maintainer review time goes to priority-area proposals first, so acceptance odds are meaningfully better inside them.

How does this affect existing MCP clients?#

Nothing in the roadmap breaks clients on the 2026-07-28 spec today. Progressive discovery, new auth flows, and server-initiated events would arrive as future spec revisions or extensions, negotiated per connection as MCP extensions always are.

The through-line is that MCP is repositioning from "a protocol for IDEs connecting to tools" toward infrastructure for fleets of agents that run for hours, call each other, and never see a browser. Whether that lands as designed or fragments along the way is the open question - our money is on the teams who ship the boring parts early. If you are weighing whether to build on MCP at all versus betting on CLIs and plain APIs, read our case for CLIs over MCPs as the counterweight, and pair this roadmap with the Arcade agent authorization guide to see how the commercial layer is already solving what the protocol is only now planning to standardize.