You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/development/roadmap.mdx
+62-29Lines changed: 62 additions & 29 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,62 +3,95 @@ title: Roadmap
3
3
description: Our plans for evolving Model Context Protocol
4
4
---
5
5
6
-
<Info>Last updated: **2025-10-31**</Info>
6
+
<Info>Last updated: **2026-03-05**</Info>
7
7
8
-
The Model Context Protocol is rapidly evolving. This page outlines our priorities for **the next release on November 25th, 2025**, with a release candidate available on November 11th, 2025. To see what's changing in the upcoming release, check out the **[specification changelog](/specification/draft/changelog/)**.
9
-
10
-
For more context on our release timeline and governance process, read our [blog post on the next version update](https://blog.modelcontextprotocol.io/posts/2025-09-26-mcp-next-version-update/).
8
+
This page describes our strategic priorities and what we expect **Working Groups** and **Interest Groups** to deliver against them.
11
9
12
10
<Note>
13
11
14
-
The ideas presented here are not commitments—we may solve these challenges differently than described, or some may not materialize at all. This is also not an _exhaustive_ list; we may incorporate work that isn't mentioned here.
12
+
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.
15
13
16
14
</Note>
17
15
18
-
We value community participation! Each section links to relevant discussions where you can learn more and contribute your thoughts.
16
+
## SEP Prioritization
19
17
20
-
For a technical view of our standardization process, visit the [Standards Track](https://github.com/orgs/modelcontextprotocol/projects/2/views/2) on GitHub, which tracks how proposals progress toward inclusion in the official [MCP specification](https://modelcontextprotocol.io/specification/).
18
+
**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.
21
19
22
-
## Priority Areas for the Next Release
20
+
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.
23
21
24
-
### Asynchronous Operations
22
+
##Priority Areas
25
23
26
-
Currently, MCP is built around mostly synchronous operations. We're adding async support to allow servers to kick off long-running tasks while clients can check back later for results. This will enable operations that take minutes or hours without blocking.
24
+
### 1. Transport Evolution and Scalability
27
25
28
-
Follow the progress in [SEP-1686](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1686).
26
+
Streamable HTTP gave MCP a production-ready transport, but running it at scale has revealed gaps around horizontal scaling, stateless operation, and middleware patterns.
29
27
30
-
### Statelessness and Scalability
28
+
**What we want to achieve:**
31
29
32
-
As organizations deploy MCP servers at enterprise scale, we're addressing challenges around horizontal scaling. While [Streamable HTTP](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http) provides some stateless support, we're smoothing out rough edges around server startup and session handling to make it easier to run MCP servers in production.
30
+
-**Next-generation transport**: evolve Streamable HTTP to run statelessly across multiple server instances and behave correctly behind load balancers and proxies.
31
+
-**Scalable session handling**: define how sessions are created, resumed, and migrated so that server restarts and scale-out events are transparent to connected clients.
32
+
-**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.
33
33
34
-
The current focus point for this effort is [SEP-1442](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1442).
34
+
**Working Group ownership:**
35
35
36
-
### Server Identity
36
+
-**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.
37
+
-**Server Card WG** owns the Server Card format and its distribution, coordinating with the broader industry AI-catalog effort.
37
38
38
-
We're enabling servers to advertise themselves through [`.well-known` URLs](https://en.wikipedia.org/wiki/Well-known_URI)—an established standard for providing metadata. This will allow clients to discover what a server can do without having to connect to it first, making discovery much more intuitive and enabling systems like our registry to automatically catalog capabilities. We are working closely across multiple projects in the industry to rely on a common standard on agent cards.
39
+
Wewill **not** be introducing additional official transports this cycle. Keeping the set small protects ecosystem compatibility; the community should experiment via custom transports.
39
40
40
-
### Official Extensions
41
+
### 2. Agent Communication
41
42
42
-
As MCP has grown, valuable patterns have emerged for specific industries and use cases. Rather than leaving everyone to reinvent the wheel, we're officially recognizing and documenting the most popular protocol extensions. This curated collection will give developers building for specialized domains like healthcare, finance, or education a solid starting point.
43
+
The Tasks primitive ([SEP-1686](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1686)) 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:
43
44
44
-
### SDK Support Standardization
45
+
-**Retry semantics**: what happens when a task fails transiently, and who decides whether to retry.
46
+
-**Expiry policies**: how long results are retained after completion, and how clients learn a result has expired.
45
47
46
-
We're introducing a clear tiering system for SDKs based on factors like specification compliance speed, maintenance responsiveness, and feature completeness. This will help developers understand exactly what level of support they're getting before committing to a dependency.
48
+
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.
47
49
48
-
### MCP Registry General Availability
50
+
### 3. Governance Maturation
49
51
50
-
The [MCP Registry](https://github.com/modelcontextprotocol/registry) launched in preview in September 2025 and is progressing toward general availability. We're stabilizing the v0.1 API through real-world integrations and community feedback, with plans to transition from preview to a production-ready service. This will provide developers with a reliable, community-driven platform for discovering and sharing MCP servers.
52
+
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.
51
53
52
-
## Validation
54
+
The **Governance WG** should deliver:
55
+
56
+
-**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.
57
+
-**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.
58
+
-**A charter template** that every WG and IG maintains publicly: scope, active deliverables, success criteria, and retirement conditions, reviewed quarterly.
59
+
60
+
### 4. Enterprise Readiness
61
+
62
+
Enterprises are deploying MCP at scale and hitting gaps the protocol does not yet address.
63
+
64
+
Areas where we need clear problem statements and directional proposals:
65
+
66
+
-**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.
67
+
-**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.
68
+
-**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.
69
+
-**Configuration portability**: a way to configure a server once and have that configuration work across different MCP clients.
53
70
54
-
To foster a robust developer ecosystem, we plan to invest in:
71
+
We expect an **Enterprise WG** to form to own this. Much of the output will likely land as extensions rather than core specification changes.
55
72
56
-
-**Reference Client Implementations**: demonstrating protocol features with high-quality AI applications
57
-
-**Reference Server Implementation**: showcasing authentication patterns and remote deployment best practices
58
-
-**Compliance Test Suites**: automated verification that clients, servers, and SDKs properly implement the specification
73
+
## On the Horizon
59
74
60
-
These tools will help developers confidently implement MCP while ensuring consistent behavior across the ecosystem.
75
+
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.
76
+
77
+
-**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.
78
+
-**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.
79
+
-**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).
80
+
-**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.
81
+
82
+
## Validation
83
+
84
+
A protocol specification is only as good as the implementations that follow it. Alongside the areas above, we continue to invest in:
85
+
86
+
-**Conformance Test Suites**: automated verification that clients, servers, and SDKs correctly implement the specification, with coverage expanding alongside each new feature area.
87
+
-**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.
88
+
-**Reference Implementations**: canonical implementations of new features to anchor community development and unblock early adopters.
61
89
62
90
## Get Involved
63
91
64
-
We welcome your contributions to MCP's future! Join our [GitHub Discussions](https://github.com/orgs/modelcontextprotocol/discussions) to share ideas, provide feedback, or participate in the development process.
92
+
MCP's roadmap is built by its community:
93
+
94
+
-**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.
95
+
-**Propose or comment on SEPs**: review the [SEP guidelines](/community/sep-guidelines) and open or weigh in on proposals.
96
+
-**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.
97
+
-**Contribute to the project**: read the [contributing guide](/community/contributing) for how to get involved with the specification, SDKs, and tooling.
0 commit comments