This is where extensions come in. They let developers layer new capabilities on top of the baseline MCP implementation without touching the core protocol. This allows us to keep things stable while also opening up room to experiment, learn, and build with the community’s needs in mind.

In this post, we’ll walk through how extensions fit into the MCP ecosystem and share some patterns the community is already exploring. Think of this less as a formal specification change and more as a short practical guide to extending MCP.

How MCP is structured

It helps to think of MCP in three layers:

• MCP core specification: The protocol itself. This is how clients and servers talk to each other. It also represents the absolute minimum bar for client and server interoperability.
• MCP projects: Supporting infrastructure like the Registry, that helps developers discover MCP servers, or Inspector, that makes MCP server testing and debugging easier.
• MCP extensions: Optional patterns that developers can adopt for specialized use cases, built on top of the MCP core specification.

Extensions let the ecosystem grow and give us an avenue to test changes and emerging spec components without destabilizing the core protocol that lots of production clients and servers already depend on.

The Extensions documentation covers the full details — including extension identifiers, capability negotiation during the initialization handshake, and the SEP (Specification Enhancement Proposal) process for proposing new ones.

Here’s where it gets interesting. Extensions are patterns built on existing MCP mechanisms, and they’re strictly additive: a client or server that doesn’t recognize an extension simply skips it during negotiation, and the baseline protocol keeps working. Nothing breaks when one side hasn’t opted in.

In practice, a few of these patterns have already emerged — some now formalized as official extensions, others still exploratory:

• UI extensions: Imagine a server that returns not just data, but an interactive interface for working with it — a chart you can filter, a form you can submit, a dashboard you can drill into. That’s what MCP Apps enables. It’s the first official MCP extension and went GA in January 2026, with support already live in ChatGPT, Claude, VS Code, Goose, and more.
• Authorization extensions: Need machine-to-machine auth without a user in the loop, or centralized enterprise IdP control? The auth extensions layer these on top of MCP’s core OAuth framework — OAuth Client Credentials and Enterprise-Managed Authorization are both live today.
• Domain-specific extensions: Community groups are already exploring conventions for verticals like financial services, where developers might want standardized ways to handle compliance metadata.

Another important side-effect to this approach is that MCP client and server developers get richer functionality without having to wait for protocol changes, which might need more extensive validation before being merged into the core.

Extensions are also the way to validate future protocol changes - if a particular implementation gains traction, that signals that there is a growing community need in protocol functionality that could become a part of the specification.

How extensions are governed

Extensions are community-driven, and all of them are optional. Developers adopt what makes sense for their use case.

At the same time, we encourage implementing official and recommended extensions when possible. It helps the whole ecosystem work better together. Official extensions typically start as conversations between MCP contributors, both on the core team and in the broader community, before graduating to the Model Context Protocol GitHub organization where they’re maintained collaboratively, following the Extensions Track SEP process.

Beyond officially-supported extensions, community members and working groups are also free to define their own extensions for any custom needs.

A note on proprietary integrations

Some MCP clients ship their own proprietary features, like custom UI systems, that happen to use MCP under the hood. These are not necessarily considered MCP extensions. They integrate with MCP servers but they don’t define how MCP itself behaves at the protocol level. We will work with client and server implementers to help them adopt extensions as the de-facto way to implement custom behaviors.

Get started

If you’re building on MCP and want to explore extensions:

• Read the docs: The Extensions overview covers identifiers, negotiation, governance, and the full list of official extensions.
• Build an MCP App: Follow the MCP Apps quickstart to ship an interactive UI that works across supporting clients today.
• Check client support: See the Extension Support Matrix for which clients already implement which extensions.
• Propose your own: If you have an idea for a new extension, the SEP guidelines walk you through opening an Extensions Track SEP.

Thank you

This post wouldn’t exist without the MCP community. The ideas here grew out of countless conversations - working group calls, GitHub threads, extension proposals, and plenty of back-and-forth in Discord.

To everyone who’s contributed ideas, challenged our initial assumptions, and helped shape where this is all going: thank you.

We’ll keep sharing updates here on the blog and in the public repos. See you there.

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!

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.

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.

The MCP Registry is now available in preview. To get started:

• Add your server by following our guide on Adding Servers to the MCP Registry (for server maintainers)
• Access server data by following our guide on Accessing MCP Registry Data (for client maintainers)

Single source of truth for MCP servers

In March 2025, we shared that we wanted to build a central registry for the MCP ecosystem. Today we are announcing that we’ve launched https://registry.modelcontextprotocol.io as the official MCP Registry. As part of the MCP project, the MCP Registry, as well as a parent OpenAPI specification, are open source—allowing everyone to build a compatible sub-registry.

Our goal is to standardize how servers are distributed and discovered, providing a primary source of truth that sub-registries can build upon. In turn, this will expand server reach and help clients find servers more easily across the MCP ecosystem.

Public and private sub-registries

In building a central registry, it was important to us not to take away from existing registries that the community and companies have built. The MCP Registry serves as a primary source of truth for publicly available MCP servers, and organizations can choose to create sub-registries based on custom criteria. For example:

Public subregistries like opinionated “MCP marketplaces” associated with each MCP client are free to augment and enhance data they ingest from the upstream MCP Registry. Every MCP end-user persona will have different needs, and it is up to the MCP client marketplaces to properly serve their end-users in opinionated ways.

Private subregistries will exist within enterprises that have strict privacy and security requirements, but the MCP Registry gives these enterprises a single upstream data source they can build upon. At a minimum, we aim to share API schemas with these private implementations so that associated SDKs and tooling can be shared across the ecosystem.

In both cases, the MCP Registry is the starting point – it’s the centralized location where MCP server maintainers publish and maintain their self-reported information for these downstream consumers to massage and deliver to their end-users.

Community-driven mechanism for moderation

The MCP Registry is an official MCP project maintained by the registry working group and permissively licensed. Community members can submit issues to flag servers that violate the MCP moderation guidelines—such as those containing spam, malicious code, or impersonating legitimate services. Registry maintainers can then denylist these entries and retroactively remove them from public access.

Getting started

To get started:

• Add your server by following our guide on Adding Servers to the MCP Registry (for server maintainers)
• Access server data by following our guide on Accessing MCP Registry Data (for client maintainers)

This preview of the MCP Registry is meant to help us improve the user experience before general availability and does not provide data durability guarantees or other warranties. We advise MCP adopters to watch development closely as breaking changes may occur before the registry is made generally available.

As we continue to develop the registry, we encourage feedback and contributions on the modelcontextprotocol/registry GitHub repository: Discussion, Issues, and Pull Requests are all welcome.

Thanks to the MCP community

The MCP Registry has been a collaborative effort from the beginning and we are incredibly grateful for the enthusiasm and support from the broader developer community.

In February 2025, it began as a grassroots project when MCP creators David Soria Parra and Justin Spahr-Summers asked the PulseMCP and Goose teams to help build a centralized community registry. Registry Maintainer Tadas Antanavicius from PulseMCP spearheaded the initial effort in collaboration with Alex Hancock from Block. They were soon joined by Registry Maintainer Toby Padilla, Head of MCP at GitHub, and more recently, Adam Jones from Anthropic joined as Registry Maintainer to drive the project towards the launch today. The initial announcement of the MCP Registry’s development lists 16 contributing individuals from at least 9 different companies.

Many others made crucial contributions to bring this project to life: Radoslav Dimitrov from Stacklok, Avinash Sridhar from GitHub, Connor Peet from VS Code, Joel Verhagen from NuGet, Preeti Dewani from Last9, Avish Porwal from Microsoft, Jonathan Hefner, and many Anthropic and GitHub employees that provided code reviews and development support. We are also grateful to everyone on the Registry’s contributors log and those who participated in discussions and issues.

We deeply appreciate everyone investing in this foundational open source infrastructure. Together, we’re helping developers and organizations worldwide to build more reliable, context-aware AI applications. On behalf of the MCP community, thank you.

Built in collaboration with the PHP Foundation and Symfony, the PHP SDK handles protocol details, so developers don’t have to worry about low-level mechanics and can focus on building their applications.

The initial release enables PHP developers to build MCP servers, exposing tools, prompts, and resources to AI applications. Support for PHP applications to act as MCP clients will follow.

The PHP SDK now joins 9 other officially supported language SDKs in the MCP ecosystem, making it easier for developers everywhere to adopt MCP in their preferred language.

Get involved

The PHP SDK is now open to the community to install, test, and contribute:

• SDK repo: modelcontextprotocol/php-sdk
• Composer package: mcp/sdk

We welcome your feedback and contribution, including issues, documentation improvements, and pull requests. Framework-specific integrations and real-world examples are also particularly valuable.

Thanks to the MCP community

This release consolidates earlier community work into a single, trusted implementation. The SDK is maintained by the Symfony team, with Kyrian Obikwelu joining as a maintainer based on his previous PHP-MCP work. The PHP Foundation helped to coordinate the initiative with support from the members of MCP steering group.

Thank you to all involved in bringing PHP to the MCP ecosystem.

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.