MCP publishes new roadmap covering agent identity and HTTP transport

The Core Maintainers of the Model Context Protocol (MCP), working with the community of maintainers and Working Groups, published an updated roadmap setting direction for protocol work over the coming months, covering the next specification release and beyond. The roadmap is organized into five priority areas. Several of them pick up work the previous roadmap had listed as merely 'on the horizon', including server-initiated events, result type improvements, and agent identity, which have since matured enough to become priorities in their own right.

The first area, agentic messaging primitives, addresses the fact that modern agentic workloads no longer fit the standard request-and-response pattern: loops can run for longer, servers can push streamed results, and there is a need to steer work mid-flight. MCP has already introduced Tasks, subscriptions/listen, and progress notifications to meet this, and the roadmap commits to server-initiated events (webhooks and channels, so clients are not left polling for results), a composition review across the Agents, Transports, and Triggers & Events Working Groups, and maturing the Tasks extension (SEP-2663) toward inclusion in the specification.

The second area is HTTP-native transport unification and hardening. With the 2026-07-28 release, a remote MCP server became no different from any other HTTP workload, which the maintainers say makes it easy to host on infrastructure organizations already use for their APIs. The roadmap extends that approach to other deployment modes, including local servers that speak Streamable HTTP over stdio, with the goal of simplifying both server and client development by unifying on one transport.

The third area is agent identity and enterprise-ready security. MCP authorization today is built around a person approving access in a browser, which works for interactive clients but not for the growing share of callers that are agents running as cloud workloads with their own identity, acting on behalf of an absent user, or delegating narrower authority to sub-agents. The roadmap commits to 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, this means finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining a path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange, alongside continued engagement with the IETF OAuth and WIMSE working groups.

The fourth area covers improved primitives for tool calling. A tools/call response can carry the same output in more than one form today, and a server developer has no way to know which form a given client will present to the model; the roadmap aims to standardize on one clear contract. It also addresses scale: connecting to a server with a hundred tools means the model pays for that entire surface before a user asks a single question, and tool selection tends to get worse as the list grows, so the maintainers are starting a progressive discovery effort letting a server offer a small entry point and reveal more of its catalog as the conversation narrows.

The fifth area is improved SDK developer experience, investing in the ergonomics, specification conformance, and documentation of MCP's SDKs across every supported platform and language, a priority the maintainers frame as more important now that many developers build MCP clients and servers by pointing an AI agent at the libraries directly.

Specification Enhancement Proposals (SEPs) that fall within these five areas get expedited review and the best chance of acceptance; proposals outside them are not automatically rejected, but maintainer review time goes to the priority areas first. The post also points contributors toward the relevant Working or Interest Group for their proposal, and notes that SEP-2133 lets any Working Group or Interest Group experiment in a repository before filing a formal SEP.

Key facts

MCP's Core Maintainers published an updated roadmap organized into five priority areas, covering the next specification release and beyond.
Agentic messaging primitives will get server-initiated events (webhooks and channels) and a matured Tasks extension (SEP-2663) toward spec inclusion.
Following the 2026-07-28 release that made remote MCP servers ordinary HTTP workloads, the roadmap extends that transport model to local servers speaking Streamable HTTP over stdio.
A new agent identity system is planned, built on DPoP, Workload Identity Federation, and standard token exchange, to replace pasted API keys and long-lived tokens for agents acting without a person present.
Tool primitives are being reworked to standardize response formats and add progressive discovery, since a hundred-tool server currently costs context before a user asks anything and degrades tool selection.

Why it matters

MCP has become a de facto standard for connecting AI models to external tools and data, and this roadmap is the maintainers' account of where the protocol still falls short as usage shifts from interactive chat sessions to autonomous, long-running agent workloads. The shift from a browser-approval security model to one built for agents acting without a person present is the clearest sign of that transition, and the emphasis on scale problems (a hundred-tool server taxing the model before a question is even asked) reflects real friction reported by developers building on the protocol.

Who it affects

MCP server and client developers building on the protocol's SDKs, organizations operating MCP servers as part of their infrastructure, and Working Group and Interest Group members whose Specification Enhancement Proposals will now be prioritized or deprioritized based on fit with these five areas. It also affects anyone building agents that need to authenticate to MCP servers without a human in the loop.

How to use it

The roadmap is a planning document, not a shipped feature: nothing here is available today beyond what MCP already supports (Tasks, subscriptions/listen, progress notifications, and the HTTP-native transport from the 2026-07-28 release). Developers with a Specification Enhancement Proposal that fits one of the five areas are told to raise it with the relevant Working Group for expedited review; anyone wanting to experiment ahead of a formal SEP can use the experimental-ext-repository mechanism under SEP-2133. No pricing or licensing terms are mentioned, since MCP is an open specification.

How solid is it

The roadmap comes directly from MCP's Core Maintainers and names concrete, trackable commitments: specific SEP numbers (SEP-2663 for Tasks, SEP-2133 for experimental extensions), a dated prior release (2026-07-28) that already shipped the HTTP-native transport, and named standards efforts (DPoP, Workload Identity Federation, IETF OAuth and WIMSE working groups) rather than vague ambitions. The post does not give target ship dates for the five priority areas or the next specification release, and does not name adopting companies or quantify current Working Group or contributor counts.

Risks and caveats

This is a roadmap, meaning priorities and intentions rather than commitments with dates: the post explicitly states that proposals outside the five areas are not rejected but simply get less review time, which means the pace of any single item depends on Working Group bandwidth that is not quantified here. The agent identity work in particular depends on external standards bodies (IETF OAuth, WIMSE) maturing their own specifications, which is outside MCP's direct control.

“MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn't present, or delegating narrower authority to sub-agents.”

— MCP Core Maintainers