On August 22, the Model Context Protocol team published an updated roadmap covering the next specification release and beyond. The post, authored by lead maintainers David Soria Parra and Den Delimarsky, organizes work into five priority areas. Each area has designated Core Maintainers and one or more Working Groups behind it.
The roadmap is notable for what it signals: several items that appeared on the horizon in the previous roadmap have graduated to active priorities. Server-initiated events, result type improvements, and agent identity have matured enough to command dedicated maintainer attention. For developers building MCP servers or clients, these are the workstreams that will shape the protocol over the coming months.
Agentic messaging primitives
Modern agentic workloads no longer fit the standard request-and-response pattern. Loops run for longer, servers push streamed results, and there is a clear need to steer work mid-flight. MCP has been growing to meet these requirements, introducing Tasks, subscriptions/listen, and progress notifications.
The roadmap calls out three concrete threads here. First, server-initiated events via webhooks and channels so clients are not left polling for results. Second, a composition review across the Agents, Transports, and Triggers & Events Working Groups to ensure these primitives work well together. Third, maturing the Tasks extension (SEP-2663) so it can move into the specification proper.
For developers, the practical takeaway is that if you are building long-running agent workflows today, the primitives you need — tasks, streaming, progress — are converging but not yet stabilized. The Tasks extension is the one to watch; once it lands in the spec, it becomes the standard way to represent multi-step, interruptible work.
HTTP-native transport unification and hardening
With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload. This makes it straightforward to host and operate MCP servers on any infrastructure that developers already use for APIs and services — Kubernetes, Cloudflare Workers, Vercel, Fly.io, or a plain VPS.
The roadmap indicates the team wants to stretch this approach to cover other deployment modes, including local servers speaking Streamable HTTP over stdio. Unifying on one transport simplifies both server and client development: instead of maintaining separate code paths for stdio, SSE, and HTTP, you target one transport that works everywhere.
If you are deploying MCP servers today, the HTTP-native path is the blessed one. The stdio transport is not going away (local-first tooling depends on it), but new investment goes into making Streamable HTTP over stdio a first-class option for local development too.
Agent identity and enterprise-ready security
MCP authorization today is built around a person approving access in a browser. That works for interactive clients, but more and more callers are agents running as cloud workloads with their own identity, acting on behalf of a user who is not present, or delegating narrower authority to sub-agents.
The roadmap outlines a standards-based approach rather than pasted API keys and long-lived tokens. Three pillars: finalizing Demonstrating Proof of Possession (DPoP, RFC 9449) and driving its adoption; defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange; and continuing engagement with the IETF OAuth and WIMSE working groups so the underlying standards evolve with the building blocks agent identity needs.
For server developers, this means the authentication story is moving toward workload identity and short-lived, bound credentials. If you are building an MCP server that needs to serve both interactive users and autonomous agents, plan for a token exchange flow rather than a single long-lived bearer token.
Improved primitives
Tool calling is the part of MCP most developers touch first, and it has held up well. Where it falls short is result handling. A tools/call response can carry the same output in more than one form, and a server developer today has no way to know which form a given client will put in front of the model. The roadmap aims to standardize on one clear contract.
The second challenge is scale. Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, 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.
For server authors, this is a signal to design tool surfaces with progressive disclosure in mind. A server that exposes a handful of high-leverage tools up front and gates the rest behind discovery will behave better with models as the spec evolves.
Improved SDK developer experience
SDKs are how most developers experience MCP. The roadmap acknowledges that many developers now build MCP clients and servers by pointing an agent at the libraries, where clear APIs and accurate docs decide whether the code works with minimal friction. Investment goes into ergonomics, conformance with the specification, and documentation across every supported platform and language.
Conformance testing is called out explicitly. If you maintain an SDK or are evaluating one, the conformance suite is the benchmark to watch — it is the mechanism that keeps implementations honest as the spec moves.
Proposal prioritization and how to contribute
Specification Enhancement Proposals (SEPs) that fall within these five priority areas get expedited review and have the best chance of acceptance. Proposals outside them are not rejected automatically, but maintainer review time is scarce and goes to these areas first.
The roadmap page names the Core Maintainers responsible for each area, and anyone interested in contributing can reach them on Discord. There are several ways to participate: join a Working Group or Interest Group, propose or comment on a SEP, start an experimental extension under SEP-2133, or contribute directly to the specification, SDKs, and tooling.
What this means for developers today
The roadmap is a statement of maintainer capacity as much as technical direction. Five priority areas, each with named maintainers and Working Groups, means the protocol has the governance structure to move multiple workstreams in parallel. That is a significant shift from the earlier phase where a smaller core team sequenced everything.
If you are building on MCP, the practical moves are: target the HTTP-native transport for new servers; design tool surfaces for progressive disclosure; watch the Tasks extension (SEP-2663) for long-running workflows; and plan authentication around workload identity and token exchange rather than static API keys. The SDK conformance suite will be the signal of which libraries are tracking the spec faithfully.
The roadmap is public at modelcontextprotocol.io/development/roadmap. The Working Groups page lists current groups and how to join. The SEP guidelines explain the proposal process. All three are linked from the roadmap post.