MCP’s new roadmap names the right gaps, but the fixes are still proposals

The Model Context Protocol’s core maintainers published a new MCP roadmap on August 22. The roadmap itself prioritizes agent identity, long-running work, transport unification, progressive discovery and better SDK conformance over the next specification release and beyond.

Those features did not ship with the announcement. The page describes a six-to-twelve-month horizon and calls the plan “current thinking rather than firm commitments.” Priorities may shift, be deferred or arrive in a different form.

The distinction matters for teams choosing an architecture today. MCP has moved beyond connecting a local assistant to a few tools. Agents now run as cloud workloads, delegate work and remain active after the person who started them has left. The protocol’s current authorization and discovery patterns do not cover all of that cleanly.

Agent identity has moved beyond browser approval

MCP authorization currently assumes that a person can approve access in a browser. That works for an interactive client. It fits less well when a cloud-hosted agent acts for an absent user or delegates limited authority to another agent.

The roadmap proposes a standardized path built around Demonstrating Proof of Possession (DPoP), Workload Identity Federation (SEP-1933), the Identity Assertion JWT Authorization Grant used by Enterprise-Managed Authorization, and RFC 8693 token exchange. DPoP is an existing IETF standard; MCP’s work is to finalize its use in the protocol and drive adoption. The maintainers are coordinating with the IETF OAuth and WIMSE groups, so part of the timeline sits outside MCP itself.

The Agent Identity Working Group assigned to this work is marked as forming during the roadmap period.

Nothing in the roadmap deprecates API keys, and the roadmap gives no individual deliverable a date. Teams operating machine-to-machine MCP connections still need to decide how identities are issued, how delegated access is narrowed and how credentials are revoked.

Long-running work creates a related problem. An agent loop may stream results, wait on outside events or need steering while it is running. The maintainers want Tasks, subscriptions/listen and progress notifications to work as a coherent set. Planned server-initiated events would use webhooks or channels so clients are not forced to poll continuously. Tasks currently remain an extension; the project says eventual inclusion in the core protocol sits beyond the named deliverables for this roadmap period.

Large catalogs need a smaller front door

A server exposing a hundred tools makes the model pay for that entire surface before the user asks for anything. Selection also becomes less reliable as the list grows.

The proposed answer is progressive discovery across tools, resources and other primitives. A server would initially expose a small entry point, then reveal more of its catalog as the conversation narrows. That could reduce context usage and make selection easier, although the roadmap does not yet define the final contract builders can implement against. The Core Primitives Working Group responsible for this work and tool-result shape is still forming.

One developer in the Hacker News discussion described a working substitute for progressive discovery. Their OpenAPI specification contains more than 400 endpoints, grouped by tags. The MCP layer returns no more than ten matching endpoints at a time and lets the model paginate for more. It is one team’s workaround, not evidence that MCP will adopt the same design.

The roadmap also targets an existing ambiguity in tools/call. A response can contain both content and structuredContent, leaving a server author unsure which representation a client will show the model. The proposed redesign would give tool results a clearer contract. SDK work follows the same theme: the maintainers plan to generate a candidate Tier 1 SDK and quickstarts from the specification, then validate them against a conformance suite.

One transport model, with caching underneath

Transport work is moving toward one HTTP-native model. For local servers, the roadmap specifies HTTP/2 over stdin and stdout, gaining multiplexing while retaining the security and lifecycle guarantees of a subprocess. The blog post’s phrasing was ambiguous enough that a reader in the HN thread asked whether stdio was being deprecated. The answer is no. The proposal retains the subprocess transport while trying to remove its separate protocol behavior.

Caching connects transport work to progressive discovery. SEP-2549 added ttlMs and cacheScope to list results and resource reads. The roadmap proposes extending that model with ETags, particularly to version tool-call results, and says progressive discovery should be designed to work with the caching layer.

July’s release already removed server-side state

The July 28 specification release removed protocol-level sessions and the initialization handshake through SEP-2575 and SEP-2567, allowing servers to scale horizontally without retaining that state. Clients can call server/discover to inspect versions and capabilities before initializing. SEP-2549 supplied the caching foundation described above.

SEP-2322 also replaced server-initiated requests with a multi-round-trip request pattern designed for stateless servers. SEP-2663 moved Tasks into an official extension.

The shipped authorization work is broader than those transport changes. July added issuer validation, issuer-bound client credentials and Client ID Metadata Documents as the preferred registration path. Enterprise-Managed Authorization is now a stable extension. The roadmap’s future identity work builds on that foundation rather than starting from zero.

MCP now has a clearer account of the infrastructure it wants to become. Builders still have to separate that destination from the protocol available today. Stateless scaling, early capability discovery and several authorization foundations have shipped. Standardized workload identity, progressive discovery and the fuller long-running-work model remain proposals, and some of their most consequential deliverables depend on Working Groups that are still being assembled. Their real test will be interoperable implementations across clients and servers.