The New MCP Roadmap

What it claims

The roadmap names five priority areas, each owned by named Core Maintainers and one or more Working Groups. Specification Enhancement Proposals (SEPs) inside these areas get expedited review. SEPs outside them are not automatically rejected, but maintainer review time goes to the five areas first. For anyone planning to propose protocol changes, that is the practical consequence.

Three items listed as "on the horizon" in the March roadmap have now become priorities in their own right:

• server-initiated events
• result type improvements
• agent identity

How it works

The page states the concrete problem behind each area:

• Messaging. Server-initiated events would be webhooks and channels, so clients stop polling for results. A composition review across the Agents, Transports, and Triggers & Events WGs will check that Tasks, subscriptions/listen and progress notifications work together.
• Transport. After 2026-07-28, a remote MCP server is an ordinary HTTP workload. The goal is to extend that to local servers by running Streamable HTTP over stdio, leaving a single transport.
• Identity. Today's authorization assumes a person approving access in a browser. The target cases are agents running as cloud workloads with their own identity, agents acting for an absent user, and agents delegating narrower authority to sub-agents. The stated aim is to replace pasted API keys and long-lived tokens.
• Tool results. A tools/call response can carry the same output in several forms. A server cannot know which form a client will show the model. The plan is to standardize on one contract.
• Tool scale. A server with a hundred tools makes the model pay for the whole surface before the user asks anything, and tool selection degrades as the list grows. Progressive discovery would let a server expose a small entry point and reveal more of its catalog as the conversation narrows.

How to use it

Details from the 2026-07-28 release that matter for implementers:

• Session removal. Protocol-level sessions and the initialization handshake were removed by SEP-2575 and SEP-2567.
• Caching. Cacheable list results come from SEP-2549.
• Server-initiated requests. These were replaced by Multi Round-Trip Requests (SEP-2322). Elicitation-style flows must use the new pattern to work on stateless servers.
• Tasks. Tasks now live in an official extension (SEP-2663), not the core spec.
• Client registration. CIMD is the preferred client registration path.
• Enterprise-Managed Authorization. This extension, based on the ID-JAG grant, is now stable.
• Deprecations. The 2026-07-28 deprecations were the first to follow the new feature lifecycle and deprecation policy. Check them against your SDK version.
• Server Card WG. This group is still defining .well-known metadata so a server can be discovered without connecting to it. Not finalized.

Contribution routes:

1. Raise a proposal with the relevant WG first. Maintainers are reachable on Discord.
2. Under SEP-2133, a WG or Interest Group can experiment in an experimental-ext- repository before writing a formal SEP.

Governance now includes a Contributor Ladder, and WGs triage SEPs in their own area.

Limits

This is a direction-setting post, not a specification. It gives no dates for the next spec release and no SEP numbers for the new work, except the Tasks maturation (SEP-2663). In particular, DPoP, the agent-identity path, the unified tool-result contract and progressive discovery are all unshipped and undesigned in this text. Do not build against them yet.

The page does not list which items were deprecated in 2026-07-28. It also does not say whether server-initiated requests remain usable during a transition period.