We spent the last few months working through a long list of candidate priorities. They were informed by production experience, community feedback, and the pain points that keep surfacing. We narrowed them down to the areas that matter most for 2026. The result is an updated roadmap document that lays out where we’re headed.

If you read the January update, you’ll recognize the broad strokes. Production deployments have different needs than the early experiments that got us here, and the roadmap now reflects that. Here’s what changed and what it means for you.

From Releases to Working Groups

Previous versions of the roadmap were organized around release milestones: what’s shipping in the next spec version and what comes after. That framing made sense when the project was smaller and most of the work flowed through a handful of people.

Working and Interest Groups are now the primary vehicle for protocol development, and the roadmap needed to reflect that. The new document is organized around priority areas, rather than around dates. Working Groups drive the timeline for their deliverables. The roadmap tells you which problems we consider most important and points you to the groups working on them.

This approach also lets us be more honest about the uncertainty inherent in a fast-growing project like MCP. A release-oriented roadmap implies a level of predictability that open-standards work rarely has.

The Priority Areas

Core maintainers ranked candidate areas, and the result was a clear top four. These are the areas where SEPs will receive expedited review and where most of our maintainer capacity is concentrated.

Transport Evolution and Scalability

Streamable HTTP is the transport that lets MCP servers run as remote services rather than local processes. It unlocked a wave of production deployments. But running it at scale has surfaced a consistent set of gaps: stateful sessions fight with load balancers, horizontal scaling requires workarounds, and there’s no standard way for a registry or crawler to learn what a server does without connecting to it.

The work here falls into two parts. First, evolving the transport and session model so that servers can scale horizontally without having to hold state, as well as clear, explicit mechanisms to handle sessions. Second, a standard metadata format, that can be served via .well-known, so that server capabilities are discoverable without a live connection.

One thing we want to be explicit about: we are not adding more official transports this cycle but evolve the existing transport. Keeping the set small is a deliberate decision grounded in the MCP design principles.

Agent Communication

The Tasks primitive (SEP-1686) shipped as an experimental feature and works well for what it was designed to do. Early production use has surfaced a concrete list of lifecycle gaps to close: retry semantics when a task fails transiently, and expiry policies for how long results are retained after completion.

This is the kind of iteration you can only do once something is deployed and tested in the real world. We plan to take the same approach with other parts of MCP: ship an experimental version, gather production feedback, and iterate.

Governance Maturation

Right now, every SEP requires full Core Maintainer review, regardless of domain. That’s a bottleneck. It slows down Working Groups that already have the expertise to evaluate proposals in their own area.

The goal is to remove that bottleneck without sacrificing quality. Concretely, that means a documented contributor ladder so there’s a clear path from community participant to maintainer, and a delegation model that lets trusted Working Groups accept SEPs in their domain without waiting on a full core review. Core Maintainers keep strategic oversight. Working Groups get room to move.

Enterprise Readiness

Enterprises are deploying MCP and running into a predictable set of problems: audit trails, SSO-integrated auth, gateway behavior, and configuration portability.

This is also the least defined of the four priorities, and that’s intentional. We want the people experiencing these challenges to help us define the work.

A dedicated Enterprise WG does not yet exist. If you work in enterprise infrastructure and want to lead or join one, the Working Groups page explains how to get started. We also recommend joining the contributor Discord to make sure you’re not duplicating work or going solo on new proposals.

We expect most of the enterprise readiness work to land as extensions rather than core spec changes. Enterprise needs are real, but they shouldn’t make the base protocol heavier for everyone else.

SEP Prioritization: What It Means for Contributors

One of the most practical additions to the roadmap is explicit guidance on how SEP review capacity gets allocated.

The short version: SEPs aligned with the priority areas above will move the fastest. SEPs outside those areas aren’t automatically rejected, but they face longer review timelines and a higher bar for justification. Maintainer bandwidth is finite, and we’d rather be transparent about where it’s going.

If you’re considering writing a SEP, start with the SEP Guidelines. Once you’re familiar with those:

1. Check whether your proposed change maps to one of the priority areas. If it does not, be prepared for delays in reviews.
2. Bring it to the relevant Working Group. SEPs that arrive with WG backing and a clear connection to the roadmap are the ones that move.

On the Horizon

Not everything we care about made the top four, and we didn’t want those areas to disappear from view. We’re focused on a limited set of items, but we still want protocol exploration to continue at a good pace. The roadmap now includes an On the Horizon section for work with real community interest, such as triggers and event-driven updates, streamed and reference-based result types, deeper security and authorization work, and maturing the extensions ecosystem.

These aren’t deprioritized in the sense of “We don’t want them.” They’re areas where we’ll happily support a community-formed WG and review SEPs as time permits, but where Core Maintainers aren’t actively standing things up this cycle.

Some of these already have active proposals in review, such as SEP-1932 (DPoP) and SEP-1933 (Workload Identity Federation). Others, like triggers and event-driven updates, would benefit from a new Working Group.

Get Involved

Every deliverable on the roadmap runs through a Working Group, and every Working Group is open to contributors. Here are a few ways to get involved:

• Join a Working Group: Working Groups are the small teams doing the actual protocol design. They meet regularly and welcome new participants. The Working Groups & Interest Groups page lists what’s active and how to connect.
• Propose a SEP: SEPs are how changes to the protocol get proposed and reviewed. The SEP guidelines walk through the process.
• Start an extension: Extensions let us experiment with new capabilities outside the core spec. You can learn more in our official Extensions documentation.

If you’re not sure where to start, the easiest first step is to join a Working Group meeting and introduce yourself.

We’re excited to build the protocol together!

The Streamable HTTP transport was a significant step forward, enabling remote MCP deployments and unlocking new use cases. However, as enterprise deployments scale to millions of daily requests, early adopters have encountered practical challenges that make it difficult to leverage existing infrastructure patterns. The friction of stateful connections has become a bottleneck for managed services and load balancing.

Some of these challenges include:

• Infrastructure Complexity: Load balancers and API gateways must parse full JSON-RPC payloads to route traffic, rather than using standard HTTP patterns.
• Scaling Friction: Stateful connections force “sticky” routing that pins traffic to specific servers, preventing effective auto-scaling.
• High Barrier for Simple Tools: Developers building simple, ephemeral tools are often required to manage complex backend storage to support basic multi-turn interactions.
• Ambiguous Session Scope: There is no predictable mechanism for defining where a conversation context starts and ends across distributed systems.

Roadmap

Over the past few months, the Transport Working Group has worked together with the community and MCP Core Maintainers to develop solutions to these challenges.

In this post we share the roadmap for evolving the Streamable HTTP transport and invite community feedback to help shape the future of MCP transports.

A Stateless Protocol

MCP was originally designed as a stateful protocol. Clients and servers maintain mutual awareness through a persistent, bidirectional channel that begins with a handshake to exchange capabilities and protocol version information. Because this state remains fixed throughout the connection, scaling requires techniques like sticky sessions or distributed session storage.

We envision a future where agentic applications are stateful, but the protocol itself doesn’t need to be. A stateless protocol enables scale, while still providing features to support stateful application sessions when needed.

We are exploring ways to make MCP stateless by:

• Replacing the initialize handshake and sending the shared information with each request and response instead.
• Providing a discovery mechanism for clients to query server capabilities if they need the information early, for scenarios such as UI hydration.

These changes enable a more dynamic model where clients can optimistically attempt operations and receive clear error messages if a capability is unsupported.

NOTE: Many SDKs already offer a stateless option in their server transport configuration, though the behavior varies across implementations. As part of this roadmap, we’ll be working to standardize what “stateless” means across all official SDKs to ensure consistent behavior.

Elevating Sessions

Currently, sessions are a side effect of the transport connection. With STDIO, sessions are implicit in the process lifecycle; with Streamable HTTP, sessions are created when a server assigns an Mcp-Session-Id during initialization. This can lead to confusion between transport and application layer concerns.

We are looking at moving sessions to the data model layer, making them explicit rather than implicit.

This would allow MCP applications to handle sessions as part of their domain logic. We’re exploring several approaches, with a cookie-like mechanism being one potential candidate to decouple session state from the transport layer.

This direction mirrors standard HTTP, where the protocol itself is stateless while applications build stateful semantics using cookies, tokens, and similar mechanisms. The exact approach to session creation is still being designed, with the goal of removing existing ambiguities around what a session means in remote MCP scenarios.

Elicitations and Sampling

Two MCP features are central to a few of the modern AI workflows: Elicitations, which request human input, and Sampling, which enable agentic LLM interactions.

Supporting these features at scale requires rethinking the bidirectional communication pattern they rely on. Currently, when a server needs more information to complete a tool call, it suspends execution and waits for a client response, requiring it to track all outstanding requests.

To address this, we’re looking at designing server requests and responses to work similarly to chat APIs. The server returns the elicitation request as usual, and the client returns both the request and response together. This allows the server to reconstruct the necessary state purely from the returned message, avoiding long-running state management between nodes and potentially eliminating the need for back-end storage entirely.

Update Notifications and Subscriptions

MCP is dynamic by design - tools, prompts, and resources can change during operation. Today, servers send ListChangedNotification messages to clients as a hint to invalidate their caches.

We’re exploring replacing the general-purpose GET stream with explicit subscription streams. Clients would open dedicated streams for specific items they want to monitor, with support for multiple concurrent subscriptions. If a stream is interrupted, the client simply restarts it with no complex resumption logic.

To make notifications truly optional - an optimization rather than a requirement - we’re considering adding Time-To-Live (TTL) values and version identifiers (such as ETags) to data. This would let clients make intelligent caching decisions independently of the notification stream, significantly improving reliability.

JSON-RPC Envelopes

MCP uses JSON-RPC for all message envelopes, including method names and parameters. As we optimize for HTTP deployments, a common question is whether routing information should be more accessible to the underlying MCP server infrastructure.

While we’re keeping JSON-RPC as the message format, we’re exploring ways to expose routing-critical information (such as the RPC method or tool name) via standard HTTP paths or headers. This would allow load balancers and API gateways to route traffic without parsing JSON bodies.

Server Cards

Today, clients must complete a full initialization handshake just to learn basic information about an MCP server, like its capabilities or available tools. This creates friction for discovery, integration, and optimization scenarios.

We’re exploring the direction of introducing MCP Server Cards: structured metadata documents that servers expose through a standardized /.well-known/mcp.json endpoint. Server Cards enable clients to discover server capabilities, authentication requirements, and available primitives before establishing a connection. This unlocks use cases like autoconfiguration, automated discovery, static security validation, and reduced latency for UI hydration — all without requiring the full initialization sequence.

Official and Custom Transports

To ensure a minimum compatibility baseline across the ecosystem, MCP will continue to support only two official transports: STDIO for local deployments and Streamable HTTP for remote deployments. This keeps the core ecosystem unified, where every MCP client and server can interoperate out of the box.

We also recognize that transport and protocol changes can be disruptive. Backwards compatibility is a priority, and we’ll only introduce breaking changes when strictly necessary for critical use cases.

For teams with specialized requirements, the MCP Specification supports Custom Transports, giving developers the flexibility to build alternatives that fit their needs. Our focus is on making Custom Transports easier to implement by improving SDK integration—so the community can experiment freely without fragmenting the standard.

Summary

These changes reorient MCP around stateless, independent requests - without sacrificing the rich features that make it powerful. Server developers get simpler horizontal scaling with no sticky sessions or distributed stores. Clients get a more predictable architecture.

For most SDK users, both on the client and server sides, the impact will be minimal - we’re focused on reducing breaking changes to the absolute minimum. The shift we’re outlining is architectural: simpler deployments, serverless viability for advanced MCP features, and better alignment with modern infrastructure patterns.

Next Steps

Work is already underway. Our goal is to finalize the required Spec Enhancement Proposals (SEPs) in the first quarter of 2026 for inclusion in the next specification release, which is tentatively slated for June of 2026. With these changes, MCP can easily scale while keeping the ergonomics that made it successful.

We want your input. Join us in the MCP Contributors Discord server, or engage directly with transport-related SEPs in the Model Context Protocol repository.

This roadmap is shaped by real-world feedback from developers and companies building with MCP. We’re excited to collaborate with the MCP community to continuously improve the protocol and its capabilities!

In one year, MCP has become one of the fastest-growing and widely-adopted open-source projects in AI: Over 97 million monthly SDK downloads, 10,000 active servers and first-class client support across major AI platforms like ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code and many more.

Since its inception, we’ve remained committed to ensuring MCP remains open and community-driven. This move formalizes that commitment—ensuring MCP’s vendor-neutrality and long-term independence under the same neutral stewardship that supports Kubernetes, PyTorch, and Node.js. Anthropic’s commitment to MCP is unchanged: we will continue to invest in its development, maintain core infrastructure, and actively participate in the community.

The Agentic AI Foundation

MCP will be a founding project of the newly created Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg to advance open-source innovation in agentic AI.

MCP joins two other founding projects: goose by Block and AGENTS.md by OpenAI as founding projects.

The AAIF Governing Board will make decisions regarding strategic investments, budget allocation, member recruitment, and approval of new projects, while individual projects, such as MCP, maintain full autonomy over their technical direction and day-to-day operations.

MCP’s maintainer structure stays the same

For MCP little changes. The governance model we introduced earlier this year continues as is. The people making decisions about the protocol are still the maintainers who have been stewarding it, guided by community input through our SEP process.

The Linux Foundation provides a neutral home and infrastructure that allows maintainers to operate independently, and will not dictate the technical direction of MCP.

Thank you

To all who’ve adopted and contributed to MCP so far, thank you. None of this would’ve been possible without your contribution. From building servers to maintaining SDKs to filing issues to improving documentation to welcoming new visitors and everything in between, you’ve made MCP what it is today.

Here’s to MCP’s next chapter under the Linux Foundation’s stewardship.

Why the Change?

When we introduced SEPs in July, we chose GitHub Issues as our starting point. Issues are familiar to developers, low-friction, and got us up and running quickly. But as more proposals have come through the process, we’ve identified some key pain points:

Scattered discussions. With issues, the proposal text lives in the issue body while implementation details often end up in a separate PR. This splits the conversation and makes it harder to follow the full history of a proposal. This also introduces two distinct numbers referencing the same SEP, making it harder to consistently track and manage changes.

No version history. Issues don’t have the same revision tracking that files in a repository do. When a SEP evolves through review, it’s difficult to see what changed and when.

The new PR-based approach, inspired by Python’s PEP process, solves both problems.

How It Works

The new workflow will be familiar if you’ve submitted pull requests on GitHub before:

1. Draft your SEP as a markdown file named 0000-your-feature.md using the SEP template

2. Create a pull request adding your SEP to the seps/ directory

3. Update the SEP number once your PR is created, rename the file using the PR number (e.g., PR #1850 becomes 1850-your-feature.md) and push a new commit with the rename

4. Find a sponsor from our maintainer list to shepherd your proposal

5. Iterate on feedback directly in the PR

That’s it. The PR number becomes the SEP number, discussion happens in one place, and git tracks every revision.

What About Status?

One notable change: sponsors are now responsible for updating SEP status. In addition to applying labels to the pull request, the sponsor is responsible for ensuring that the Status field is updated in the SEP markdown file. This keeps the canonical state of the proposal in the file itself, versioned alongside the content, while PR labels make it easy to filter and find SEPs by status.

Status transitions work the same as before: Draft to In-Review to Accepted to Final, with the sponsor managing each transition as the proposal progresses.

Getting Started

Ready to propose a change to MCP? Here’s what you need to know:

For new SEPs:

• Read the latest SEP Guidelines
• Use the SEP template to create your proposal
• Browse existing SEPs in the seps/ directory for examples
• Follow the workflow described above

For existing SEPs: If you have a SEP submitted as a GitHub issue, you can continue with your current workflow. We strongly encourage migrating to the new process for better version control and centralized discussion. To migrate:

1. Create a markdown file using the SEP template, starting with 0000-your-feature.md
2. Copy and adapt your proposal content to fit the template structure
3. Submit a pull request to the seps/ directory
4. Rename the file using your new PR number (e.g., PR #1900 becomes 1900-your-feature.md)
5. Close the original issue with a link to the new PR

The new PR gets a fresh SEP number and gives your proposal proper version control and centralized discussion. Any valuable context from the original issue discussion should be summarized in the new SEP or referenced via links.

As always, if you’re unsure whether your idea warrants a SEP, start a conversation on Discord or GitHub Discussions. We’re happy to help you figure out the right path forward.

Thank You

This change is a direct result of feedback from contributors who’ve been through the SEP process. Your input helps us continuously improve how we build MCP together. Keep it coming.

Today, we’re taking a big step to ensure MCP can continue to grow and thrive. We’re introducing a formal governance model designed to bring clarity to the development process while preserving the collaborative, open source spirit that has made MCP successful.

Specification Enhancement Proposals (SEPs)

One of the first major changes we’re introducing is Specification Enhancement Proposals (SEPs). This will be the primary mechanism for anyone to propose changes to MCP. SEPs are inspired by other projects, like Python PEPs or Rust RFCs. We aim to make the process for suggesting changes to Model Context Protocol as straightforward as possible:

1. Following the SEP guidelines, submit a proposal as a GitHub issue to start the conversation.
2. Our maintainers and core maintainers regularly review proposals and tag SEPs for review and sponsorship. You can also reach out and collaborate with contributing folks on Discord or GitHub. Refer to MAINTAINERS.md for a list of currently active maintainers and their focus areas.
3. Work with the sponsor and the MCP community to move your proposal through draft, review, and implementation stages.

SEPs provide a clear, documented path for evolving the protocol, ensuring that every major change is well-vetted by the community.

Leadership Roles

The new model also establishes three types of leadership roles, ensuring both focused ownership and broad community representation:

• Maintainers manage specific components like SDKs, our documentation, and individual repositories.
• Core Maintainers guide the overall direction of the project and the evolution of the MCP specification.
• Lead Maintainers serve as the final decision-makers and ensure the project’s long-term health.

All maintainers form the MCP steering group. To ensure a structured and timely review of incoming proposals, our core and lead maintainers will meet bi-weekly to review submitted SEPs. Meeting notes and decisions will always be public. For example the notes from the core maintainer meeting on July 23rd, 2025.

Get Involved

We need your help to build the future of MCP, and everyone is welcome here. Whether you’re a seasoned open source veteran or just curious about how to get started, there’s a place for you in our community.

Many of our maintainers began with a single small contribution—sometimes just fixing a typo or asking a thoughtful question. Every journey starts somewhere, and we’re excited to help you take your first step.

• New Contributors: Unsure where to begin? Start by helping with documentation, fixing bugs, or building out examples. Every contribution matters, and we’re here to support you. Check out issues tagged with good first issue - they’re perfect for getting started, and you’ll find friendly faces ready to help.
• SDK Developers: Have a favorite programming language? As MCP grows, we need your expertise to build and maintain the protocol SDKs. Your work could empower entire new communities to use MCP.
• Documentation Writers: Clear, comprehensive documentation is what turns a good project into a great one. If you love explaining things or making guides, your contributions will help others succeed.
• Future Maintainers: We believe in growing our team from within. The path to becoming a maintainer starts with consistent, quality contributions and a commitment to the project’s success. Imagine yourself guiding new contributors and shaping the future of MCP.

No matter your background or experience, you belong here. Join our Discord to connect with other contributors, ask questions, and find mentorship. Whether you’re fixing a typo or proposing a major change to the protocol, your voice is valued and your efforts make a difference.

For all the details, please see our full governance documentation.

Thank You

None of this would be possible without the incredible community that has rallied around MCP. From the early adopters who believed in the vision, to the developers building MCP clients and servers, to the maintainers dedicating their time and expertise. Every contribution has been essential to making the Model Context Protocol the success it is today.

You’ve helped us identify issues, improve documentation, build SDKs, create compelling examples, and push the boundaries of what’s possible with platform integration. Your feedback, bug reports, feature requests, and code contributions have shaped MCP into something far better than we could have built alone.

As we embark on this next chapter with formal governance, we’re more committed than ever to fostering the open, inclusive community that has made MCP thrive. Thank you for being part of this journey - we can’t wait to see what we’ll build together next.