MCP roadmap targets agent identity, HTTP transport unification and progressive tool discovery

A five-track plan for the protocol

The core maintainers of the Model Context Protocol have published an updated roadmap that sets the direction for the AI-agent connectivity specification over the coming months, including its next release. According to the post on the MCP blog, which surfaced on the front page of Hacker News, the document was drafted by the Core Maintainers together with the broader community and its working groups. It is organised into five priority areas, several of which — server-initiated events, result type improvements and agent identity — were previously flagged as future work and have since matured into priorities of their own.

Agentic messaging primitives

The first area starts from the observation that modern agent workloads no longer fit the classic request-and-response pattern: loops run longer, servers push streamed results, and running work sometimes needs to be redirected mid-course. MCP has already grown Tasks, subscription and listen semantics, and progress notifications, and the roadmap's stated goal is to make sure these primitives compose well rather than merely exist. Concrete work includes server-initiated events — webhooks and channels, so clients no longer need to poll for results — a composition review spanning the Agents, Transports, and Triggers & Events working groups, and maturing the Tasks extension (SEP-2663) enough to fold it into the specification itself.

Unifying transports on HTTP

With the 2026-07-28 specification release, a remote MCP server became just another HTTP workload, which the maintainers say has made hosting straightforward on ordinary API infrastructure and has scaled well in practice. The roadmap now proposes stretching that model to further deployment modes, including local servers speaking Streamable HTTP over stdio, so that a single transport simplifies both client and server development.

Identity for agents, not just people

MCP's current authorisation model assumes a person approving access in a browser. That breaks down when the caller is an agent running as a cloud workload with its own identity, acting on behalf of a user who is not present, or delegating narrower authority to sub-agents. The maintainers want servers to have a standardised way to recognise and trust such agent identities, built on existing standards rather than static API keys and long-lived tokens. Planned work includes finalising Demonstrating Proof of Possession (DPoP) and driving its adoption, defining a route for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange. The team also intends to keep working with the IETF OAuth and WIMSE working groups so the underlying standards evolve to support what agent identity requires.

Cleaner tool results and progressive discovery

Tool calling is the part of MCP most developers touch first, and the maintainers judge that it has served the protocol well so far, with result handling as the main shortcoming. A tools/call response can currently carry the same output in more than one form, and a server developer has no way to know which form a given client will present to the model; the roadmap aims to settle on one clear contract. The second problem is scale: connecting to a server that exposes a hundred tools means the model pays for that entire surface before the user's first request, and tool selection tends to degrade as the list grows. A new progressive discovery effort will let a server expose a compact starting surface and unfold more of its catalogue as the interaction narrows.

SDK developer experience

The SDKs are how most developers actually experience MCP, so the maintainers are investing in their ergonomics, their conformance with the specification, and documentation across every supported platform and language. They argue this matters more now because many builders create MCP clients and servers by pointing an agent at the libraries, where well-designed APIs and reliable documentation heavily influence whether the resulting code works with little friction.

What this means for SEP authors

Specification Enhancement Proposals that fall within the five priority areas receive expedited review and have the best chance of acceptance. Proposals outside them are not rejected outright, but maintainer review time is limited and goes to these areas first. The post encourages contributors to identify the relevant priority area, raise ideas with its working group, and contact the responsible Core Maintainers on Discord. Other routes include joining a working or interest group, commenting on SEPs, starting an experimental extension under SEP-2133 before a formal proposal, or contributing directly to the specification, SDKs and tooling.

Why it matters

For anyone building MCP clients or servers, this roadmap is the advance warning for what changes are coming: new event-driven primitives, a single HTTP-based transport, a proper identity story for machine callers, and altered tool-result and discovery behaviour. The agent-identity track is notable beyond MCP itself, since it ties the protocol's evolution to IETF OAuth and WIMSE standardisation, meaning decisions here could ripple into wider web infrastructure. The progressive discovery work addresses a practical cost that grows with every tool a server exposes, and the explicit prioritisation rule tells proposal authors exactly where review attention will and will not be spent.