Roadmap

 # Roadmap
 
-> Our plans for evolving Model Context Protocol
+> The Model Context Protocol roadmap, covering the priority areas Core Maintainers and Working Groups are driving for the next specification release and how they shape SEP review.
 
-<Info>Last updated: **2026-03-05**</Info>
+<Info>Last updated: **2026-08-22**</Info>
 
-This page describes our strategic priorities and what we expect **Working Groups** and **Interest Groups** to deliver against them.
+This page outlines the Core Maintainers' vision for the protocol over the coming six to twelve months, highlighting objectives targeted for the next specification update and beyond. It describes our primary strategic goals and the expected deliverables from [Working and Interest Groups](/community/working-interest-groups).
 
 <Note>
-  The ideas presented here are not commitments. We may solve these challenges differently than described. Some items may not materialize at all. This is also not an *exhaustive* list. We may incorporate work that isn't mentioned here.
+  This roadmap reflects current thinking rather than firm commitments. Priorities may shift, some items may be delivered differently than described or deferred, and work not listed here may still be included in the release.
 </Note>
 
 ## SEP Prioritization
 
-**SEPs that fall within the priority areas below will receive expedited review and have the highest chance of acceptance.** SEPs outside these areas are not automatically rejected, but contributors should expect longer review timelines and a higher bar for justification. Maintainer capacity is finite. We direct it toward these priorities first.
+**[Specification Enhancement Proposals](/community/sep-guidelines) (SEPs) that fall within the priority areas below get expedited review and have the best chance of acceptance.** SEPs outside them aren't rejected automatically, but expect a longer queue and a higher bar for justification. Maintainer review time is scarce. We spend it here first.
 
-If you are considering a SEP, check whether it aligns with one of the areas below, discuss it in the relevant [Working Group or Interest Group](/community/working-interest-groups), and bring that group's backing with you. SEPs with WG support and a clear connection to the roadmap move fastest. See the [SEP guidelines](/community/sep-guidelines) for the full process.
+If you're considering writing a SEP, start by identifying which priority area it belongs to and raising it with the relevant Working Group, then bring that group's support with the proposal. SEPs with a Working Group behind them and a clear line to this roadmap move fastest. See the [SEP guidelines](/community/sep-guidelines) for the full process.
 
+Each priority area names the Core Maintainers responsible for it, who can be reached on [Discord](/community/communication#discord) by anyone interested in contributing. The items listed under each area are the deliverables prioritized for this roadmap period. The remainder of each area is open scope, and Working Groups are expected to define and contribute further work within it.
+
 ## Priority Areas
 
-### 1. Transport Evolution and Scalability
+### 1. Agentic Messaging Primitives
 
-Streamable HTTP gave MCP a production-ready transport, but running it at scale has revealed gaps around horizontal scaling, stateless operation, and middleware patterns.
+Core Maintainers: [**Caitie McCaffrey**](https://github.com/CaitieM20), [**Clare Liguori**](https://github.com/clareliguori), [**Peter Alexander**](https://github.com/pja-ant)
 
-**What we want to achieve:**
+Agentic workloads need [messaging patterns](/specification/2026-07-28/basic/patterns) beyond request and response: work that runs for minutes, servers that push, results that stream, and a way to steer work mid-flight. MCP has grown a set of concepts for this, including [Tasks](/extensions/tasks/overview), [`subscriptions/listen`](/specification/2026-07-28/basic/patterns/subscriptions), and [progress notifications](/specification/2026-07-28/basic/patterns/progress), spread across multiple Working Groups. The risk is three answers to "the server isn't done yet" that don't share a lifecycle, a cancellation model, or an error surface. We want them to compose.
 
-* **Next-generation transport**: evolve Streamable HTTP to run statelessly across multiple server instances and behave correctly behind load balancers and proxies.
-* **Scalable session handling**: define how sessions are created, resumed, and migrated so that server restarts and scale-out events are transparent to connected clients.
-* **MCP Server Cards**: a standard for exposing structured server metadata via a `.well-known` URL, so browsers, crawlers, and registries can discover a server's capabilities without connecting to it.
+**This roadmap period:**
 
-**Working Group ownership:**
+* **Server-initiated events**: [Triggers & Events WG](/community/working-groups/triggers-events). Channels and subscriptions for push delivery, including webhooks. As we take on asynchronous workloads through Tasks and other events, we need extensions that let servers tell clients when work has finished, without relying purely on expensive client-side polling.
+* **A composition review**: [Agents](/community/working-groups/agents), Transports, and [Triggers & Events](/community/working-groups/triggers-events) WGs. Primitives in the making, such as Tasks and Triggers, need to compose cleanly with each other and fit concrete use cases.
 
-* **Transports WG** owns the transport and session work: a series of SEPs covering the wire format, session model, and resumption protocol, plus conformance guidance for SDK authors.
-* **Server Card WG** owns the Server Card format and its distribution, coordinating with the broader industry AI-catalog effort.
+Beyond these, we expect continued work on Tasks ([SEP-2663](/seps/2663-tasks-extension)) toward eventual inclusion of the extension in the core protocol.
 
-We will **not** be introducing additional official transports this cycle. Keeping the set small protects ecosystem compatibility; the community should experiment via custom transports.
+### 2. HTTP-Native Transport Unification and Hardening
 
-### 2. Agent Communication
+Core Maintainers: [**Kurtis Van Gent**](https://github.com/kurtisvg), [**Nick Cooper**](https://github.com/nickcoai)
 
-The Tasks extension ([SEP-2663](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663)) gave agents a reliable call-now / fetch-later pattern. Running it in production has surfaced gaps in the lifecycle semantics that the **Agents WG** should close:
+The [2026-07-28 release](/specification/2026-07-28/changelog) made a remote MCP server a normal HTTP workload, and we increasingly rely on HTTP specifics such as headers and status codes to carry transport-level information. Every HTTP-native feature needs a second stdio-specific design or doesn't work locally. SDKs maintain two transport pipelines, and protocol metadata is now duplicated across HTTP headers and message fields that servers have to cross-validate. We want one transport model, with standard HTTP practice on top of it.
 
-* **Retry semantics**: what happens when a task fails transiently, and who decides whether to retry.
-* **Expiry policies**: how long results are retained after completion, and how clients learn a result has expired.
+**This roadmap period:**
 
-These are the gaps we can point to today. The Agents WG should also collect and triage operational issues from production deployments—this list will grow as more of the ecosystem runs Tasks at scale.
+* **HTTP over stdio**: Transports WG. Streamable HTTP as the single binding, spoken over stdin/stdout for local servers. We believe we can use HTTP/2 over stdio to get multiplexed HTTP transport while retaining the security and lifecycle guarantees of a subprocess.
+* **Caching**: Transports WG. The most recent protocol revision made strides toward caching, adding `ttlMs` and `cacheScope` to list results and resource reads ([SEP-2549](/seps/2549-TTL-for-list-results)). As part of this work, we want to extend our caching approach to support ETags, which should allow versioning the results of primitives, in particular tool calls.
 
-### 3. Governance Maturation
+Beyond these, we want to look at standardized error handling across all surfaces, capability scoping for tool lists after [SEP-2575](/seps/2575-stateless-mcp), and providing servers with configuration options in a secure way.
 
-MCP has grown into a multi-company open standard under the Linux Foundation. [SEP-1302](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1302) formalized Working Groups and Interest Groups, and [SEP-2085](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2085) established succession and amendment procedures. The next step is giving the community a clear path to leadership so the project does not depend on a small set of individuals.
+### 3. Agent Identity and Enterprise-Ready Security
 
-The **Governance WG** should deliver:
+Core Maintainers: [**Paul Carleton**](https://github.com/pcarleton), [**Den Delimarsky**](https://github.com/localden)
 
-* **A Contributor Ladder SEP** defining the progression from community participant → WG contributor → WG facilitator → lead maintainer → core maintainer, with explicit nomination and review criteria at each step.
-* **A delegation model** allowing WGs with a proven track record to accept SEPs and publish extension updates within their domain without a full core-maintainer review cycle.
-* **A charter template** that every WG and IG maintains publicly: scope, active deliverables, success criteria, and retirement conditions, reviewed quarterly.
+MCP authorization assumes a person with a browser at consent time. Increasingly the caller is an agent: a cloud workload with its own identity, acting for a user who isn't present, or spawning sub-agents that should get narrower authority than their parent. Existing MCP servers lean on pasted API keys and long-lived refresh tokens. We need a standardized way for MCP servers to handle agent identities, and we will continue improving security by adopting existing standards.
 
-### 4. Enterprise Readiness
+**This roadmap period:**
 
-Enterprises are deploying MCP at scale and hitting gaps the protocol does not yet address.
+* **DPoP**: Agent Identity WG (forming during this roadmap period). Finalize the specification for Demonstrating Proof of Possession (DPoP) and focus on getting widespread adoption.
+* **Agent identity and delegation**: Agent Identity WG. We want an opinionated way for MCP servers to be reached by agents through their own identity or a user-delegated identity. The work will focus on Workload Identity Federation ([SEP-1933](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1933)), the Identity Assertion JWT Authorization Grant (ID-JAG) used by [Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization), and [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693) token exchange, coordinated with the IETF OAuth and [WIMSE](https://datatracker.ietf.org/wg/wimse/about/) working groups.
 
-Areas where we need clear problem statements and directional proposals:
+Beyond these, several other topics are under discussion and may come into scope as the Working Group forms, including human-presence attestation for distinguishing interactive clients from headless agents and other agent identity concerns.
 
-* **Audit trails and observability**: end-to-end visibility into what a client requested and what a server did, in a form enterprises can feed into their existing logging and compliance pipelines.
-* **Enterprise-managed auth**: paved paths away from static client secrets and toward SSO-integrated flows ([Cross-App Access](https://xaa.dev)), so IT can manage MCP access the same way they manage everything else.
-* **Gateway and proxy patterns**: well-defined behavior when a client does not connect directly to a server but routes through an intermediary. This may include authorization propagation, session semantics, and what the gateway is allowed to see.
-* **Configuration portability**: a way to configure a server once and have that configuration work across different MCP clients.
+### 4. Improved Primitives
 
-We expect an **Enterprise WG** to form to own this. Much of the output will likely land as extensions rather than core specification changes.
+Core Maintainers: [**Kurtis Van Gent**](https://github.com/kurtisvg), [**Peter Alexander**](https://github.com/pja-ant), [**Den Delimarsky**](https://github.com/localden)
 
-## On the Horizon
+MCP's tool calling interface has served well. However, `tools/call` allows returning both `content` and `structuredContent` at the same time, which has confused server and client authors alike and produced diverging implementations. We want to spend this roadmap period improving the shape of the `tools/call` interface for more consistent semantics. We also hear repeatedly from the community that servers need more options to guide clients through large sets of tools, resources, and other primitives, so we're starting a dedicated effort around **progressive discovery** to define what an experimental server-side discovery mechanism would look like.
 
-These areas have community interest and interest from core maintainers but are not top priorities. We will support a community-formed Working Group in any of them and review SEPs on these topics if time permits.
+**This roadmap period:**
 
-* **Triggers and Event-Driven Updates** — clients currently learn about server-side state changes by polling or holding an SSE connection open. A standardized callback mechanism (webhooks or similar) would let servers proactively notify clients when new data is available, with defined ordering guarantees across all transports.
-* **Result Type Improvements** — tool calls, resource reads, and task results all arrive complete and inline. Streamed results would let clients receive output incrementally for interactive scenarios (generated text, audio, video frames); reference-based results would let clients decide when to pull large payloads into context rather than polluting it by default. This is cross-cutting: streaming touches transport, references touch the schema.
-* **Security & Authorization** — finer-grained least-privilege scopes, clearer guidance on avoiding OAuth mix-up attacks, secure credential management on both client and server, and a community-driven vulnerability disclosure program routed through the Linux Foundation. Sponsored work is already underway: [SEP-1932 (DPoP)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1932) and [SEP-1933 (Workload Identity Federation)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1933).
-* **Extensions Ecosystem** — the `ext-auth` and `ext-apps` tracks are early proof that the extension mechanism works. Maturing them, investigating a Skills primitive for composed capabilities, and adding first-class extension support to the registry would all strengthen the path from experiment to standard.
+* **Tool result shape**: Core Primitives WG (forming during this roadmap period). Redesign the `tools/call` interface to resolve fidelity disparities among return types and streamline the handling of structured and unstructured output.
+* **Progressive discovery**: Core Primitives WG. Clients learn a server's tools and resources as they need them instead of ingesting the full catalog up front, with a defined interaction with the caching work under [HTTP-Native Transport Unification and Hardening](#2-http-native-transport-unification-and-hardening).
+* **Primitive annotations**: Core Primitives WG. [Content annotations](/specification/2026-07-28/server/resources#annotations) in the specification declare a piece of content's intended audience and priority. Applying them to tool results and resources could resolve the visibility confusion described in [SEP-2200](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2200), but most implementers haven't adopted these annotations and may not be aware of their purpose. If they aren't useful, we should consider deprecating them.
 
-## Validation
+In addition, the [File Uploads WG](/community/working-groups/file-uploads) continues on scoped file operations and filesystem-like resource semantics (range reads, hierarchical listing).
 
-A protocol specification is only as good as the implementations that follow it. Alongside the areas above, we continue to invest in:
+### 5. Improved SDK Developer Experience
 
-* **Conformance Test Suites**: automated verification that clients, servers, and SDKs correctly implement the specification, with coverage expanding alongside each new feature area.
-* **SDK Tiers**: the tiering system introduced in [SEP-1730](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1730) gives developers a clear signal of which SDKs track the specification most closely.
-* **Reference Implementations**: canonical implementations of new features to anchor community development and unblock early adopters.
+Core Maintainers: [**Den Delimarsky**](https://github.com/localden), [**David Soria Parra**](https://github.com/dsp-ant)
 
+Our SDKs, reference servers, and quickstarts are maintained by hand. While this works, we believe the specification and a human-reviewed conformance test suite can serve as the source of truth from which more of these artifacts are derived, so that both SDKs and examples are regenerated and revalidated as part of each release rather than repaired after it.
+
+**This roadmap period:**
+
+* **The extension contract**: [SDK WG](/community/working-groups/sdk) with the Core Maintainers. Which role an extension binds (host, client, server, agent) and what each does when the capability is declared; what SDKs must support natively; how extensions are packaged; capability additions as versioned changes to the extension; auth treated as its own area.
+* **The generated-artifacts experiment**: [SDK WG](/community/working-groups/sdk). Generate a candidate [Tier 1 SDK](/community/sdk-tiers) and its companion quickstart examples from the specification, validate both against the [conformance test suite](/community/sdk-tiers#conformance-testing), and publish findings with a recommendation for the next cycle, including which layers should be deterministic codegen versus model-assisted.
+
+Beyond these, we want to revisit ownership and freshness expectations for the reference servers and quickstart repositories, and treat spec clarity issues surfaced by generation failures as documentation bugs.
+
 ## Get Involved
 
-MCP's roadmap is built by its community:
+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 Groups & Interest Groups](/community/working-interest-groups) page and the [community communication channels](/community/communication) to connect with the groups active in each area above.
-* **Propose or comment on SEPs**: review the [SEP guidelines](/community/sep-guidelines) and open or weigh in on proposals.
-* **Start an experimental extension**: [SEP-2133](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2133) lets any WG or IG experiment in an `experimental-ext-` repository before a formal SEP is required.
-* **Contribute to the project**: read the [contributing guide](/community/contributing) for how to get involved with the specification, SDKs, and tooling.
+* **Join a Working Group or Interest Group**: see the [Working and Interest Groups](/community/working-interest-groups) page and the [community channels](/community/communication).
+* **Propose or comment on a SEP**: read the [SEP guidelines](/community/sep-guidelines), then open one or weigh in.
+* **Start an experimental extension**: [SEP-2133](/seps/2133-extensions) lets any WG or IG experiment in an `experimental-ext-` repository before a formal SEP.
+* **Contribute directly**: the [contributing guide](/community/contributing) covers the specification, SDKs, and tooling.