MCP roadmap 2026: five priority areas to plan for

MCP roadmap 2026: five priority areas and review order

The MCP roadmap sets where maintainer attention goes next. It names five priority areas and attaches no date, release name or deadline to any of them. Read it as a direction for the protocol, not as a list of features that are about to ship.

The table lists each area and the problem it targets. A Specification Enhancement Proposal (SEP) is the written proposal form for changing the MCP specification, and the areas decide which SEPs are read first.

The five priority areas and the problem each targets

Priority area	Problem it targets
Agentic messaging primitives	Long-running loops, streamed results, steering work mid-flight
HTTP-native transport unification	Extending the HTTP model from remote servers to other deployment modes
Agent identity and enterprise-ready security	Authorization assumes a person approving in a browser
Improved primitives	Tool results that can come in more than one form, large tool catalogs
SDK developer experience	Ergonomics, spec conformance, documentation accuracy

Five priority areas and who owns them

Each area names its Core Maintainers, the people assigned to own it, and has one or more Working Groups behind it. The Core Maintainers developed the roadmap together with the community of maintainers and Working Groups. Several areas pick up items the March roadmap listed as on the horizon: server-initiated events, result type improvements and agent identity.

How SEP review order changes

A SEP that falls inside a priority area gets expedited review and has the best chance of acceptance. A SEP outside the areas is not rejected automatically, but it waits, because maintainer review time goes to the priority areas first.

For an author the steps are short. Identify the priority area the proposal belongs to, raise it with the relevant Working Group (the body that triages SEPs in its own area), and shape it with its members.

What the 2026-07-28 MCP specification release shipped

The March roadmap had four priority areas: transport evolution and scalability, agent communication, governance maturation and enterprise readiness. Most of the work on those four areas landed in the 2026-07-28 specification release. The post says the changes ranged from minor modifications to major protocol overhauls.

On the protocol side, protocol-level sessions and the initialization handshake are gone, so a server can scale horizontally without holding state (SEP-2575, SEP-2567). Clients can call server/discover first to learn which versions and capabilities a server supports, and list results are cacheable (SEP-2549).

On the agent side, Tasks were reworked after early adopter feedback and moved into an official extension (SEP-2663). A new pattern, Multi Round-Trip Requests (SEP-2322), replaced server-initiated requests so that elicitation and similar flows work on stateless servers.

The post lists further progress alongside the release. Working Groups now triage SEPs in their own area, and the specification has a feature lifecycle and deprecation policy.

Authorization gained issuer validation and issuer-bound client credentials. Client ID Metadata Documents became the preferred registration path for clients, and Enterprise-Managed Authorization is available as a stable extension. For a server that has to move to the new release, the earlier article MCP Specification 2026-07-28: Sessions Removed walks through the changes.

Agentic messaging and the Tasks extension (SEP-2663)

Agent work no longer fits a single request and a single response. The roadmap's answer is to make the messaging primitives work well together, with the Tasks extension as the piece to mature. Loops run longer, servers push streamed results, and work already in flight needs steering.

MCP already has Tasks, a way to run long work and return the result later, plus subscriptions/listen and progress notifications. The roadmap wants these to compose, not just to exist side by side.

The planned work has three parts. The first is server-initiated events, meaning webhooks and channels, so clients are not left polling for results. The second is a composition review across the Agents, Transports, and Triggers & Events Working Groups.

The third part is maturing the Tasks extension so it can move into the specification. The post does not say which release carries Tasks into the specification, so plan around the extension as it stands.

Streamable HTTP over stdio: one transport, local and remote

Since the 2026-07-28 release, a remote MCP server is an ordinary HTTP workload. The roadmap wants to stretch that model to other deployment modes, local servers included, so one transport can serve them. A team can host a remote server on the infrastructure it already runs its APIs on.

Streamable HTTP is the HTTP-based transport remote servers use, and stdio (standard input and output) is how a local server talks to its client today. The aim is for local servers to speak Streamable HTTP over stdio.

The post gives one reason: unifying on one transport lets the project simplify MCP server and client development further. For a concrete case, see the earlier article X MCP Server: Give Claude and Grok the X API, which covers the official X implementation. No date or release is attached to the transport work.

Tool results and progressive discovery for large catalogs

Tool calling is the part of MCP most developers touch first, and it has held up well. The weak spot is the result, and the roadmap aims for one clear contract for it. A tools/call response can carry the same output in more than one form, and a server developer cannot know which form a given client puts in front of the model.

Catalog size is the second problem. A server with a hundred tools makes the model pay for that whole surface before the user asks a single question, and tool selection tends to get worse as the list grows.

Progressive discovery is the response: a server offers a small entry point and reveals more of its catalog as the conversation narrows. The post says this effort is starting, and it gives no release for it.

Agent identity and MCP authorization beyond browser approval

For a server already in use, agent identity is the sensible area to look at first. MCP authorization today assumes a person approving access in a browser, and the roadmap sets out to standardize how a server recognizes and trusts an agent. The goal is to build this on existing standards instead of pasted API keys and long-lived tokens.

Why a browser prompt no longer covers every caller

A browser approval works well for interactive clients, but more and more callers are agents. Some run as cloud workloads with their own identity.

An agent may act on behalf of a user who is not present, or delegate narrower authority to sub-agents. When the user is not present, a browser prompt has nobody to answer it.

DPoP, token exchange and delegation

The work has two parts: finalizing Demonstrating Proof of Possession (DPoP) and defining a path for delegation. For DPoP, the roadmap goes past finalizing it and also covers driving its adoption. The delegation path is meant to be opinionated, built on Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange.

The post names these standards without explaining how each works. The project will also keep growing its engagement with the OAuth standards bodies, including the IETF OAuth and WIMSE working groups, to help the underlying standards evolve with the building blocks agent identity needs.

MCP SDK ergonomics and what to plan for now

SDKs are how developers meet MCP, so the roadmap includes work on their ergonomics and on conformance with the specification. A sensible first area to plan for is authorization, since it covers who calls a server that is already running. The post commits to no dates, so nothing here is a migration deadline.

The SDK work matters more than the label suggests. Many developers now build MCP clients and servers by pointing an agent at the libraries. In that setup, clear APIs and accurate docs decide whether the generated code works with minimal friction.

Here is a short list for a team running an MCP server or client. None of the items carries a deadline:

• Find which of the five areas your server or your proposed SEP falls into.
• Treat pasted API keys and long-lived tokens as the pattern the standardized path is meant to replace, and watch the authorization work.
• Follow the transport and discovery work, whose stated aims are simpler server and client development and less tool surface for the model to pay for up front.

To take part, you can join a Working Group or Interest Group, or propose or comment on a SEP after reading the SEP guidelines. SEP-2133 also lets any Working Group or Interest Group try an idea in an experimental extension repository before writing a formal SEP.