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!

Release Timeline

The next version of the Model Context Protocol specification will be released on November 25th, 2025, with a release candidate (RC) available on November 11th, 2025.

We’re building in a 14-day RC validation window so client implementors and SDK maintainers can thoroughly test the protocol changes. This approach gives us the focused time we need to deliver critical improvements while applying our new governance model to the process.

Summer Progress

Our last spec was released on June 18, 2025, and focused on structured tool outputs, OAuth-based authorization, elicitation for server-initiated user interactions, and improved security best practices.

Since then, we’ve focused on establishing additional foundations for the MCP ecosystem:

Formal Governance Structures

We established a formal governance model for MCP, including defined roles and decision-making mechanisms. We also developed the Specification Enhancement Proposal (SEP) process to provide clear guidelines for contributing specification changes.

Our goal is transparency—making decision-making procedures clear and accessible to everyone. Like any new system serving a fast-evolving community, our governance model is still finding its footing. We’re actively refining it as both the protocol and community continue to grow.

Working Groups

We’ve launched Working Groups and Interest Groups to foster community collaboration. These groups serve multiple purposes:

• Provide clear entry points for new contributors
• Empower community members to lead initiatives in their areas of expertise
• Distribute ownership across the ecosystem rather than concentrating it among core maintainers

We’re developing governance structures that will grant these groups greater autonomy in decision-making and implementation. This distributed approach ensures the protocol can grow to meet community needs while maintaining quality and consistency across different domains.

Registry Development

In September, we launched the MCP Registry preview—an open catalog and API for indexing and discovery of MCP servers. The Registry serves as the single source of truth for available MCP servers, supporting both public and private sub-registries that organizations can customize for their specific needs.

Building the MCP Registry has been a true community effort. Any MCP client can consume registry content via the native API or through third-party registry aggregators, making it easier for users to discover and integrate MCP servers into their AI workflows.

Priority Areas for the Next Release

With governance and infrastructure foundations in place, we’re focusing on five key protocol improvements identified by our working groups.

Asynchronous Operations

Currently, MCP is built around mostly synchronous operations—when you call a tool, everything stops and waits for it to finish. That works great for quick tasks, but what about operations that take minutes or hours?

The Agents Working Group is adding async support, allowing servers to kick off long-running tasks while clients can check back later for results. You can follow the progress in SEP-1391.

Statelessness and Scalability

As organizations deploy MCP servers at enterprise scale, we’re seeing new requirements emerge. Current implementations often need to remember things between requests, which makes horizontal scaling across multiple server instances challenging.

While Streamable HTTP provides some stateless support, pain points remain around server startup and session handling. The Transport Working Group is smoothing out these rough edges, making it easier to run MCP servers in production while keeping simple upgrade paths for teams who want more sophisticated stateful features.

Server Identity

Today, if you want to know what an MCP server can do, you have to connect to it first. This makes it difficult for clients to browse available servers or for systems like our registry to automatically catalog capabilities.

We’re solving this by letting servers advertise themselves through .well-known URLs—an established standard for providing metadata. Think of it as a server’s business card that anyone can read without having to knock on the door first. This will make discovery much more intuitive for every MCP consumer.

Official Extensions

As MCP has grown, we’ve noticed patterns emerging for specific industries and use cases—valuable implementations that don’t necessarily belong in the core protocol specification.

Rather than leaving everyone to reinvent the wheel, we’re officially recognizing and documenting the most popular protocol extensions. This curated collection of proven patterns will give developers building for specialized domains like healthcare, finance, or education a solid starting point instead of building every custom integration from scratch.

SDK Support Standardization

Choosing an MCP SDK today can be challenging—it’s hard to gauge the level of support or spec compliance you’ll get. Some SDKs are lightning-fast with updates, while others might lag behind feature-wise.

We’re introducing a clear tiering system for SDKs. You’ll know exactly what you’re signing up for before committing to a dependency, based on factors like specification compliance speed, maintenance responsiveness, and feature completeness.

Call for Contributors

MCP is only as strong as the community behind it. Whether you’re an individual developer passionate about building SDKs or a company looking to invest in the ecosystem, we need your help in several key areas.

SDK Maintenance

• TypeScript SDK - Needs additional maintainers for feature development and bug fixes
• Swift SDK - Requires attention for Apple ecosystem support
• Other language SDKs welcome continued contributions

Tooling

• Inspector - Development and maintenance of debugging tools for MCP server developers
• Registry - Backend API and CLI development; Go expertise would be particularly welcome

Input from Client Developers

We talk a lot about MCP servers, but clients are equally important—they’re the bridge connecting users to the entire MCP ecosystem. If you’re building an MCP client, you’re seeing the protocol from a unique angle, and we need that perspective embedded in the protocol design.

Your real-world experience with implementation challenges, performance bottlenecks, and user needs directly shapes where the protocol should go next. Whether it’s feedback on existing capabilities or ideas for streamlining the developer experience, we want to hear from you.

Join us in the #client-implementors working group channel in the MCP Discord.

Looking Ahead

With governance structures and working groups in place, we’re better positioned to tackle major protocol improvements efficiently while ensuring everyone has a voice in the process. The foundational work we’ve done this summer gives us a solid base to build from.

The improvements coming in November—async operations, better scalability, server discovery, and standardized extensions—will help MCP become a stronger backbone for production AI integrations. But we can’t do it alone.

MCP’s strength has always been that it’s an open protocol built by the community, for the community. We’re excited to keep building it together.

Thank you for your continued support, and we look forward to sharing more soon.