The core maintainers of Model Context Protocol (MCP), the open standard that connects AI applications to external tools, published an updated roadmap on August 22, 2026. It lays out five priority areas for the next specification release and beyond, with long-running work that goes past a single tool call and the question of how an agent proves who it is sitting near the top.

The July overhaul that cleared the ground

The new roadmap assumes a large batch of work has just landed. The previous version, published in March 2026, named four priorities: transport evolution and scalability, agent communication, governance maturation, and enterprise readiness. Most of that shipped in the specification release dated July 28, 2026.

The single biggest change was the removal of protocol-level sessions and the initialization handshake. A server no longer has to hold state, so it can scale horizontally. Instead of diving straight into work after connecting, a client can call server/discover to learn which versions and capabilities a server supports. List results became cacheable.

On the agent communication side, Tasks were reworked in response to early adopter feedback and moved into an official extension. The old pattern of server-initiated requests was replaced by Multi Round-Trip Requests, a new approach that lets flows such as elicitation work even on stateless servers.

Governance matured as well. A Contributor Ladder was formally adopted, Working Groups now triage enhancement proposals in their own area, and the specification gained a feature lifecycle and deprecation policy. The deprecations in the July release were the first to go through it.

Agents that keep working need parts built for waiting

The first priority area covers messaging primitives for agents. Modern agent workloads do not fit neatly into a single request followed by a single response. Loops run longer, servers push intermediate results, and there are cases where you want to steer work that is already in flight.

MCP has been adding pieces to match: Tasks, subscriptions/listen, and progress notifications. What the roadmap questions is not whether the parts exist, but whether they fit together. The listed work includes server-initiated events, meaning webhooks and channels, so that clients stop polling for results. Alongside that, the Agents, Transports, and Triggers & Events Working Groups will review how the pieces compose. Maturing the Tasks extension so it can move into the specification proper is also on the list.

Getting local servers to speak HTTP too

The second area is transport unification. After the July changes, a remote MCP server is no different from any other HTTP workload, which means it can run on the same infrastructure developers and organizations already use for their APIs and services. That approach has proven it scales, so the maintainers want to stretch it to cover other deployment modes.

Local servers are the specific target. The plan under consideration is to have them speak Streamable HTTP over standard input and output. Not having to maintain separate transports for local and remote would make both server and client implementations simpler.

Nobody is around to click approve anymore

The third area, agent identity and enterprise-ready security, starts from the observation that the current authorization model rests on assumptions that are eroding. MCP authorization today is built around a person approving access in a browser. That suits interactive clients, but more callers are cloud workloads with identities of their own, acting for a user who is not present, and delegating narrower authority to sub-agents.

What the maintainers want is for servers to recognize and trust those agent identities using existing standards, rather than pasted API keys and long-lived tokens. The work items include finalizing and driving adoption of Demonstrating Proof of Possession (DPoP), which binds an access token to a key, and defining an opinionated path for identity and delegation using Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. Engagement with the IETF OAuth and WIMSE working groups continues.

Not showing all 100 tools before the first question

The fourth area is the primitives themselves. Tool calling is what most developers touch first in MCP, and it has held up. The weak spot is result handling. A tools/call response can carry the same output in more than one form, and a server developer has no way to know which form a given client will put in front of the model. The plan is to settle on one clear contract.

Scale is the other problem. Connecting to a server that exposes 100 tools means the model pays for the entire surface before the user has asked anything, and tool selection tends to degrade as the list grows. A progressive discovery effort is starting, so a server can offer a small entry point and reveal more of its catalog as the conversation narrows.

SDKs written on the assumption that an agent reads them

The fifth area is SDK developer experience. For many developers, the SDK is MCP. The maintainers are investing in ergonomics, conformance with the specification, and accurate documentation across every supported language and platform.

The reasoning is current. A growing number of developers build MCP clients and servers by pointing an agent at the libraries, which means clear APIs and correct docs are what decide whether the generated code works.

Which proposals get through changes

The roadmap also determines review order. Specification Enhancement Proposals (SEPs) that fall inside the five priority areas get expedited review and the best chance of acceptance. Proposals outside them are not rejected automatically, but the roadmap states plainly that maintainer review time is scarce and goes to these areas first.

Anyone considering a SEP is advised to identify which priority area it belongs to, raise it with the relevant Working Group, and shape the proposal with its members. Each area names the Core Maintainers responsible for it.

Summary

The July specification release brought MCP close to an ordinary stateless HTTP service, and this roadmap sets out what comes next on that foundation: sorting out the parts needed to handle long-running work, unifying transports down to local servers, verifying agent identity in situations where no human can approve, progressive discovery so tool selection survives growth, and SDK quality. The common thread is a gradual removal of the assumption that a person is watching, which lines up closely with what teams running agents in production actually worry about.

Source: https://blog.modelcontextprotocol.io/posts/mcp-roadmap/

Source: https://modelcontextprotocol.io/development/roadmap

Source: https://blog.modelcontextprotocol.io/posts/2026-07-28/