The New MCP Roadmap  🔗 **Source:** [The New MCP Roadmap](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/) > [!note]+ Document Notes > --- > tags: [model-context-protocol, agent-identity, protocol-design, tool-discovery, oauth-delegation, sdk-ergonomics] > author: MCP Core Maintainers > source: Model Context Protocol blog (blog.modelcontextprotocol.io) > reference: https://blog.modelcontextprotocol.io/posts/mcp-roadmap/ > date created: 2026-08-24 09:00 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: The New MCP Roadmap > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [MCP specification](https://modelcontextprotocol.io/) — the protocol this roadmap governs > - SEP-2663 — the Tasks extension being matured into the specification > - SEP-2133 — allows any Working or Interest Group to experiment in an `experimental-ext-` repository before a formal SEP > - [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) — Demonstrating Proof of Possession, being finalised and driven to adoption > - [IETF OAuth Working Group](https://datatracker.ietf.org/wg/oauth/about/) and WIMSE — the standards bodies MCP is engaging > - Workload Identity Federation and the ID-JAG grant behind Enterprise-Managed Authorization — the delegation path being defined > ## 📝 Summary > - **What happened.** The MCP Core Maintainers published an updated roadmap covering the next specification release and beyond, developed with community maintainers and Working Groups. It organises protocol work into **five priority areas**, each owned by named Core Maintainers and one or more Working Groups. > - **Why it matters.** Two of the five address problems anyone using MCP at any scale has hit. **Progressive discovery** targets the fact that 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 get worse as the list grows." And **agent identity** addresses the mismatch between MCP's browser-consent authorization model and the reality that callers are increasingly cloud workloads acting for an absent user, or sub-agents receiving delegated authority. > - **Key stakeholders.** MCP server and client developers; enterprises blocked on authorization that doesn't fit agents; SDK users, especially the growing group who build MCP integrations by pointing an agent at the libraries; anyone with a Specification Enhancement Proposal outside the five areas. > - **Risks and tradeoffs.** The roadmap doubles as a **prioritisation notice with real consequences** — proposals outside the priority areas "aren't rejected automatically, but maintainer review time is scarce and goes to the roadmap first." No dates appear anywhere, which is honest but leaves adopters unable to plan. And the security work depends on standards bodies moving at their own pace. > - **Bottom line.** The through-line is **MCP converging on existing infrastructure rather than inventing parallel mechanisms** — one HTTP-native transport, OAuth-family standards for identity, one clear result contract instead of several. The most consequential single item for practitioners is progressive discovery, because tool-surface bloat is the constraint people are hitting right now. The most consequential structurally is agent identity, because "pasted API keys and long-lived tokens" is what it is replacing. > ## 📖 Main Content > The framing is procedural and worth reading carefully: the roadmap "sets the direction for protocol work over the coming months," was developed by Core Maintainers **together with** community maintainers and Working Groups, and each of its five areas is **owned by named Core Maintainers and one or more Working Groups**. Several priorities are promotions — server-initiated events, result type improvements, and agent identity all appeared on the previous roadmap as "on the horizon" and "have since matured enough to become priorities in their own right." That is a functioning pipeline rather than a wish list, and the promotion history is evidence for it. > **Agentic messaging primitives** starts from a correct observation: **"Modern agentic workloads no longer fit the standard request-and-response pattern."** Loops run longer, servers push streamed results, and there is a clear need to steer work mid-flight. MCP has already added Tasks, `subscriptions/listen`, and progress notifications — and the roadmap's stated concern is notable: not only offering the right primitives "but also that they work well together." A **composition review across the Agents, Transports, and Triggers & Events Working Groups** is explicitly part of the work. Protocols usually accrete primitives and discover the interaction problems later; scheduling a composition review before the primitives harden is unusual discipline. > The concrete items are **server-initiated events** — webhooks and channels, "so clients aren't left polling for results" — and maturing the **Tasks extension (SEP-2663)** into the specification proper. > **HTTP-native transport unification** reports an already-shipped result. With the **2026-07-28 release**, "a remote MCP server is now no different from any other HTTP workload, making it easy to host and operate one on any infrastructure that developers and organizations already use for their APIs and services." That is a significant operational claim: it means MCP servers inherit existing load balancers, observability, auth proxies, and deployment tooling rather than needing bespoke handling. > The next step is stranger and more interesting: extending the same model to **local servers speaking Streamable HTTP over stdio**. Running an HTTP-shaped protocol over a pipe looks odd until you see the goal — **one transport** means client and server implementations stop branching on deployment mode. The stated rationale, "unifying on one transport lets us simplify MCP server and client development even further," is the kind of simplification that pays off in every SDK and every implementation simultaneously. > **Agent identity and enterprise-ready security** contains the roadmap's sharpest problem statement. **"MCP authorization today is built around a person approving access in a browser."** That works for interactive clients and fails for three cases the roadmap names precisely: agents running as cloud workloads with their own identity; agents acting on behalf of a user who is not present; and agents delegating narrower authority to sub-agents. The third is the one most people have not thought about — sub-agent delegation with *reduced* scope is a genuine authorization primitive that currently has no expression. > The stated goal is a standardised way for servers to recognise and trust agent identities **"built on existing standards rather than pasted API keys and long-lived tokens."** That last phrase is an accurate and slightly damning description of current practice. > The work is specific and named: finalising **DPoP (Demonstrating Proof of Possession)** and driving adoption, and 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**. Plus continued engagement with **IETF OAuth and WIMSE working groups** to help the underlying standards evolve with what agent identity needs. > Two things stand out. **"Opinionated path"** is the right choice — a menu of standards-compliant options produces Today we’re excited to publish an updated [roadmap](https://modelcontextprotocol.io/development/roadmap) for the Model Context Protocol (MCP), covering the next specification release and beyond. The roadmap sets the direction for protocol work over the coming months. It was developed by the Core Maintainers together with our community of maintainers and Working Groups. [Explore the roadmap →](https://modelcontextprotocol.io/development/roadmap) #### Priority areas The roadmap is organized into five priority areas. Several of them pick up work that the [previous roadmap](https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/) listed as 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. Each area is owned by a set of Core Maintainers and one or more Working Groups. MCP Roadmap: five priority areas, agentic messaging primitives, HTTP-native transport unification and hardening, agent identity and enterprise-ready security, improved primitives, and improved SDK developer experience. ##### Agentic messaging primitives Modern agentic workloads no longer fit the standard [request-and-response pattern](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns). Loops can run for longer, servers can push streamed results, and there is a clear need to steer work mid-flight. MCP has been growing to meet these requirements, introducing [Tasks](https://modelcontextprotocol.io/extensions/tasks/overview), [`subscriptions/listen`](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), and [progress notifications](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/progress). We want to make sure that we not only offer the right primitives for the job, but also that they work well together. The work here spans server-initiated events (webhooks and channels, so clients aren’t left polling for results), a composition review across the [Agents](https://modelcontextprotocol.io/community/working-groups/agents), Transports, and [Triggers & Events](https://modelcontextprotocol.io/community/working-groups/triggers-events) Working Groups, and maturing the Tasks extension ([SEP-2663](https://modelcontextprotocol.io/seps/2663-tasks-extension)) so it can move into the specification. ##### HTTP-native transport unification and hardening With the [2026-07-28 release](https://modelcontextprotocol.io/specification/2026-07-28/changelog), a remote MCP server is now no different from any other HTTP workload, making it easy to host and operate one on any infrastructure that developers and organizations already use for their APIs and services. The model has proven to scale, and we want to stretch it to cover other deployment modes as well, including local servers speaking [Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) over [stdio](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdio). Unifying on one transport lets us simplify MCP server and client development even further. ##### Agent identity and enterprise-ready security [MCP authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/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. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens. The work here covers finalizing [Demonstrating Proof of Possession](https://www.rfc-editor.org/rfc/rfc9449) (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through [Workload Identity Federation](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1933), the ID-JAG grant behind [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization), and standard token exchange. We will also continue to grow our engagement with the OAuth standards bodies, including the IETF OAuth and [WIMSE](https://datatracker.ietf.org/wg/wimse/about/) working groups, to help the underlying standards evolve with the building blocks that agent identity needs. ##### Improved primitives Tool calling is the part of MCP most developers touch first, and it has held up well over the lifetime of the protocol. Where it falls a bit short, however, is in the result handling. A [`tools/call`](https://modelcontextprotocol.io/specification/2026-07-28/server/tools#tool-result) 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. We aim to make this easier by standardizing on one clear contract. The other challenge we need to address for primitive use is their ever-growing 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 get worse as the list grows. We’re starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows. ##### Improved SDK developer experience Our SDKs are how developers experience MCP. We are investing in their ergonomics and their [conformance with the specification](https://modelcontextprotocol.io/community/sdk-tiers#conformance-testing), and in making them intuitive and well-documented across every platform and language we support. This is even more important now that many developers build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work with minimal friction. #### Proposal prioritization [Specification Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines) (SEPs) that fall within these priority areas get expedited review and have the best chance of acceptance. Proposals outside them aren’t rejected automatically, but maintainer review time is scarce and goes to the roadmap first. If you’re considering a SEP, identify the priority area it belongs to, raise it with the relevant [Working Group](https://modelcontextprotocol.io/community/working-interest-groups), and work with its members to shape your proposal. Each area on the [roadmap](https://modelcontextprotocol.io/development/roadmap) names the Core Maintainers responsible for it, and anyone interested in contributing can reach them on [Discord](https://modelcontextprotocol.io/community/communication#discord). We’re excited to work with the community to review and build on the proposals that support this roadmap. #### Get involved Every priority area above has a Working Group behind it or forming around it, and all of them have room for more contributors. There are several ways to participate: * **Join a Working Group or Interest Group**: see the [Working and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups) page and the [community channels](https://modelcontextprotocol.io/community/communication). * **Propose or comment on a SEP**: read the [SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines), then open one or weigh in. * **Start an experimental extension**: [SEP-2133](https://modelcontextprotocol.io/seps/2133-extensions) lets any WG or IG experiment in an `experimental-ext-` repository before a formal SEP. * **Contribute directly**: the [contributing guide](https://modelcontextprotocol.io/community/contributing) covers the specification, SDKs, and tooling. We look forward to growing and evolving MCP together!, The New MCP Roadmap, blog.modelcontextprotocol.io, 01m0sxg44zpm7mkz01varwx97y.