Alongside the release, the Ruby SDK now meets every Tier 2 requirement of the SDK tiering system, as recorded in the Tier 2 assessment, and development toward Tier 1 is ongoing.

What is in 1.0

The 1.0 release implements the 2025-06-18 and 2025-11-25 specification revisions and passes 100% of the server and client conformance scenarios. It includes:

• MCP servers with tools, prompts, resources (including templates and subscriptions), completions, logging, pagination, progress, and cancellation, plus server-to-client requests for sampling, elicitation (form and URL mode), and roots
• An MCP client with a complete OAuth flow, including dynamic client registration, PKCE, and scope handling
• stdio and Streamable HTTP transports; the HTTP transport is a standard Rack app, so it can be mounted directly in Rails routes or any Rack-compatible framework

From Tier 3 to Tier 2

The Ruby SDK was assessed at Tier 3 in March 2026. Since then:

• Server conformance moved from 83.3% to 100%, with no baselined failures
• A conformance client was implemented and passes 100% of client scenarios
• Sampling, elicitation, and progress notifications were implemented on both the server and client sides
• ROADMAP.md and VERSIONING.md were published

Work is also under way to support the upcoming 2026-07-28 specification release.

Get started

Install the gem:

$ gem install mcp

A minimal stdio server looks like this:

require "mcp"

class ExampleTool < MCP::Tool
  description "A simple example tool that echoes back its arguments"
  input_schema(
    properties: {
      message: { type: "string" },
    },
    required: ["message"]
  )

  class << self
    def call(message:, server_context:)
      MCP::Tool::Response.new([{
        type: "text",
        text: "Hello from example tool! Message: #{message}",
      }])
    end
  end
end

server = MCP::Server.new(
  name: "example_server",
  tools: [ExampleTool],
)

MCP::Server::Transports::StdioTransport.new(server).open

See the Ruby SDK documentation for guides on building servers and clients, including Rails integration.

Give us your feedback

If you run into problems or unexpected behavior while using the SDK, please report them on the issue tracker. Reports from real-world usage are especially valuable.

The Ruby SDK began at Shopify and is maintained by Topher Bullock, Koichi Ito, Ateş Göral, and Jonathan Hefner together with the wider Ruby community. Thank you to everyone for the feedback and contributions on the road to 1.0.

Starting today you can test all the forthcoming updates to the protocol with all four Tier 1 SDKs, led by Python v2 and TypeScript v2, with Go and C# betas also available. We encourage you to run the beta SDKs against your real workloads and tell us what breaks as we inch closer to the actual spec revision. The new protocol specification will be launched on July 28, 2026.

Your existing server keeps working

First, we want to reassure you that for existing clients and servers nothing breaks today, and nothing breaks on July 28 either. This is merely the date when the normative specification text is published and is not a switch-off for any implementers relying on the current protocol version.

The SDK beta releases exist so you can test the protocol changes and give us feedback before the new specification is locked. For any critical workloads, the stable SDK releases remain the recommended versions.

You might’ve seen that some of the SDKs, like Python and TypeScript, have also switched to v2. Those are new major versions, so moving your own code onto them is a breaking change, and one you can take on your own schedule; it is separate from anything that happens on July 28. Once v2 ships, the TypeScript SDK will continue shipping v1.x bug fixes and security updates for at least six months, and the Python v1.x branch continues to receive critical bug fixes and security patches.

Trying a beta is safe because it is opt-in at every step. Installing the Python, Go, or C# SDK without explicitly requesting a pre-release still resolves to a stable version; the TypeScript v2 packages are new package names with no stable release yet, so installing them is itself the opt-in. In the TypeScript and Go SDKs, the opt-in extends to the wire: upgrading does not by itself change what your server speaks over HTTP. Serving 2026-07-28 is an explicit choice you make when you wire up the transport. A Python or C# server picks up the new revision on upgrade instead: a Python v2 server answers both protocol revisions from one endpoint, and the C# preview’s HTTP transport defaults to the new stateless mode. And clients that speak 2026-07-28 fall back to the initialize handshake when they reach a server on 2025-11-25 or earlier, so old servers and new clients keep interoperating.

If you want to make sure your own users are not caught out:

• If you publish a library that depends on the Python mcp package, add an upper bound now (for example mcp>=1.27,<2) so the stable v2 release does not surprise your users.
• When you test a beta, pin the exact version. Public APIs may still change between the beta and the stable releases.

What beta SDKs implement

All four beta releases implement the core protocol changes from the release candidate, with each release’s notes detailing which changes are covered. The RC announcement covers the changes in depth, but if you’re curious about the short version:

• The stateless core (SEP-2575, SEP-2567). Every request is self-describing, capabilities come from server/discover, and any server instance can handle any request.
• Multi Round-Trip Requests (MRTR) (SEP-2322). Tools can return InputRequiredResult to ask the user something mid-call, and the client retries with the answers. No long-lived stream required!
• Routable transport headers (SEP-2243). Mcp-Method rides on every request, and Mcp-Name on requests that name a tool, resource, or prompt, so gateways and rate limiters can route without parsing bodies.
• Authorization hardening, including iss validation per RFC 9207 (SEP-2468), application_type in Dynamic Client Registration (SEP-837), scope accumulation on step-up (SEP-2350), and credential binding to the issuing authorization server (SEP-2352). The application_type change is the one desktop and CLI clients will feel: authorization servers stop defaulting them to "web" and rejecting their localhost redirects.
• Standard error codes (SEP-2164). A missing resource now returns JSON-RPC -32602 instead of the MCP-custom -32002. If your client matches on the literal value, you should update it.
• Deprecation annotations (SEP-2577) on roots, sampling, and logging. This is advisory only, as the deprecated methods, types, and capability flags keep working in this release and in every specification version published within a year of it.

The full protocol text is in the draft specification, and the changelog lists every change against 2025-11-25.

Python: mcp v2

The v2 line is a rework of the package you already know: FastMCP becomes MCPServer, and the decorator API carries over. A complete server still looks like this:

from mcp.server import MCPServer

mcp = MCPServer("Demo")


@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b


@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
    """Greet someone by name."""
    return f"Hello, {name}!"

As in v1, there is no JSON Schema to write, as idiomatic Python constructs take over. Install the beta with an exact pin, since unpinned installs stay on v1.x:

uv add "mcp[cli]==2.0.0b1"
# or
pip install "mcp[cli]==2.0.0b1"

If you have a v1 server today, the migration guide walks through every breaking change.

On the protocol side, the beta speaks 2026-07-28 end to end: servers answer the new server/discover method, and the client’s default mode probes it and falls back to initialize on older servers. Upgrading your server does not strand existing clients: a v2 server answers the legacy initialize handshake alongside server/discover, so clients on 2025-11-25 keep connecting. You can test all of it in-process: pass your MCPServer instance directly to Client (async with Client(mcp) as client:) and it connects in memory, the same pattern as FastAPI’s TestClient. No subprocess, no port. The SDK documentation has the tutorial and the full API reference.

TypeScript: split packages

TypeScript v2 retires the monolithic @modelcontextprotocol/sdk package in favor of focused ones, like @modelcontextprotocol/server for servers, @modelcontextprotocol/client for clients, plus thin adapters for Node.js, Express, Hono, and Fastify. It is ESM-only and runs on Node.js 20+, Bun, and Deno. Tool schemas now use Standard Schema, so you can bring Zod v4, Valibot, ArkType, or any compatible library.

You can bootstrap a minimal server like this:

import { McpServer } from "@modelcontextprotocol/server";
import { StdioServerTransport } from "@modelcontextprotocol/server/stdio";
import * as z from "zod/v4";

const server = new McpServer({ name: "greeting-server", version: "1.0.0" });

server.registerTool(
  "greet",
  {
    description: "Greet someone by name",
    inputSchema: z.object({ name: z.string() }),
  },
  async ({ name }) => ({
    content: [{ type: "text", text: `Hello, ${name}!` }],
  }),
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main();

To install any of the packages, you can use the now-familiar npm commands:

npm install @modelcontextprotocol/server@beta
npm install @modelcontextprotocol/client@beta

For HTTP deployments, which is where the stateless protocol pays off, createMcpHandler from @modelcontextprotocol/server is the entry point. It serves 2026-07-28 per request and handles 2025-11-25 traffic from the same endpoint, with the adapter packages connecting it to Node.js, Express, Hono, and Fastify.

Migrating from v1 is mostly mechanical, and there is a codemod that does the boring parts for you, including the rename from .tool() to registerTool and the error-type renames. You can get it with:

npx @modelcontextprotocol/codemod@beta v1-to-v2 .

The repository ships two guides that will help you along the way:

• Upgrading from v1 to v2
• Adopting the 2026-07-28 revision

While it might seem confusing, these two are standalone steps - you can move to v2 now and turn on the new protocol revision when you are ready. The v2 API documentation covers the rest.

Go and C#

The Go and C# betas take a slightly gentler path - there is no package split and no rework of the API you use day to day.

The Go SDK ships 2026-07-28 support in v1.7.0-pre.1, on the same module path as the version you are already using:

go get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1

Serving the new revision over HTTP is the same explicit choice as in TypeScript: the streamable HTTP transport accepts 2026-07-28 only when you set StreamableHTTPOptions.Stateless = true. Leave it unset and clients negotiate down to 2025-11-25. The release notes walk through every protocol change and the SDK documentation will cover the updated API.

The C# beta, in turn, is released as the 2.0.0-preview.1 version of the ModelContextProtocol packages:

dotnet add package ModelContextProtocol --prerelease

Stable v1.x APIs keep working in v2. The breaking changes are confined to the capabilities the specification deprecates (roots, sampling, and logging), which are marked [Obsolete] with pointers to their replacements, and to experimental APIs whose contracts changed as the specification settled. The preview release notes include a per-SEP implementation table, and the SDK documentation will have the updated API reference once the package is stable.

Give us your feedback

We’re a mere four weeks away until the specification is final. We need your help to make the release smoother!

1. Install a beta in a branch of your server and run your real traffic against it, not just the happy path.

2. If you operate behind a gateway or load balancer, serve the stateless path and see whether your routing still needs anything the protocol no longer provides. In TypeScript that path is createMcpHandler; in Go, set StreamableHTTPOptions.Stateless = true; in Python, the v2 HTTP app answers both protocol revisions from one endpoint.

3. File what you find. SDK problems go to the issue tracker for the SDK you are using:

   • Python
   • TypeScript
   • Go
   • C#

   And if you spot issues with the protocol itself, go to the specification repository.

It’s worth noting that public APIs may still change between the betas and the stable releases, so pin exact versions. Your feedback in the next four weeks is what they will be built from. And if you have other feedback or want to engage with SDK maintainers, join our contributor Discord.

We’re excited to see what you build!

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.

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.

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.

About MCP

The Model Context Protocol is an open standard that enables seamless integration between AI assistants and external data sources and tools. It provides a universal way for AI models to interact with local services, APIs, and data stores.

Get Involved

We’re excited to build this ecosystem together with you. Here’s how you can participate:

• Check out the MCP specification
• Join the discussion on GitHub