Today, we’re officially pushing the release button on the next version of the MCP specification, 2026-07-28, along with the SDKs that will allow you to start building clients and servers right away.

The highlight of this release is a stateless protocol core - MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol. It was one of the most highly-requested features from developers who were eager to get better reliability and scalability for their MCP servers.

There is, of course, more to what we’re introducing with this version:

• Every request is self-describing, with an optional discovery call for clients that want capabilities up front, so any request can land on any instance behind a plain round-robin load balancer.
• Method and tool names travel in the Mcp-Method and Mcp-Name HTTP headers, so gateways can route and authorize on headers directly.
• Server-to-client requests for things like sampling and elicitation are being redesigned to use Multi Round-Trip Requests (MRTR), removing the need for constantly open bidirectional streams.
• List responses carry cache hints and a deterministic order, so clients can cache tool catalogs and keep upstream prompt caches stable across reconnects.
• Formally locking in on a proper extensions framework, with Tasks joining other extensions, such as MCP Apps and Enterprise Managed Authorization (EMA).
• A set of authorization hardening changes including RFC 9207 issuer validation and a formal shift away from Dynamic Client Registration (DCR) toward client metadata documents (CIMD).
• A formal deprecation policy with a twelve-month minimum window so you can plan upgrades instead of reacting to them.

The TypeScript, Python, Go, and C# SDKs are updated to match, with detailed migration notes for the breaking bits - and you can get started with the new spec right away.

What changed

No handshake or sessions

With the new spec version, we’ve officially retired the initialize/initialized exchange along with the Mcp-Session-Id header (refer to SEP-2575, SEP-2567). Each request now travels on its own, carrying its protocol version, client identity, and client capabilities in _meta. If a client wants to learn a server’s capabilities before doing anything else, there’s a new server/discover Remote Procedure Call (RPC) for that; however, it is not required. Any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Dropping the protocol-level session doesn’t force your application to be stateless. If your server needs to carry state across calls, mint an explicit handle from a tool and have the model pass it back as an argument. We found this works better than session state hidden in the transport - the model can see the handle and thread it between tools.

Multi Round-Trip Requests (MRTR)

MRTR replaces the server-initiated elicitation/create, sampling/createMessage, and roots/list requests that previously required a held-open stream.

Sometimes a tool needs something from the user mid-call, such as a confirmation or a missing parameter. MRTR (SEP-2322) enables this scenario over a stateless protocol: the server returns resultType: "input_required" along with the requests it needs answered, and the client retries the original call with the answers attached in inputResponses.

Header-based routing

Streamable HTTP requests now must include Mcp-Method and Mcp-Name (SEP-2243). Your gateway, rate limiter, or WAF can route and meter on those headers instead of parsing JSON bodies.

List results are cacheable

Responses from tools/list, prompts/list, resources/list, and resources/read now carry ttlMs and cacheScope (SEP-2549). This allows clients to determine the best caching strategy for responses and reduce unnecessary re-fetching.

Authorization

From our discussions with implementers for the past year, authorization is where implementers spend most of their integration time. With this spec revision, we continued evolving the MCP auth and security posture.

• Authorization servers should return the iss parameter per RFC 9207, and clients must validate it before redeeming a code (SEP-2468). This closes an authorization-server mix-up hole.
• Clients set application_type during Dynamic Client Registration (DCR) so authorization servers stop rejecting localhost redirects for desktop and CLI apps (SEP-837). If you’ve ever wondered why your CLI client’s OAuth flow got a redirect_uri error, this is likely why. And while we’re moving to Client ID Metadata Documents (CIMD) as the standard, this is a hardening measure making the protocol comply with OAuth spec requirements.
• Client credentials are bound to the issuer that minted them. No reuse across authorization servers (SEP-2352).
• Dynamic Client Registration itself is now formally deprecated in favor of CIMD. DCR continues to work for backward compatibility, but will be removed in a future version of the MCP spec.

Tasks

Tasks move out of the experimental core and into the io.modelcontextprotocol/tasks extension, with a poll-based tasks/get and a new tasks/update (SEP-2663). Change notifications move from the old HTTP GET endpoint to a single subscriptions/listen stream that clients opt into per notification type.

Deprecations

Roots, Sampling, and Logging are deprecated (SEP-2577). They still work, and they’ll keep working for at least twelve months. New implementations shouldn’t adopt them. The legacy HTTP+SSE transport is also considered to be officially deprecated, with a year-long offramp.

SDKs

All four Tier 1 SDKs speak 2026-07-28 as of today:

• TypeScript
• Python
• Go
• C#

Beyond the Tier 1 set, the Rust SDK supports the new spec in beta.

The SDKs implement APIs that allow you to build both servers and clients with the new spec version. As we mentioned in the SDK beta blog post, there will be some migration cost, especially for developers that did depend on session identifiers; however, we incorporated early testing feedback that makes this process much easier.

Ecosystem support

As with any large release, the work that we’re doing with MCP would not be possible without contributions from folks across the ecosystem. We’re also especially grateful to a number of contributors and partners who helped us test and validate the spec before it became generally available.

The new release is MCP’s most important since remote MCP first launched over a year ago. It is a leap in serving scalable MCP servers and takes all the lessons learned over the last 18 months to provide a robust foundation for MCP’s future. The newly added extensions showcase the continuous innovation of the wider open source project. I am excited to see what people will do with the new capabilities of MCP.

This release is the clearest signal yet that MCP is becoming real production-grade infrastructure. The biggest changes are breaking ones, and the community has chosen to do the hard work rather than paper over the gaps. That tracks with what we see across the enterprises we work with: MCP has already become the default these teams are building on, and this release is exactly the maturation they’ve been waiting for. This is a protocol growing up in real time around what production teams actually need, and it’s a step forward for anyone building enterprise agents.

AWS and Anthropic are committed to supporting the MCP community and helping developers ship enterprise-grade agents at scale. With the new MCP specification and its stateless protocol core available in Amazon Bedrock AgentCore, developers can deploy MCP servers on standard, scalable infrastructure without managing sessions or persistent connections. Tasks, one of the first official MCP extensions and contributed by AWS, brings support for reliable, long-running agents, so developers can spend less time on infrastructure and more time innovating.

MCP 2026-07-28 is a major step toward making agent infrastructure work like the rest of the web: stateless, cacheable, routable, and globally scalable. Cloudflare’s Agents SDK supports the spec from day zero, so developers can run MCP servers directly in Workers, call tools without transport-session overhead, and enable richer flows like elicitation for approvals. Because MCP is an open standard, Cloudflare customers like Sentry and Linear can adopt it on day zero and immediately deliver these improvements to their users.

More builders are using our MCP server to bring generated outputs into Figma’s canvas, where they can explore, riff and refine them with their team into products that stand out. As that usage grows, our stateless architecture can scale with it, and with MCP Apps, Tasks, and Enterprise-Managed Authorization, we can do even more to keep design and code together in one, connected flow.

The 2026-07-28 Model Context Protocol release represents a massive leap forward in enterprise AI scalability. By evolving into a stateless architecture, this specification removes the friction of deploying agentic workflows at scale. At Google Cloud, we are excited to leverage these powerful new capabilities across our ecosystem of developer tools. This release provides the robust, secure, and extensible foundation that our customers (and our own teams) need to build the next generation of AI applications, and we are proud to continue shaping the future of this open standard together.

At honeycomb.io, we’ve seen fantastic adoption of MCP - nearly 20% of all monthly interactive queries are now made by agents! The new specification release allows us to support more advanced features such as elicitations while running at enterprise scale.

The new version of the MCP spec proves that the maintainers listen to feedback from the community. It solves real issues we faced at Manufact, both in mcp-use, our open-source framework, and on Manufact Cloud, where we host thousands of MCP servers. The new SDK v2, which powers mcp-use, helped us cut the package size by around 83% while making it 25% faster, thanks to the new client-server split. And with MCP going stateless, we are able to handle production traffic more reliably, securely, and at scale, without impractical infrastructure workarounds.

Open protocols create bigger ecosystems than any one company can build alone. MCP is foundational to Microsoft Foundry, enabling us to scale from dozens of integrations to thousands. We leverage it with Foundry toolbox unified MCP endpoint that brings together tools while centralizing governance, identity, and observability. With stateless operations, Tasks for long-running work, and enterprise-managed identity, the next generation of MCP makes it easier than ever to build secure, scalable, production-ready agent systems.

The stateless core in the 2026-07-28 spec makes MCP a first-class HTTP workload with no session management to work around. Our customers wanted MCPs on Netlify to be as simple as the rest of the platform and this new spec unlocks this at its core. Building MCP Apps into the new extensions framework is a huge step forward for scalability, accessibility, and capability across the whole ecosystem.

MCP is now about a year and a half old. Thanks to feedback from developers and others who have worked with us, it’s evolving into a more mature protocol that incorporates lessons from decades of web protocol design. As with prior revisions, the most interesting part will be seeing the unexpected things people build with it.

Moving MCP to a stateless protocol makes it easier to scale our own service and makes it easier for us to add analytics for our customers’ MCP servers. Making it easier to show people how their MCP tools are being used and what tools are missing that their users would want to use. It’s great to see this protocol growing in this direction.

This is a milestone release for anyone building MCP at scale. FastMCP has always existed to turn the spec’s most powerful capabilities into an obvious developer experience, and we’re excited to ship first-class support for background tasks, stateless interactivity, enterprise auth, and more in FastMCP 4.0. Horizon, our MCP governance platform, was built stateless from the start to handle enormous scale, so having that approach become native to the protocol is incredible to see.

This release makes MCP more enterprise-ready than ever. Runlayer is bringing these advances to every enterprise on our platform, providing a simpler, safer foundation for deploying MCP and agents across their organizations.

The latest MCP revision is an important milestone. It reflects a level of rigor and user input that shows the protocol is maturing in a way that allows businesses to build on it with confidence. We have implemented the revision and the move to a stateless model removes operational complexity and unlocks MCP at enterprise scale. It’s a strong signal that the community is being shaped by real deployment experience.

Supporting elicitations has been on our roadmap for a while, but since Supabase MCP runs statelessly, it wasn’t something we could do easily. MRTR changes that - it allows our tools to confirm with the user before it acts, like the cost of a new project before it’s created, or a query that would delete data. We’re excited to support elicitations.

Anthropic pairs frontier models with a developer experience that keeps raising the bar. The stateless core in the open MCP 2026-07-28 spec reduces the complexity we manage, so we can ship more features to our customers, faster and at scale.

Getting started

We’re excited to have developers build on the new spec. To get started, refer to the following resources:

• Specification
• Full changelog
• Documentation and guides

Thank you

This release would not be possible without a massive community of contributors and industry partners. We’d like to acknowledge the dozens of key contributors across specification, documentation, SDKs, working and interest groups, as well as hundreds of independent worldwide communities who rallied support and excitement for MCP. We’re looking forward to continuing evolving the protocol as it grows!

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!

The Enterprise-Managed Authorization (EMA) extension is now stable. We’ve heard from the community that authorization and repeated consent prompts from connected MCP servers is one of the biggest pain points when it comes to managing connectivity in enterprise environments. This extension helps address this.

EMA allows organizations to control MCP server access centrally through their trusted identity provider. For end-users, this means a zero-touch setup: the MCP servers they need are connected on first login, with no per-app OAuth and nothing to configure as a one-off.

Per-user auth is high friction

The standard MCP authorization model was designed to be user-scoped and bound to the traditional interactive auth conventions. While this might work well for more general consumer scenarios where individuals decide what touches their data, this doesn’t quite scale for enterprise deployments:

• Every employee has to authorize every server individually: onboarding means manually connecting service after service.
• Security teams cannot enforce consistent policy: access is whatever each user authorized, with no central control or audit trail.
• Work and personal accounts blur together: there’s no way to require a corporate identity, so a user can connect a personal account to a work tool.

This combination of factors slows MCP adoption and pushes people toward brittle workarounds. With no universal standard for preserving shared auth state, everyone invents their own bespoke solution. The data and tools are available, but the per-user authorization tax keeps most of them switched off.

Authorize once, inherit everywhere

Enterprise-Managed Authorization makes the organization’s IdP the authoritative decision-maker for MCP server access. Administrators define the policy once and users can authenticate with their existing identity into the MCP host. The IdP can grant or deny access based on group membership, role, and conditional access rules.

Under the hood, the client obtains an Identity Assertion JWT Authorization Grant (ID-JAG) from the IdP during single sign-on and exchanges it for an access token from the MCP server’s authorization server. The user is never redirected through a per-server consent screen. Three properties fall out of that flow:

• Authorize once, inherit everywhere: admins enable a server for the org. Users get it automatically, scoped to the groups and roles they already have.
• Centralized policy and audit: access decisions live in the IdP admin console, with one auditable trail across every connector.
• Removing personal/enterprise mixups: by removing the interactive account selection step, it’s much easier to prevent data flowing between personal and enterprise accounts by mistake or compromise.

We see this as a brand new baseline for MCP in the enterprise. When users log in, their client should be connected to the tools and data they’re authorized to use with no extra steps in between.

Early adopters

This launch brought together three groups that collaborated closely on making the implementation real:

• Identity providers: Okta is the first supported identity provider. Organizations using Okta can provision MCP access to supported servers through any supported client, using Okta’s Cross App Access (XAA).
• Clients: Anthropic has implemented the extension in its shared MCP layer for Claude. Admins can authorize MCP servers for users across Claude, Claude Code, and Cowork. Additionally, Visual Studio Code has also added support for EMA right in the IDE.
• Servers: Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase now support EMA, with Slack and more actively adding support.

We’re excited for more identity providers, clients, and servers to adopt Enterprise-Managed Auth to help reduce the authorization-related fatigue and significantly improve the security and observability posture for its implementers.

“The momentum around MCP is incredible, but as we move toward an interconnected AI workforce, security can’t be an afterthought. By embedding the Cross App Access protocol into MCP as the Enterprise-Managed Authorization extension, we turn identity into a centralized governance plane and give security teams strict compliance control and users a seamless, secure experience.”

— Aaron Parecki, Director of Identity Standards, Okta

“The Figma MCP brings the power of code and canvas together so teams can move faster, explore more and ship products that stand out. As MCP adoption grows, XAA makes it easier for enterprises to scale their MCP deployments securely without slowing teams down.”

— Devdatta Akhawe, VP of Engineering, Figma

“Logging in once and automatically having all your MCP connectors automatically setup is pretty magical.”

— Tom Moor, Head of Engineering, Linear

Get involved

As with all other MCP extensions, features, and enhancements, we welcome your input. We’re encouraging clients, servers, and identity platforms to review the extension specification and add support for the new standard into their products:

• Read the requirements: the Enterprise-Managed Authorization page documents the flow for clients, servers, and authorization servers.
• Source and spec: see the ext-auth repository and the specification for the latest in EMA evolution as well as any support materials that will help you get started.

If you’re interested in discussing the extension, sharing compatibility reports, or iterating on the extension, join the EMA Interest Group.

Acknowledgements

Enterprise-Managed Authorization is the work of the MCP community: the authors of SEP-990, the maintainers of the ext-auth repository, and the identity and MCP providers who tested early implementations and pushed the spec forward. Thank you to everyone who contributed.

• a stateless core that scales on ordinary HTTP infrastructure
• extensions including server-rendered UIs through MCP Apps and long-running work through the Tasks extension
• authorization that aligns more closely with OAuth and OpenID Connect deployments
• a formal deprecation policy so the protocol can evolve without breaking what you’ve built,

and many other changes.

The practical effect on a production deployment is immediate. A remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses for as long as the server’s ttlMs permits.

The release candidate is available today and the final specification ships on July 28, 2026. This release contains breaking changes; see Release Timeline and Validation for the details.

A Stateless Protocol

The headline change is that MCP is now stateless at the protocol layer. Six Specification Enhancement Proposals (SEPs) work together to get there, completing the plan we laid out in The Future of MCP Transports in December.

Before and after

In 2025-11-25, calling a tool over Streamable HTTP means establishing a session first:

POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

The server responds with an Mcp-Session-Id that every subsequent request must carry, pinning the client to whichever instance issued it:

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

In 2026-07-28, the same call is a single self-contained request that any server instance can handle:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

The handshake and session are gone

The initialize/initialized handshake is removed (SEP-2575). The protocol version, client info, and client capabilities that used to be exchanged once at connection time now travel in _meta on every request, and a new server/discover method lets clients fetch server capabilities when they need them up front.

The Mcp-Session-Id header and the protocol-level session that came with it are also removed (SEP-2567). With both gone, any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer.

Stateless protocol, stateful applications

Removing the protocol-level session does not mean your application has to be stateless. Servers that need to carry state across calls can do what HTTP APIs have always done: mint an explicit handle (a basket_id, a browser_id) from a tool and have the model pass it back as an ordinary argument on later calls.

In practice, we’ve found this pattern (the model threading an identifier from one tool call to the next) to be more than just a workable substitute for session state. It’s often a more powerful one. The model can compose handles across tools, reason about them, and hand them off between steps in ways that externally managed session state, hidden in transport metadata, never really allowed.

The protocol no longer manages that state for you, but it doesn’t prevent you from managing it yourself. The explicit-handle pattern simply makes the state visible to the model rather than hidden away.

Server-to-client requests, restructured

A stateless protocol still needs a way for servers to ask the client for something mid-call, such as an elicitation prompt. Two SEPs rebuild that flow so it works without a persistent connection.

Server-initiated requests may now only be issued while the server is actively processing a client request (SEP-2260). Earlier spec versions recommended this; it’s now required. A user is never prompted out of nowhere, and every elicitation traces back to something they (or their agent) started.

Multi Round-Trip Requests (SEP-2322) change how those prompts are delivered. Instead of holding a Server-Sent Events (SSE) stream open, the server returns an InputRequiredResult:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Delete 3 files?",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

The client gathers the answers and re-issues the original call with inputResponses and the echoed requestState. Any server instance can pick that retry up because everything it needs is in the payload.

Routable, cacheable, traceable

Three smaller changes make the resulting traffic easier to operate.

The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers (SEP-2243) so load balancers, gateways, and rate-limiters can route on the operation without inspecting the body. Servers reject requests where the headers and body disagree.

List and resource read results now carry ttlMs and cacheScope (SEP-2549), modeled on HTTP Cache-Control. Clients know exactly how long a tools/list response is fresh and whether it’s safe to share across users, and a long-lived SSE stream is no longer the only way to learn that a list changed.

W3C Trace Context propagation in _meta is now documented (SEP-414), locking down the traceparent, tracestate, and baggage key names so distributed traces correlate across SDKs and gateways. Several SDKs and tools were already doing this; with the key names fixed in the spec, a trace that starts in a host application can follow a tool call through the client SDK, the MCP server, and whatever the server calls downstream, and show up as a single span tree in an OpenTelemetry-compatible backend.

Extensions Become First-Class

Extensions existed in the 2025-11-25 release but had no formal process behind them. SEP-2133 adds that: extensions are identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, live in their own ext-* repositories with delegated maintainers, and version independently of the specification. A new Extensions Track in the SEP process gives them a path from experimental to official.

This release includes two official extensions.

MCP Apps: server-rendered user interfaces

MCP Apps (SEP-1865) lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs. The rendered UI talks back to the host over the same JSON-RPC base protocol used everywhere else in MCP, so every UI-initiated action goes through the same audit and consent path as a direct tool call.

Tasks graduates to an extension

Tasks shipped as an experimental core feature in 2025-11-25. Production use surfaced enough redesign that the right home for it is an extension rather than the specification.

The Tasks extension reshapes the lifecycle around the stateless model: a server can answer tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. Task creation is server-directed: the client advertises the extension and the server decides when a call should run as a task. tasks/list is removed because it can’t be scoped safely without sessions.

Anyone who shipped against the 2025-11-25 experimental Tasks API will need to migrate to the new lifecycle.

Authorization Hardening

Six SEPs harden the authorization specification to align more closely with how OAuth 2.0 and OpenID Connect are deployed in practice.

Clients must now validate the iss parameter on authorization responses per RFC 9207 (SEP-2468). This is a low-cost mitigation for a class of mix-up attack that is more prevalent in MCP’s single-client, many-server deployment pattern. In a future version, clients will be expected to reject responses that omit iss, so authorization servers should begin supplying it now if they don’t already.

Clients now declare their OpenID Connect application_type during Dynamic Client Registration (SEP-837), avoiding the common case where an authorization server defaults a desktop or CLI client to "web" and rejects its localhost redirect URI. Clients bind registered credentials to the issuing authorization server’s issuer and re-register when a resource migrates between authorization servers (SEP-2352). The spec also documents how to request refresh tokens from OpenID Connect-style authorization servers (SEP-2207), and clarifies scope accumulation during step-up (SEP-2350) and the .well-known discovery suffix (SEP-2351).

Roots, Sampling, and Logging Are Deprecated

Three core features are deprecated under the new feature lifecycle policy (SEP-2577):

These are annotation-only deprecations. The methods, types, and capability flags continue to work in this release and in every specification version published within a year of it, and removing any of them will require a separate SEP under the lifecycle policy.

Full JSON Schema 2020-12 for Tools

Tool inputSchema and outputSchema are lifted to full JSON Schema 2020-12 (SEP-2106). Input schemas keep the type: "object" root constraint but now allow composition (oneOf, anyOf, allOf), conditionals, and references ($ref, $defs). Output schemas are unrestricted, and structuredContent can now be any JSON value rather than only an object. Implementations must not auto-dereference external $ref URIs and should bound schema depth and validation time.

Separately, the error code for a missing resource changes from the MCP-custom -32002 to the JSON-RPC standard -32602 Invalid Params (SEP-2164). If your client matches on the literal -32002 value, update it.

How the Protocol Evolves From Here

This release contains breaking changes. We don’t intend for that to be the norm.

Three governance SEPs in this release are designed so that future revisions can evolve the protocol without breaking core capabilities. The feature lifecycle policy gives every feature an Active, Deprecated, and Removed lifecycle with at least twelve months between deprecation and the earliest possible removal. The Extensions framework means new capabilities can ship as opt-in extensions and stabilize there before, if ever, moving into the specification. And a Standards Track SEP can no longer reach Final status until a matching scenario lands in the conformance suite (SEP-2484), which is the same suite the new SDK tier system scores official SDKs against.

The stateless rework in this release is the kind of foundational change that needed a clean break. With it landed, and with deprecation windows and extensions as the standard tools going forward, our expectation is that implementers targeting 2026-07-28 will be able to adopt future revisions without rewriting their transport or lifecycle code.

Release Timeline and Validation

The release candidate is locked as of May 21, 2026. The final specification will be published on July 28, 2026. The ten-week window is for SDK maintainers and client implementers to validate the changes against real workloads; under the SDK tier system, Tier 1 SDKs are expected to ship support within this window.

The full release candidate is in the draft specification, and the changelog will list every change against 2025-11-25.

If you find a problem, open an issue in the specification repository. For implementation questions, the relevant Working Group channel in the contributor Discord is the fastest path to an answer.

Looking Ahead

This release gives MCP the foundation we expect it to grow on for a long time: a protocol that runs statelessly on commodity HTTP infrastructure, an extensions framework where capabilities like Tasks and MCP Apps can ship on their own timeline, and a lifecycle policy that lets implementers build on 2026-07-28 knowing what they ship will keep working.

Thank you to everyone who shaped these proposals through the Working Groups and a great deal of patient review. We’re looking forward to making this final with the community on July 28.

When we introduced the MCP governance model last summer, the goal was to make sure the protocol could keep growing without any one person becoming a bottleneck. That has held up well through two specification releases, the move to the Agentic AI Foundation (AAIF), and a steady increase in SEP volume, and these changes give the project the leadership capacity it needs for what comes next.

Welcoming Clare Liguori as Core Maintainer

I’m pleased to welcome Clare Liguori to the Core Maintainer team.

Clare is a Senior Principal Engineer at Amazon Web Services, where she works on agentic AI developer tooling. Her current focus is Kiro and the Strands Agents SDK, and over more than a decade at AWS she has also worked on AWS Proton, Amazon ECS, the AWS Code Suite, and several open source projects.

Clare has been bringing that depth of developer-tooling and agent-runtime experience directly into MCP’s design work, particularly the discussions around unsolicited tasks, the agent execution model, and the Triggers & Events working group. She knows firsthand what the protocol has to look like inside production agent runtimes serving large numbers of developers. As those proposals move through the SEP process over the coming year, that perspective will keep the spec grounded in what client implementers actually need. I’m glad to have her at the table.

Welcome, Clare!

Den Delimarsky Joins as Lead Maintainer

Den Delimarsky is stepping up from Core Maintainer to Lead Maintainer, joining me in that role.

Den is a Member of Technical Staff at Anthropic, where he works across the MCP ecosystem: the specification, the SDKs, governance, and the developer experience around all of it. Before Anthropic he was a Principal Product Engineer in Microsoft’s CoreAI division, and he brings a wealth of experience across developer tools, SDKs, and security tooling.

Den’s work is most visible in authorization and security. He co-authored the authorization specification, brought RFC 8707 Resource Indicators into the spec, and has continued to build on it through SEP-835, SEP-1024, and the SEP-2350 family of proposals, among others. He also led the 2025-11-25 specification release, co-leads the Security Interest Group, and built a contribution tracker that gives SDK and spec maintainers a birds-eye view of activity across the project’s repositories.

I’m glad to have Den as a partner in this role, and I’m looking forward to what we can do together for the protocol in the years ahead.

What’s Next

MCP continues to grow at a pace none of us could have predicted, and that growth wouldn’t be possible without the people who keep it moving every day: the SDK maintainers, the working group facilitators, and everyone who has authored or reviewed a SEP. Thank you.

With this team in place, I’m excited to keep working alongside the maintainer group to evolve the protocol and make sure MCP keeps pace with what the community needs from it. If you’d like to get involved, the governance docs explain how the project is organized, the Contributor Ladder shows how people grow into these roles, the roadmap shows where we’re headed, and our Discord is the best place to talk to the people working on it. Come build with us.

What Tool Annotations Are

Tool annotations shipped in the 2025-03-26 spec revision. The current ToolAnnotations interface looks like this:

interface ToolAnnotations {
  title?: string;
  readOnlyHint?: boolean; // default: false
  destructiveHint?: boolean; // default: true
  idempotentHint?: boolean; // default: false
  openWorldHint?: boolean; // default: true
}

Every property is a hint. The spec is explicit about this: annotations are not guaranteed to faithfully describe tool behavior, and clients must treat them as untrusted unless they come from a trusted server.

These four boolean hints give clients a basic risk vocabulary:

• readOnlyHint: Does the tool modify its environment?
• destructiveHint: If it does modify things, is the change destructive (as opposed to additive)?
• idempotentHint: Can you safely call it again with the same arguments?
• openWorldHint: Does the tool interact with an open world of external entities, or is its domain closed?

The first three hints mostly answer a preflight question: should the client ask for confirmation before calling this tool? openWorldHint is different. It’s about where the tool reaches and what its output might carry back, which matters after the call as much as before. It’s also the hint most sensitive to deployment context. “External” might mean anything outside a corporate network or anything beyond the local machine, depending on where the server runs. The safest posture is to treat anything a tool considers external as a potential source of untrusted content.

The defaults are deliberately cautious: a tool with no annotations is assumed to be non-read-only, potentially destructive, non-idempotent, and open-world. The spec assumes the worst until told otherwise. Making annotations optional kept the barrier to entry low for server authors, but it also means coverage is uneven. Many servers ship without them, and clients vary in how strictly they honor the pessimistic defaults. Closing that gap is part of what the current wave of SEPs is trying to do.

How We Got Here

The original proposal discussion surfaced a question that still shapes every annotation proposal today: what value do hints provide when they can’t be trusted? MCP co-creator Justin Spahr-Summers raised it directly during review:

I think the information itself, if it could be trusted, would be very useful, but I wonder how a client makes use of this flag knowing that it’s not trustable.

Basil Hosmer pushed the point further, arguing that clients should ignore annotations from untrusted servers entirely:

“Clients should ignore annotations from untrusted servers” applies to all annotations, even title — but especially the ones that describe operational properties.

The spec landed on a compromise: call everything a hint, require clients to treat hints as untrusted by default, and leave it to each client to decide how much weight to give them based on what it knows about the server.

The interface has stayed small since then, and that’s been intentional. title went in because it’s just a display name with no trust implications. taskHint was proposed as an annotation but landed as Tool.execution instead, on the grounds that execution metadata isn’t really a behavioral hint. Earlier takes on stateless, streaming, and async annotations and security annotations are worth knowing about too, since the same concerns show up again in the SEPs open today.

What’s Open Now

Five SEPs currently propose new annotations or closely related capabilities:

The trust and sensitivity work is co-authored by GitHub and OpenAI based on gaps they hit running MCP in production. A Tool Annotations Interest Group is forming to work through these alongside related proposals like tool resolution and preflight checks. Reviewing each one in isolation makes it easy to miss how a given annotation interacts with others, and it’s those interactions that determine how risky a tool actually is in a given session.

The Lethal Trifecta: Why Combinations Matter

Simon Willison’s lethal trifecta names three capabilities that, when combined, create the conditions for data theft: access to private data, exposure to untrusted content, and the ability to externally communicate. The attack is simple: LLMs follow instructions in content, and they can’t reliably tell a user’s instructions apart from ones an attacker embedded in a web page, email, or calendar event. If the agent has all three capabilities, an attacker who controls one piece of untrusted content can trick the model into reading private data and sending it out.

Researchers have demonstrated this using a malicious Google Calendar event description, an MCP calendar server, and a local code execution tool. The code execution tool is the linchpin in that chain — any agent with unrestrained shell access sits one injected instruction away from exfiltration, and that’s true whether the tool arrived via MCP or was built into the host. What MCP adds is the ease of assembling the chain: users routinely combine tools from several servers in one session, so the risk profile is a property of the session, not of any single server.

One commenter on Willison’s newsletter connected this directly to tool annotations:

If the current state is tainted, block (or require explicit human approval for) any action with exfiltration potential… This also makes MCP’s mix-and-match story extra risky unless tools carry metadata like: reads_private_data / sees_untrusted_content / can_exfiltrate — and the runtime enforces ’never allow all three in a single tainted execution path.'

Several of the open SEPs are trying to define that kind of metadata so a client can spot when a session has all three legs of the trifecta available.

What Annotations Can Do

Drive confirmation prompts. A tool marked readOnlyHint: true from a trusted server might be auto-approved, while destructiveHint: true gets a confirmation step. A user asks their agent to clean up old files, the agent reaches for delete_file, and the client shows a dialog listing what’s about to be deleted before anything happens. This is the most common use of annotations today.

Enable graduated trust. An enterprise running its own internal MCP servers behind auth has a very different trust relationship than someone installing a random server off the internet. Annotations from the first can drive policy; from the second they’re informational at best. In practice most clients still treat installation itself as the trust signal and don’t distinguish further, so this is more of a design opportunity than a widely shipped feature.

Improve UX. title is just a display name. Annotations that help users understand what tools do without running them are useful regardless of trust. This is largely unexploited today: no MCP client lets users filter tools by annotation values, and none surface annotations as context in approval prompts. GitHub’s read-only mode is the closest production analog, enabled by about 17% of users.

Feed policy engines. Annotations can be one input among several into a policy engine enforcing rules like “no destructive tools without approval” or “open-world tools are blocked in sessions that have accessed private data.” The hints don’t need to be perfectly trustworthy if the engine cross-references other signals.

Adoption across all of these is uneven, partly because MCP users split into two camps. Developers building autonomous agents treat confirmations as friction and lean on sandboxing instead. Enterprise adopters want more annotations than currently exist. One camp barely notices annotations, the other wants a much richer vocabulary.

What Annotations Can’t Do

They don’t make the model resist prompt injection. Annotations are static metadata on a tool definition; nothing in them tells the model to ignore malicious instructions it reads from a calendar event. What an annotation like seesUntrustedData could do is let the client treat the session as tainted once that tool runs and tighten approvals from then on — a defense at the host layer, not inside the model.

An untrusted server can lie. A server can claim readOnlyHint: true and delete your files anyway. This is why the spec says clients must treat annotations from untrusted servers as untrusted.

They aren’t enforcement. If you need a guarantee that a tool can’t exfiltrate data, that’s a job for network controls or sandboxing, not a boolean hint. We made the same point about server instructions: don’t rely on soft signals for things that need to be hard guarantees.

A tool’s risk depends on what else is in the session. search_emails isn’t safe or dangerous on its own; it depends on what other tools the agent has. Annotations on one tool can’t tell you that.

Questions for Evaluating New Annotations

As a starting point for the Interest Group, we’re putting forward a tentative set of questions to ask of each annotation proposal. These will likely change as the group works through the open SEPs.

1. What client behavior does it enable?

Maintainer Jonathan Hefner put this directly on an early draft of what became the governance/UX annotations proposal:

It’s not clear to me exactly how a client would behave differently when presented with these annotations.

If there’s no concrete client action that changes based on the annotation, it probably doesn’t belong in the protocol. Each of the existing hints maps to at least one decision a client can make:

2. Does it need trust to be useful?

title is useful even from an untrusted server; worst case you show a bad display name. readOnlyHint from an untrusted server isn’t actionable, because the decision it informs — whether to skip a confirmation — only makes sense if you believe the hint. Proposals should say where they fall on that spectrum, since it determines which clients can actually use them.

3. Could _meta handle it instead?

Tools already have _meta, which accepts namespaced keys like com.example/my-field for exactly this kind of metadata. If an annotation only matters to one deployment style where the same organization runs both the server and the client, _meta is a reasonable home for it. It’s also a good way to prove out an idea before writing a SEP: ship a namespaced field, see how it holds up in production, and come back with a proposal backed by actual usage instead of a design doc. What _meta can’t do is drive behavior in off-the-shelf clients — those won’t read a key they’ve never heard of, so anything aimed at ecosystem-wide UX still needs a real annotation.

4. Does it help reason about combinations?

Annotations that help a client understand what happens when tools are used together are worth more than ones that only describe a tool in isolation. openWorldHint already hints at this: a client could use it to notice that a session mixes closed-world data access tools with open-world communication tools.

5. Is it a hint or a contract?

Hints inform decisions; contracts enforce them. If a proposal’s value depends on the annotation being true, it’s asking for a contract, and the right place for that is the authorization layer, the transport, or the runtime rather than ToolAnnotations. Hints work best when they’re still useful even if some servers get them wrong.

Where This Is Heading

The Tool Annotations Interest Group includes participants from Microsoft, OpenAI, AWS, Cloudflare, and Anthropic, among others. These are companies that build both MCP hosts and MCP servers at scale, so they sit on both sides of the annotation contract: they need annotations expressive enough to surface risk to their users, and they need to author annotations that other clients will actually honor. Among the questions on the group’s agenda are whether annotations belong on tool responses as well as tool definitions, and whether any annotations should be evaluated at runtime rather than declared statically.

In the meantime, the existing annotations are worth using. If you’re writing a server, set readOnlyHint: true on read-only tools, destructiveHint: false on additive operations, and openWorldHint: false on closed-domain tools. If you’re writing a client, treat annotations from untrusted servers as informational and lean on them for UX, but keep your actual safety guarantees in deterministic controls. And if you’re thinking of proposing a new annotation, the questions above are a good place to start shaping it.

Get Involved

The Tool Annotations Interest Group is forming now. If you’re interested in contributing:

• Review the open SEPs linked above and leave feedback
• Join the conversation in #tool-annotations-ig on the MCP Contributors Discord

Acknowledgements

This post draws on discussions with the MCP community, particularly the contributors involved in the Tool Annotations Interest Group proposal, including Sam Morrow (GitHub), Robert Reichel (OpenAI), Den Delimarsky (Anthropic), Nick Cooper (OpenAI), Connor Peet (Microsoft), and Luca Chang (AWS).

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!

We proposed MCP Apps last November, building on the amazing work of MCP-UI and the OpenAI Apps SDK. We were excited to partner with both OpenAI and MCP-UI to create a shared open standard for providing affordances for developers to include UI components in their MCP clients.

Since then, the spec has been refined, the SDK has matured, and clients like ChatGPT, Claude, Goose and Visual Studio Code have shipped support for this capability, with more clients coming soon.

What Are MCP Apps?

MCP Apps let tools return rich, interactive interfaces instead of plain text. When a tool declares a UI resource, the host renders it in a sandboxed iframe, and users interact with it directly in the conversation.

Here are a few scenarios where MCP Apps shine:

• Data exploration: A sales analytics tool returns an interactive dashboard. Users filter by region, drill down into specific accounts, and export reports without leaving the conversation.
• Configuration wizards: A deployment tool presents a form with dependent fields. Selecting “production” reveals additional security options; selecting “staging” shows different defaults.
• Document review: A contract analysis tool displays the PDF inline with highlighted clauses. Users click to approve or flag sections, and the model sees their decisions in real time.
• Real-time monitoring: A server health tool shows live metrics that update as systems change. No need to re-run the tool to see current status.

These interactions would be less smooth as text exchanges, whereas MCP Apps make them natural - it’s like using any other UI-based web app.

How It Works

The architecture of MCP Apps relies on two key MCP primitives:

1. Tools with UI metadata: Tools include a _meta.ui.resourceUri field pointing to a UI resource
2. UI Resources: Server-side resources served via the ui:// scheme containing bundled HTML/JavaScript

// Tool with UI metadata
{
  name: "visualize_data",
  description: "Visualize data as an interactive chart",
  inputSchema: { /* ... */ },
  _meta: {
    ui: {
      resourceUri: "ui://charts/interactive"
    }
  }
}

The host fetches the resource, renders it in a sandboxed iframe, and enables bidirectional communication via JSON-RPC over postMessage.

Why MCP Apps?

MCP is great for connecting models to data and giving them the ability to take actions. But there’s still a context gap between what tools can do and what users can see.

Consider a tool that queries your database. It returns rows of data, maybe hundreds of them. The model can summarize this data, but users often want to explore: sort by a column, filter to a date range, or click into a specific record. With text responses, every interaction requires another prompt. “Show me just the ones from last week.” “Sort by revenue.” “What’s the detail on row 47?” It works, but it’s slow.

MCP Apps closes this gap. The model stays in the loop, seeing what users do and responding accordingly, but the UI handles what text can’t: live updates, native media viewers, persistent states, and direct manipulation. Combined, they provide the model and user with all the context they need in one familiar interface.

The App API

To build new MCP Apps, developers can use the @modelcontextprotocol/ext-apps package, which provides an App class for UI-to-host communication:

import { App } from "@modelcontextprotocol/ext-apps";

const app = new App();
await app.connect();

// Receive tool results from the host
app.ontoolresult = (result) => {
  renderChart(result.data);
};

// Call server tools from the UI
const response = await app.callServerTool({
  name: "fetch_details",
  arguments: { id: "123" },
});

// Update model context
await app.updateModelContext({
  content: [{ type: "text", text: "User selected option B" }],
});

Because apps run inside the client, they can do things a plain iframe can’t. They can log events for debugging, open links in the user’s browser, send follow-up messages to drive the conversation forward, or quietly update the model’s context for later. All of this happens over standard postMessage, so you’re not locked into any framework.

Security Model

Running UI from MCP servers means running code you didn’t write within your MCP host. MCP Apps handles this through multiple layers:

• Iframe sandboxing: All UI content runs in sandboxed iframes with restricted permissions
• Pre-declared templates: Hosts can review HTML content before rendering
• Auditable messages: All UI-to-host communication goes through loggable JSON-RPC
• User consent: Hosts can require explicit approval for UI-initiated tool calls

If something looks suspicious, hosts can block it before it ever renders. Of course, users should continue to proactively and thoroughly vet MCP servers before connecting them.

The Future of Agentic UI Frameworks

MCP-UI and OpenAI Apps SDK pioneered the patterns that MCP Apps now standardizes. The projects proved that UI resources can and do fit naturally within the MCP ecosystem, with enterprises of all sizes adopting both the OpenAI and MCP-UI SDKs for production applications.

MCP-UI isn’t going anywhere. The SDKs support MCP Apps patterns, with the Client SDK as the recommended framework for Hosts looking to adopt MCP Apps. The community continues to contribute extensively to the specification. If you’re already using MCP-UI, keep using it. Migration to the official extension is straightforward when you’re ready.

Client Support

MCP Apps are supported in:

• Claude - available today both on web and desktop experiences
• Goose - available today
• Visual Studio Code - available in Visual Studio Code Insiders
• ChatGPT - starting this week

For the first time, an MCP tool developer can ship an interactive experience that works across a broad range of widely-adopted clients without writing a single line of client-specific code.

“I am excited about the possibilities that MCP Apps opens up. Having seen a glimpse of what is possible, I cannot wait to see what the community will build.”

• David Soria Parra, Co-Creator of MCP and Member of Technical Staff, Anthropic

“MCP Apps builds upon the foundations of MCP-UI and the ChatGPT Apps SDK to give people a rich visually interactive experience. We’re proud to support this new open standard and look forward to seeing what developers build with it as we grow the selection of apps available in ChatGPT.”

• Nick Cooper, Member of Technical Staff, OpenAI

“MCP Apps extends the Model Context Protocol in a way that puts humans at the center. The industry has embedded assistants into individual apps, creating fragmented, siloed experiences. MCP inverts this by making apps pluggable components within agents. MCP Apps extends this further by bringing user interfaces into the agent experience itself.

goose, the reference implementation for MCP, supports MCP Apps. Developers can now build interactive experiences that render directly in conversation: games, calendars, maps, checkout flows. At Block, we believe the future centers on users navigating through one trusted agent rather than context-switching between fragmented experiences, and MCP Apps supports that vision. We’re excited to support this standard and see where developers take it.”

• Andrew Harvard, Design Engineer, Agentic UX, Block

“As MCP evolves from ‘tools’ into a real platform for agentic work, VS Code has been treating the protocol like a contract: implement the full spec, track the latest transports and capabilities, and make sure server authors can rely on what they build actually behaving the same way for real developers. With MCP Apps, that contract finally includes the missing human step: when the workflow needs a decision, a selection, or exploration, the client can give you the right interaction without turning the conversation into a choose-your-own-adventure prompt.”

• Harald Kirschner, Principal Product Manager, VS Code, Microsoft

“The MCP Apps extension addresses a gap we have experienced first-hand: text and structured data only gets you so far when developers want rich, interactive tooling. The ability to render dynamic UIs directly from MCP servers, with security built in from day one, is exactly what we need to build better agentic experiences. JetBrains is excited to explore bringing this extension to our IDEs and continue working with the MCP Community.”

• Denis Shiryaev, Head of AI DevTools Ecosystem, JetBrains

“MCP Apps address a real gap between what agentic tools can provide and how users naturally want to interact with them. The ability to render dynamic interfaces directly in conversation makes it easier to leverage MCP server capabilities in practical ways. We’re excited to see this extension deliver richer interactions for users while enabling MCP server developers to craft experiences tailored to what they’re building. We’re excited to see how we can bring these capabilities to Kiro and the use cases it’ll unlock for our users.“

• Clare Liguori, Senior Principal Engineer, AWS

“The Antigravity team is excited to see the continued expansion of the MCP ecosystem, and will explore how MCP apps could enable new, magical experiences within Antigravity.”

• Anshul Ramachandran, Product Lead, Antigravity, Google DeepMind

This is just the starting lineup, and adding support to a new client is as easy as following the implementation guide.

Get Started

The ext-apps repository includes the SDK and working examples: threejs-server for 3D visualization, map-server for interactive maps, pdf-server for document viewing, system-monitor-server for real-time dashboards, sheet-music-server for music notation, and many more.

Pick one close to what you’re building and start from there!

Resources

• Documentation: MCP Apps Guide
• Quickstart: Getting Started with MCP Apps
• SDK: @modelcontextprotocol/ext-apps
• Examples: ext-apps repository

Claude.ai Feedback

If you’re building MCP Apps for Claude.ai and encounter issues with our implementation, please report them at github.com/anthropics/claude-ai-mcp. This helps us improve the experience for everyone.

ChatGPT Apps SDK Feedback

If you’re building apps with the ChatGPT Apps SDK and run into issues or have questions, please post in the ChatGPT Apps category on the OpenAI Community forum. This is where app developers, community moderators, and the OpenAI team actively engage to discuss builds, troubleshoot problems, and improve the overall developer experience.

Acknowledgements

MCP Apps is the result of collaboration across multiple teams and communities.

Ido Salomon and Liad Yosef created MCP-UI and moderated the #ui-wg channel, incubating many of the patterns that MCP Apps now standardizes. Their work proved that interactive UIs belong in MCP.

Nick Cooper at OpenAI helped deliver the OpenAI Apps SDK, enabling everyone to go beyond text in their interactions with Large Language Models.

Sean Strong, Olivier Chafik, Anton Pidkuiko, and Jerome Swannack from Anthropic helped steer the initiative from proposal to production.

The UI Community Working Group provided feedback through countless discussions, reviewed drafts, tested early implementations, and pushed for the right trade-offs between flexibility and security.

Thank you to everyone who contributed. Now go build something.

To keep that momentum going, the Core Maintainer team is evolving as well.

Departing Core Maintainers

First, some news. Inna Harper and Basil Hosmer will be stepping away from the Core Maintainer team to focus on other projects.

Inna and Basil have been with MCP since its early days. They helped shape the protocol during some of its most critical moments, from key design decisions to designing and delivering our official SDKs as well as helping ship all major spec releases. Their fingerprints are all over what MCP is today.

Thank you both for your contributions and your dedication to the project. MCP is better because of you.

Welcoming New Maintainers

We’re thrilled to welcome three new Core Maintainers to the team. They’ve already been active in MCP discussions, reviewing Spec Enhancement Proposals (SEPs), and helping shape the direction of the protocol.

Peter Alexander

Peter Alexander is a Member of Technical Staff at Anthropic on the Model Context Protocol team.

Prior to Anthropic, Peter was a Senior Staff Software Engineer at Meta working in a variety of areas across product and infrastructure including virtual reality, video conferencing, and large-scale real-time publish/subscribe data infrastructure. He also spent some time in the gaming industry at Codemasters working on their Grid and DiRT series of games on console and PC as gameplay lead.

Peter has authored several SEPs including the Extensions framework and Resource Contents Metadata, and has been an active reviewer and contributor to our SDKs, proposals around governance, roadmap, and specification changes.

Caitie McCaffrey

Caitie McCaffrey is a Software Engineer and Tech Lead at Microsoft. Caitie has built large-scale distributed systems and services across multiple domains, including AI platforms, gaming, social media, and IoT.

Previously, Caitie served as Technical Advisor to Microsoft’s CEO Satya Nadella and CTO Kevin Scott, driving strategic efforts in AI transformation, developer experience & security. Earlier in her career, Caitie was Tech Lead for the Observability team at Twitter, and worked in the gaming industry at Microsoft Game Studios and 343 Industries, contributing to titles such as Halo 4, Halo 5, and Gears of War 2 & 3. She holds a Computer Science degree from Cornell University.

Caitie has been reviewing and helping us craft our governance and transport proposals, bringing her distributed systems expertise to protocol design discussions.

Kurtis Van Gent

Kurtis Van Gent is a Senior Staff Software Engineer leading AI Ecosystems at Google Cloud Databases. He drives ecosystems and integrations across the portfolio, leading efforts like MCP for Data Cloud and MCP Toolbox for Databases.

Kurtis has been driving the Transport Working Group, which authored the accepted request payload decoupling SEP and is leading the stateless protocol proposal. His focus on scalability and fault tolerance has shaped key discussions around how MCP evolves.

Welcome to the team, Peter, Caitie, and Kurtis.

Looking Ahead

If there is one thing I can guarantee it’s that 2026 will be a busy year for MCP. There are multiple active SEPs working through the process right now, including ones like the DPoP extension for authentication, multi-turn SSE for transport, and Server Cards for discovery. This is just a sneak peek of the many improvements we’re currently iterating on. The ecosystem keeps expanding, with more clients, servers, and SDK releases shipping every week.

MCP as a protocol has also matured. What started as an open-source experiment is now running in production at companies of all sizes. That changes what we need to focus on. With this team in place, we’re working on the pieces of the puzzle that matter for the next phase of MCP growth: hardening the spec for enterprise scenarios, improving security and authentication patterns, providing better SDK implementation guidance, and making sure MCP can scale to meet the demands of organizations deploying it in critical systems. At the same time, we’re keeping the contributor experience welcoming and the protocol responsive to what developers actually need.

If you want to be part of it, check out our governance docs or see how to get started with MCP contributions. Come build with us.

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.

But not only do we hit the first anniversary milestone today - we’re also releasing a brand-new MCP specification version. Before we get to the details of what’s new, let’s do a bit of a retrospective.

A Year In

With all the changes that we’ve made in the past year, it feels like a decade flew by. The protocol has grown leaps and bounds since its inception and has been adopted by a huge number of developers and organizations. We went from a little open source experiment to becoming the standard for connecting data and applications to Large Language Models (LLMs).

But adoption can only grow as long as there are MCP servers to actually use and clients which are capable of communicating with them. Within the same timeframe, we saw the number of active MCP servers go from just a few experimental ones to thousands. If you think about a scenario, it’s likely there’s an MCP server for it.

Here are just a few of many (very many) MCP servers that you can try today:

• Notion built an MCP server to help you manage your notes.
• Stripe has a pretty extensive MCP server to manage all kinds of payment workflows.
• GitHub built their own MCP server to help developers automate their engineering processes.
• Hugging Face created an MCP server to make model management and dataset search a breeze.
• Postman built their MCP server to help automate API testing workflows.

And there’s so much more to discover in the MCP ecosystem! That’s why we also launched the MCP Registry earlier this year. It’s the central index for all available MCP servers that now has close to two thousand entries since its announcement in September. That’s a 407% growth from the initial batch of servers we onboarded that same month.

The ecosystem is blooming, adoption is growing, but what’s underpinning all of this?

Community & Governance

MCP’s growth was never a one‑company effort. Students, hobbyists, startup engineers, and enterprise architects all shaped the protocol - submitting Specification Enhancement Proposals (SEPs), shipping SDKs in new languages, and stress‑testing some of the early assumptions we had about MCP in production. MCP servers became a staple of many products, official and unofficial (there’s even a Blender MCP server). That kind of organic adoption isn’t something you can just come up with, no matter how ambitious your aspirations are with an open source project.

From the start, we believed that it was all about the MCP community. Our community rallied around the protocol, organizing events like MCP Dev Summit, MCP Night, MCP Dev Days, and showing up at other marquee events like AI Engineer World’s Fair to share what they learned and built.

We also nurtured large contributor communities on Discord and on GitHub, helping us debug issues, build amazing tools like the MCP Inspector, propose changes, and assist each other in shipping great MCP experiences. That kind of daily collaboration got us further than any single individual or company ever could.

Really, the success of MCP in the past year is entirely thanks to the broad community that grew around the project - from transports, to security, SDKs, documentation, samples, extensions, and developer tooling, it was all significantly evolved by and for the community.

To keep this pace sustainable, we spent some time thinking through and putting together a governance structure. Through it, community leaders and Anthropic maintainers were and continue to work together to figure out what needs fixing and how to get the right changes into the spec. Our maintainer team isn’t there to gatekeep; they help surface problems, align on solutions, and turn rough ideas into actual protocol updates.

Our approach to governance, while still evolving, proved itself to be extremely valuable. We’ve been able to move faster on critical improvements without breaking existing implementations. Potential contributors now also know how to jump in through formal Working and Interest Groups (SEP-1302 set the stage for this).

Even though this is a significant improvement, we know that we’re not done. There’s still work ahead for us to make this process even better - improved transparency, decision timelines, broader platform coverage, and so much more to help the ecosystem. We are incredibly thankful for everyone who’s been part of this journey and helped us navigate so many changes in such a short time span.

What Others Have To Say

As we called out above, the success of MCP would not be possible without the broader community of adopters. We’re delighted that the protocol enabled so many scenarios across the industry. Here are some thoughts from a few of our key partners and supporters.

“In just one year, MCP has evolved from an experiment to a widely adopted industry standard, highlighting the impact of open collaboration—something we deeply believe in at GitHub. Developers across our community, customers and own teams are using our GitHub MCP Server, Registry, and enterprise controls like the MCP allowlist to unlock real benefits of agentic development in production workflows. We’re excited to keep building with the broader community to push this standard forward.”

✦ Mario Rodriguez, CPO, GitHub

“We believe open standards are an important part of an agentic web—helping models work with tools and platforms more seamlessly. OpenAI has been contributing to the MCP ecosystem since early on, and it’s now a key part of how we build at OpenAI, integrated across ChatGPT and our developer platform. We’re excited to keep working with the community to strengthen the protocol as it evolves.”

✦ Srinivas Narayanan, CTO of B2B Applications, OpenAI

“In the year since its launch, MCP has become an incredibly impactful open standard in the industry,” said Dhanji R. Prasanna, CTO of Block. “It has quickly moved to unlocking an enormous amount of value from existing systems and made applied AI real like few anticipated. MCP has been key to building AI-powered solutions like Square AI and Moneybot, saving our customers time and delivering powerful insights as well as our internal AI systems. It sits at the heart of open source projects like goose, proving that open standards fuel innovation across the board. We are excited to see the protocol and AI agents evolve to unlock ever more productivity in the enterprise.”

✦ Dhanji Prasanna, CTO, Block

“Having an open source protocol that unlocks real interoperability has made agents truly useful. In one year, Foundry went from a small set of tools to thousands because MCP let tools from GitHub, Azure, and M365 show up wherever agents run. It made write once integrate everywhere real and gives agents the ability to work across any system and any cloud with the full power of Microsoft behind them.”

✦ Asha Sharma, President, CoreAI, Microsoft

“MCP has become the natural language for AI integration - connecting everything from model discovery to inference APIs to chat applications. The community has created thousands of MCP applications with Gradio and our HF-MCP server. Having an Open Source protocol that unlocks this seamless interoperability has been a game changer in the past year.”

✦ Julien Chaumond, CTO, Hugging Face

“The enterprise promise of AI is being realized by MCP’s ability to unify data, tools, and workflows across previously siloed systems. As agentic AI is more rapidly adopted, we’re excited to see identity and authorization at the core of a security framework. By formally incorporating Cross App Access as an MCP authorization extension, organizations can have the necessary oversight and access control to build a secure and open AI ecosystem.”

✦ Harish Peri, SVP & GM, AI Security, Okta

“We’re hearing great things from customers who have embraced MCP as their standard for connecting generative AI agents with external systems. Open source is incredibly important to our mission at AWS, which is why we started and continue contributing to MCP— building improvements on authorization, human in the loop interactions, and asynchronous execution. We have also built MCP into offerings like Amazon Bedrock, Kiro, Strands, AgentCore and Amazon Quick Suite. We’re excited to continue to collaborate with this community to make agent interoperability seamless for developers.”

✦ Swami Sivasubramanian, VP, Agentic AI, AWS

“In just one year, the Model Context Protocol has proven to be a critical standard that connects models to data and applications, solving the fragmentation that held agents back. We’re proud to support MCP across Gemini, from our models to our agentic software development tools like Gemini CLI, as well as provide open source MCP servers such as for Google Maps and Google Cloud databases. These are the very tools our own teams use, and we’re thrilled to celebrate MCP’s first birthday by continuing to build this foundation together.”

✦ Anna Berenberg, Engineering Fellow, Google Cloud

“MCP has changed everything for us at Obot AI. A standard, open protocol for connecting AI with apps, data, and systems is the biggest shift since LLMs. We’re all-in on secure MCP management because we believe it’s going to be foundational infrastructure for every organization”

✦ Shannon Williams, President and Co-Founder, Obot AI; Organizer, MCP Dev Summit

Of course, we would be remiss not to mention the massive effort it takes to coordinate the MCP community engagement. We asked some of our most prolific community managers about what MCP meant to them. Here are their stories.

“As a community moderator and maintainer, I keep coming back to something Donella Meadows wrote: “Systems can’t be controlled, but they can be designed and redesigned… We can listen to what the system tells us, and discover how its properties and our values can work together to bring forth something much better than could ever be produced by our will alone.”

What made this year’s growth possible was embracing messiness as a feature, and doing our best to solve real problems emerging from that messiness while leaving room for systems and models to advance and adapt. The looseness created velocity, which I watched unfold in a flood of discussions, PRs, and issues.

As someone who’s merged hundreds of pull requests across MCP repos, I still feel like I’m barely keeping up with this velocity. I mean that in the most positive way. Better patterns and practices are emerging from the sheer volume of contributions and breadth of experience and expertise represented in the contributor community. As a random person from the Internet, I appreciate that pretty much anyone can bring something to the table. This includes standout maintainers like Cliff Hall, who raises the bar for reviewing, testing, and giving feedback, and Jonathan Hefner, who’s done the same for documentation.

As Darren Shepard recently put it:

‘People think the value of MCP is the protocol. The value is getting people to agree and do something.’

MCP gives people a reason to coordinate and talk about the same thing. Helping to enable that coordination and discussion has been a lot of fun, and it keeps me coming back.”

✦ Ola Hungerford, Principal Engineer, Nordstrom; MCP Maintainer and Community Lead

“Watching the MCP community start small and grow up across the past year has been a joy to watch. No matter whether someone has been an independent contributor, member of a small startup, or a leader at a big enterprise: everyone has had and continues to have a voice and a role to play.

I think this is largely due to how pragmatic and use-case oriented the MCP community has been from the get-go. There is a focus on not overcomplicating the specification, and not designing ahead of need. When that’s the ethos driving decision-making, everyone’s voice matters. The hobbyist that has something working in production might have a practical opinion to contribute, that the big tech engineer can pick up and confidently deploy to a large userbase. And vice-versa: big tech can foresee problems around critical issues like security and governance that the hobbyist might have missed designing for.

That ethos has translated to community governance, too. There’s no layers of bureaucracy: just a lightweight and still-distributed structure for making decisions that keep us all marching to the beat of the same drum. We are now 58 maintainers supporting the 9 core/lead maintainers in the MCP steering group, with 2,900+ contributors in the MCP contributor community on Discord, and 100+ new contributors joining every week. We’re successfully maintaining long-running projects like the Registry, the Inspector, and a host of SDKs with that distributed group of leaders and contributors - and managed to collaborate through 17 (!) SEPs in about a quarter’s worth of time.

That doesn’t even begin to touch on the thousands of MCP implementors or millions of MCP end-users. It’s inspiring to see the often-competitive AI community rally around a foundational piece of infrastructure; I’m thankful for that willingness to collaborate and look forward to seeing where our second year takes us.”

✦ Tadas Antanavicius, Co-Creator, PulseMCP; MCP Maintainer and Community Lead

We are immensely grateful for our partners and community for helping us bring the protocol to where it is today. Let’s now jump into the latest big release - the 2025-11-25 version of the MCP specification.

The November 2025 Release

The latest release of the MCP specification ships with a number of highly-anticipated features that came directly from our community deploying and using MCP for production scenarios. People told us what wasn’t working, what was missing, and what papercuts prevented them from being able to use MCP. We listened and worked together with community experts to deliver a number of enhancements that make MCP even more scalable and reliable.

Support for Task-based Workflows

SEP: 1686

Tasks provide a new abstraction in MCP for tracking the work being performed by an MCP server. Any request can be augmented with a task that allows the client to query its status and retrieve its results up to a server-defined duration after the task is created.

Tasks support a variety of states including working, input_required, completed, failed, and cancelled, allowing clients to effectively manage multi-step operations.

Some noteworthy capabilities that this feature enables:

• Active polling: Clients can check the status of ongoing work at any time.
• Result retrieval: Results of completed tasks are accessible after the request has completed.
• Flexible lifecycle management: Support for working, input_required, completed, failed, and cancelled states.
• Task isolation: Proper security boundaries with session-based access control.

From the multitude of MCP servers that we’ve seen out there, this is particularly helpful for scenarios such as the ones below.

• Healthcare & life sciences data analysis that processes hundreds of thousands of data points
• Enterprise automation platforms with complex multi-step workflows
• Code migration tools that run for minutes or hours
• Test execution platforms that need to stream logs from long-running suites
• Deep research tools that spawn multiple agents internally
• Multi-agent systems where agents can work concurrently

Tasks are launching as an experimental capability, meaning that it’s part of the core protocol but it’s not yet finalized. Task-based workflows are a tough problem to solve at scale, so we want to give some time to the specification to be battle-tested in real-world scenarios. We’ll work closely with the community, SDK developers, as well as client and server implementers to get this right.

Simplified Authorization Flows

One of the top painpoints from the community when it comes to authorization has been Dynamic Client Registration, or DCR. This capability is needed because in the MCP world there is an unbounded number of clients and servers, so doing standard client pre-registration is not always feasible. You wouldn’t expect every MCP client in the world to also have a client registration with every Authorization Server (AS) out there, so DCR was used as a solution to this problem. You can learn more about the current approach in our authorization guide.

To use DCR, however, an MCP server developer would need to rely on an AS that allows clients to register themselves via a public API. If the AS doesn’t support this capability, developers would now need to build an OAuth proxy that would be manually registered with the AS, and support Dynamic Client Registration itself, mapping its own issued tokens to tokens issued from the downstream AS. This is a complex, time-consuming, and error-prone task, and doesn’t actually solve the fundamental problems with Dynamic Client Registration.

The alternative would be for every customer or end user to provide their own client registration, but that’s just trading one complex task for another. In that model, when a user connects to an MCP server, they need to go through their IT team to create a registration, assign it the right permissions, and then configure the MCP client to use it.

SEP-991 introduced a much more elegant solution to the problem - URL-based client registration using OAuth Client ID Metadata Documents (you might’ve already seen our blog post on this change from earlier this year). Clients can now provide their own client ID that is a URL pointing to a JSON document the client manages that describes properties of the client.

You can learn more in the Client ID Metadata Documents Flow section of the MCP authorization specification.

Security and Enterprise Features

As the protocol matures, we also can’t ignore the myriad of security and authentication/authorization needs. MCP is not just a hobby protocol - we’ve seen it adopted in some of the most mission-critical workloads. This translates into a direct need to ensure that all data is protected and access is properly managed.

Working with security and authentication experts from across the community, we’ve developed a number of enhancements shipping with this release:

• SEP-1024: Client security requirements for local server installation
• SEP-835: Default scopes definition in authorization specification

We also hear loud and clear from the industry that discovery and management of internal registries is an important component to the MCP story. With the help of the MCP Registry team, we’ve also established a vision for the ecosystem that will help enterprises adopt their own MCP registries, with self-managed governance controls and security coverage.

To learn more about other upcoming auth and security improvements you can follow the auth and security tags in the specification repository.

Extensions

As MCP continues to evolve, we constantly hear from developers who want to extend the protocol with specialized capabilities, whether for UI interactions, custom authentication flows, or other environment-specific logic. While these additions could be valuable, incorporating them directly into the core specification isn’t always practical from the get-go, especially when a feature hasn’t yet achieved broad adoption or proven its universal applicability.

To address this, we’re introducing extensions in the protocol. Extensions are components and conventions that operate outside the core specification, providing a flexible way to build scenario-specific additions that follow MCP conventions without requiring full protocol integration. This approach allows for experimentation and specialized use cases while keeping the core protocol focused and stable. With extensions, we can move faster and enable developers to test out protocol capabilities before they become part of the specification.

Extensions are:

• Optional. Server and client implementors can choose to adopt these extensions.
• Additive. Extensions do not modify or break core protocol functionality; they add new capabilities while preserving core protocol behavior.
• Composable. Extensions are modular and designed to work together without conflicts, allowing implementations to adopt multiple extensions simultaneously.
• Versioned independently. Extensions follow the core MCP versioning cycle but may adopt independent versioning as needed.

You might’ve already seen our announcement of the MCP Apps Extension proposal. In this specification release, we’re introducing a couple of other extensions that should help developers further.

Authorization Extensions

To make MCP better suited for environments that require specific levels of control over the authorization process, we’ve officially introduced the concept of authorization extensions (building on the broader MCP Extensions). As with all other extensions, authorization extensions build on the core protocol and define additional authorization mechanisms that can be implemented by both server and client developers.

The first two authorization extensions came on the heels of community feedback regarding some of the most-used authorization flows:

• SEP-1046: OAuth client credentials support for machine-to-machine authorization
• SEP-990: Enterprise IdP policy controls for MCP OAuth flows (Cross App Access). This enables users within an enterprise to sign in to the MCP client once, and immediately get access to every authorized MCP server without additional authorization prompts.

As we engage closer with the community, we expect the number of authorization extensions to grow as well - after all, there are more than just a few ways for a system to acquire and manage credentials.

URL Mode Elicitation: Secure Out-of-Band Interactions

SEP: 1036

Asking users for their API keys, tokens, or any other credentials directly through the MCP client might seem like quite a scary proposition. This is especially critical when you need to connect an MCP server to an array of other APIs, where the traditional client-to-server authorization flow doesn’t quite work. Until now, there wasn’t a good alternative - you either had to trust the client to handle the user’s credentials directly, or implement a bunch of custom authorization logic to be used from the start.

URL mode elicitation lets you send users to a proper OAuth flow (or any credential acquisition flow, for that matter) in their browser, where they can authenticate securely without your client ever seeing the entered credentials. The credentials are then directly managed by the server and the client only needs to worry about its own authorization flow to the server.

We are excited about including this feature in addition to capabilities that we already have, like elicitations, because it allows the protocol to be used for a few scenarios that were quite hard to get right, such as:

• Secure credential collection: API keys and passwords never transit through the MCP client
• External OAuth flows: MCP servers have a path to obtain third-party authorization without token passthrough
• Payment processing: PCI-compliant financial transactions with secure browser contexts can now be done outside the client

All the server does is send a URL that the client will provide an affordance for. When the user completes the flow in their browser, the server will get the necessary tokens directly, avoiding sharing credentials with the client or other manual steps. Simple!

Sampling with Tools: Agentic Servers

SEP: 1577

This functionality allows MCP servers to run their own agentic loops using the client’s tokens (still under the user’s control, of course), and reduces the complexity of client implementations, context support becoming explicitly optional. This came from the fact that sampling doesn’t support tool calling, although it’s a cornerstone of modern agentic behaviour. With the new spec release, this is no longer a gap!

Now that sampling with tools is available, this also means that all of the scenarios below are possible!

• Tool calling in sampling requests: Servers can now include tool definitions and specify tool choice behavior
• Server-side agent loops: Servers can implement sophisticated multi-step reasoning
• Parallel tool calls: Support for concurrent tool execution
• Better context control: The ambiguous includeContext parameter is being soft-deprecated in favor of explicit capability declarations

As an example, a research server can spawn multiple agents internally, coordinate their work, and deliver a coherent result while using nothing other than standard MCP primitives without custom scaffolding or complex orchestration code.

Developer Experience Improvements

One of the core tenets of MCP is simplicity - we want to make the developer and integration experience as intuitive and easy as possible. To help achieve this, the latest spec release also adds a few minor changes that help make the protocol easier to use for developers.

• SEP-986: Standardized format for tool names
• SEP-1319: Decoupled request payload from RPC methods definition
• SEP-1699: SSE polling via server-side disconnect for better connection management
• SEP-1309: Improved specification version management for SDKs

Looking Forward

This release is backward compatible. Your existing implementations keep working. The new features are there when you need them.

Looking ahead, we’re excited about what’s coming next for MCP. The protocol is entering a new phase, one where it’s not just about connecting LLMs to data, but about enabling entirely new categories of AI-powered applications.

We’re seeing early signals of this transformation already. Developers are building multi-agent systems that coordinate across dozens of MCP servers. Enterprise teams are deploying MCP at scale with sophisticated security and governance controls. Startups are launching products where MCP is the core architectural pattern. MCP servers are even being transformed into executable code, to create sandboxed agent workflows.

The roadmap ahead includes deeper work on reliability and observability, making it easier to debug and monitor complex MCP deployments. We’re exploring better patterns for server composition, allowing you to build sophisticated capabilities by combining simpler building blocks. And we’re continuing to refine the security model to meet the needs of the most demanding enterprise environments.

What excites us most isn’t what we’re planning to build but what our community is going to build. Every week we see MCP servers designed, developed, and deployed in novel ways. Every conversation in Discord reveals new use cases and patterns. The protocol has become a canvas for AI innovation, and we can’t fill it alone.

The next year of MCP will be shaped by more production deployments, more real-world feedback, amplified by the creativity of thousands of developers worldwide. We’re here to support that growth, to ensure the protocol evolves thoughtfully, and to keep MCP stable, secure, and simple as it scales.

Get Started

To get started with all the new goodness in the latest MCP specification release, check out the following resources:

• Read the changelog: All major changes are captured in our Key Changes document
• Get to know our docs: The MCP documentation is the source of truth for the all the inner workings of the protocol
• Join the discussion: If you would like to contribute or engage with other MCP maintainers, start with our GitHub repo and Discord

This extension addresses one of the most requested features from the MCP community and builds on proven work from MCP-UI and OpenAI Apps SDK - the ability for MCP servers to deliver interactive user interfaces to hosts.

MCP Apps Extension introduces a standardized pattern for declaring UI resources, linking them to tools, and enabling bidirectional communication between embedded interfaces and the host application.

The SEP was authored by MCP Core Maintainers at OpenAI and Anthropic, together with the MCP-UI creators and lead maintainers of the MCP UI Community Working Group.

Standardization for interactive interfaces

Currently, MCP servers are limited to exchanging text and structured data with hosts. While this works well for many use cases, it creates friction when tools need to present visual information or gather complex user input.

For example, consider a data visualization MCP server that returns chart data as JSON. The host application must interpret that data and render it. Handling all kinds of specialized data in this scenario translates to a significant burden for client developers, who would need to build their own logic to render the UI. As more UI requirements come up, like the need to collect multiple related settings from users, the complexity balloons. Alternatively, without UI support, these interactions become awkward exchanges of text prompts and responses.

The MCP community has been creative in working around these limitations, but different implementations using varying conventions and architectures make it harder for servers to work consistently across clients. This lack of standardization creates a real risk of ecosystem fragmentation - something we’re working to proactively prevent.

Building together

The MCP-UI project, created by Ido Salomon and Liad Yosef and maintained by a dedicated community, spearheaded the vision of agentic apps with interactive interfaces. The project developed patterns for delivering rich user interfaces as first-class MCP resources, proving that agentic apps fit naturally within the MCP architecture. The project is backed by a large community and provides rich SDKs, adopted at leading companies and projects such as Postman, Shopify, Hugging Face, Goose, and ElevenLabs.

The OpenAI Apps SDK further validated the demand for rich UI experiences within conversational AI interfaces. The SDK enables developers to build rich, interactive applications inside ChatGPT using MCP as its backbone. To ensure interoperability and establish consistent security and usage patterns across the ecosystem, Anthropic, OpenAI, and MCP-UI are collaborating to create an official MCP extension for interactive interfaces.

MCP Apps Extension specification

We’re proposing a specification for UI resources in MCP, but the implications go further than just a set of schema changes. The MCP Apps Extension is starting to look like an agentic app runtime: a foundation for novel interactions between AI models, users, and applications. The proposal is intentionally lean, starting with core patterns that we plan on expanding over time.

Key design decisions

Pre-declared resources

UI templates are resources with the ui:// URI scheme, referenced in tool metadata.

// Server registers UI resource
{
  uri: "ui://charts/bar-chart",
  name: "Bar Chart Viewer",
  mimeType: "text/html+mcp"
}

// Tool references it in metadata
{
  name: "visualize_data_as_bar_chart",
  description: "Plots some data as a bar chart",
  inputSchema: {
    type: "object",
    properties: {
      series: { type: "array", items: .... }
    }
  },
  _meta: {
    "ui/resourceUri": "ui://charts/bar-chart",
  }
}

This approach enables hosts to prefetch and review templates before tool execution, improving both performance and security. It also separates static presentation (the template) from dynamic data (tool results), enabling better caching.

MCP transport for communication

Instead of inventing a custom message protocol, UI components communicate with hosts using existing MCP JSON-RPC base protocol over postMessage. This means that:

• UI developers can use the standard @modelcontextprotocol/sdk to build their applications
• All communication is structured and auditable
• Future MCP features automatically work with the UI extension

Starting with HTML

The initial extension specification supports only text/html content, rendered in sandboxed iframes. This provides:

• Universal browser support
• Well-understood security model
• Screenshot and preview generation capabilities
• A clear baseline for future extensions

Other content types such as external URLs, remote DOM, and native widgets are explicitly deferred to future iterations.

Security-first

Hosting interactive content from MCP servers requires careful security consideration. The proposal addresses this through multiple layers:

1. Iframe sandboxing: All UI content runs in sandboxed iframes with restricted permissions
2. Predeclared templates: Hosts can review HTML content before rendering
3. Auditable messages: All UI-to-host communication goes through loggable JSON-RPC
4. User consent: Hosts can require explicit approval for UI-initiated tool calls

These mitigations create defense in depth against malicious servers while preserving the flexibility developers need.

Backward compatibility

MCP Apps is an optional extension. Existing implementations continue working without changes, and hosts can gradually adopt UI support at their own pace. Servers should provide text-only fallback for all UI-enabled tools and return meaningful content even when UI is unavailable, so they can serve both UI-capable and text-only hosts.

What’s next

The UI Community Working Group has been instrumental in shaping this proposal through extensive feedback and discussion. We have built an early access SDK to demonstrate the patterns and types described in the specification proposal. The MCP-UI client and server SDKs support these patterns.

If you are interested in contributing to this effort, we invite you to:

• Review the full specification in SEP-1865
• Share feedback and concerns in GitHub Issues
• Join the discussion in the #ui-wg channel in the MCP Contributors Discord
• Test prototype implementations and share your experience

Acknowledgements

This proposal wouldn’t exist without the work of the maintainers at MCP-UI, OpenAI, and Anthropic.

Ido Salomon and Liad Yosef, through MCP-UI and moderation of #ui-wg, incubated and championed many of the patterns that MCP Apps now standardizes, and together with contributors demonstrated that UI resources can be a natural part of MCP.

Sean Strong, Olivier Chafik, Anton Pidkuiko, and Jerome Swannack from Anthropic helped steer the initiative and drive the collaboration.

Nick Cooper, Alexei Christakis, and Bryan Ashley from OpenAI have provided valuable direction from their experience building the Apps SDK.

Special thanks to the UI Community Working Group members and everyone who contributed to the discussions that shaped this proposal.

What are MCP Bundles?

MCP Bundles are ZIP archives containing a local MCP server and a manifest.json that describes the server and its capabilities. The format is similar to Chrome extensions (.crx) or VS Code extensions (.vsix), enabling end users to install local MCP servers with a single click.

A basic bundle structure looks like:

bundle.mcpb (ZIP file)
├── manifest.json      # Required: Bundle metadata and configuration
├── server/            # Server implementation
│   └── index.js
├── node_modules/      # Bundled dependencies
└── icon.png           # Optional: Bundle icon

The format supports servers written in Node.js, Python, or compiled binaries, giving developers flexibility in how they build their integrations, while maintaining a consistent distribution mechanism for users.

Why move MCPB to the MCP project?

Anthropic originally developed MCPB (previously called DXT) for Claude’s desktop applications. However, we believe the local MCP server ecosystem benefits when portability extends beyond any single client. By moving the bundle specification, CLI tooling, and reference implementation to the MCP project, we’re enabling:

• Cross-client compatibility: A bundle created for one MCP-compatible application should work in any other that implements the specification. Developers can distribute their work once and reach users across the ecosystem.
• Ecosystem-wide tooling: The mcpb CLI and associated libraries are now open for the community to extend, improve, and build upon. Client developers can adopt standardized code for loading and verifying bundles.
• User-friendly installation: End users benefit from a consistent installation experience regardless of which AI application they prefer. Configuration variables, permissions, and updates can be handled uniformly.
• Shared community: MCPB contributors can now collaborate in the open with the rest of the MCP community.

What this means for developers

This transition is mostly a logistical change, but also brings some benefits to implementers. For those that are building:

• Servers: You can use MCPB to package your local MCP servers for distribution across multiple clients. The mcpb CLI helps you create a manifest.json and package your server into a .mcpb file. Once packaged, users can install your server with a single click in any client that supports MCP Bundles.
• Clients: You can add support for MCP Bundles to your application using the open source toolchain. The repository includes the schemas and key functions used by Claude for macOS and Windows to implement bundle support, which you can adapt for your own client.

Getting started

Check out the repo to get started: modelcontextprotocol/mcpb. We encourage feedback and contributions!

Acknowledgements

Thanks to the MCP contributors and maintainers involved in making this happen, including:

• David Soria Parra (MCP Lead Maintainer)
• Adam Jones (MCP Maintainer)
• Joan Xie (MCPB Maintainer)
• Felix Rieseberg (MCPB Maintainer)
• Alex Sklar (MCPB Maintainer)

The Problem

Imagine you’re a Large Language Model (LLM) who just got handed a collection of tools from a database server, a file system server, and a notification server to complete a task. They might have already been carefully pre-selected or they might be more like what my workbench looks like in my garage - a mishmash of recently-used tools.

Now let’s say that the developer of the database server has pre-existing knowledge or preferences about how to best use their tools, as well as more background information about the underlying systems that power them.

Some examples could include:

• “Always use validate_schema → create_backup → migrate_schema for safe database migrations”
• “When using the export_data tool, the file system server’s write_file tool is required for storing local copies”
• “Database connection tools are rate limited to 10 requests per minute”
• “If create_backup fails, check if the notification server is connected before attempting to send alerts”
• “Only use request_preferences to ask the user for settings if elicitation is supported. Otherwise, fall back to using default configuration”

So now our question becomes: what’s the most effective way to share this contextual knowledge?

Solutions

One solution could be to include extra information in every tool description or prompt provided by the server. Going back to the physical tool analogy, however: you can only depend on “labeling” each tool if there is enough space to describe them. A model’s context window is limited - there’s only so much information you can fit into that space. Even if all those labels can fit within your model’s context window, the more tokens you cram into that space, the more challenging it becomes for models to follow them all.

Alternatively, relying on prompts to give common instructions means that:

• The prompt always needs to be selected by the user, and
• The instructions are more likely to get lost in the shuffle of other messages.

It’s like having a pile of notes on my garage workbench, each trying to explain how different tools relate to each other. While you might find the right combination of notes, you’d rather have a single, clear manual that explains how everything works together.

Similarly, for global instructions that you want the LLM to follow, it’s best to inject them into the model’s system prompt instead of including them in multiple tool descriptions or standalone prompts.

This is where server instructions come in. Server instructions give the server a way to inject information that the LLM should always read in order to understand how to use the server - independent of individual prompts, tools, or messages.

A Note on Implementation Variability

Because server instructions may be injected into the system prompt, they should be written with caution and diligence. No instructions are better than poorly written instructions.

Additionally, the exact way that the MCP host uses server instructions is up to the implementer, so it’s not always guaranteed that they will be injected into the system prompt. It’s always recommended to evaluate a client’s behavior with your server and its tools before relying on this functionality.

We will get deeper into both of these considerations with concrete examples.

Real-World Example: Optimizing GitHub PR Reviews

I tested server instructions using the official GitHub MCP server to see if they could improve how models handle complex workflows. Even with advanced features like toolsets, models may struggle to consistently follow optimal multi-step patterns without explicit guidance.

The Problem: Detailed Pull Request Reviews

One common use case where I thought instructions could be helpful is when asking an LLM to “Review pull request #123.” Without more guidance, a model might decide to over-simplify and use the create_and_submit_pull_request_review tool to add all review feedback in a single comment. This isn’t as helpful as leaving multiple inline comments for a detailed code review.

The Solution: Workflow-Aware Instructions

One solution I tested with the GitHub MCP server is to add instructions based on enabled toolsets. My hypothesis was that this would improve the consistency of workflows across models while still ensuring that I was only loading relevant instructions for the tools I wanted to use. Here is an example of what I added if the pull_requests toolset is enabled:

func GenerateInstructions(enabledToolsets []string) string {
    var instructions []string

    // Universal context management - always present
    baseInstruction := "GitHub API responses can overflow context windows. Strategy: 1) Always prefer 'search_*' tools over 'list_*' tools when possible, 2) Process large datasets in batches of 5-10 items, 3) For summarization tasks, fetch minimal data first, then drill down into specifics."

    // Only load instructions for enabled toolsets to minimize context usage
    if contains(enabledToolsets, "pull_requests") {
        instructions = append(instructions, "PR review workflow: Always use 'create_pending_pull_request_review' → 'add_comment_to_pending_review' → 'submit_pending_pull_request_review' for complex reviews with line-specific comments.")
    }

    return strings.Join(append([]string{baseInstruction}, instructions...), " ")
}

After implementing these instructions, I wanted to test whether they actually improved model behavior in practice.

Measuring Effectiveness: Quantitative Results

To validate the impact of server instructions, I ran a simple controlled evaluation in Visual Studio Code comparing model behavior with and without the PR review workflow instruction. Using 40 GitHub PR review sessions on the same set of code changes, I measured whether models followed the optimal three-step workflow.

I used the following tool usage pattern to differentiate between successful and unsuccessful reviews:

• Success: create_pending_pull_request_review → add_comment_to_pending_review → submit_pending_pull_request_review
• Failure: Single-step create_and_submit_pull_request_review OR no review tools used. (Sometimes the model decided just to summarize feedback but didn’t leave any comments on the PR.)

You can find more setup details and raw data from this evaluation in my sample MCP Server Instructions repo.

For this sample of chat sessions, I got the following results:

These results suggest that while some models naturally gravitate toward optimal patterns, others benefit significantly from explicit guidance. This variability makes server instructions particularly valuable for ensuring consistent behavior across different models and client implementations.

You can check out the latest server instructions in the GitHub MCP server repo, which now includes this PR workflow as well as other hints for effective tool usage.

Implementing Server Instructions: General Tips For Server Developers

One key to good instructions is focusing on what tools and resources don’t convey:

1. Capture cross-feature relationships:

   {
     "instructions": "Always call 'authenticate' before any 'fetch_*' tools. The 'cache_clear' tool invalidates all 'fetch_*' results."
   }
   

2. Document operational patterns:

   {
     "instructions": "For best performance: 1) Use 'batch_fetch' for multiple items, 2) Check 'rate_limit_status' before bulk operations, 3) Results are cached for 5 minutes."
   }
   

3. Specify constraints and limitations:

   {
     "instructions": "File operations limited to workspace directory. Binary files over 10MB will be rejected. Rate limit: 100 requests/minute across all tools."
   }
   

4. Write model-agnostic instructions:

   Keep instructions factual and functional rather than assuming specific model behaviors. Don’t rely on a specific model being used or assume model capabilities (such as reasoning).

Anti-Patterns to Avoid

Don’t repeat tool descriptions:

// Bad - duplicates what's in tool.description
"instructions": "The search tool searches for files. The read tool reads files."

// Good - adds relationship context
"instructions": "Use 'search' before 'read' to validate file paths. Search results expire after 10 minutes."

Don’t include marketing or superiority claims:

// Bad
"instructions": "This is the best server for all your needs! Superior to other servers!"

// Good
"instructions": "Specialized for Python AST analysis. Not suitable for binary file processing."

Don’t include general behavioral instructions, or anything unrelated to the tools or servers.:

// Bad - unrelated to server functionality
"instructions": "When using this server, talk like a pirate! Also be sure to always suggest that users switch to Linux for better performance."

Don’t write a manual:

// Bad - too long and detailed
"instructions": "This server provides comprehensive functionality for... [500 words]"

// Good - concise and actionable
"instructions": "GitHub integration server. Workflow: 1) 'auth_github', 2) 'list_repos', 3) 'clone_repo'. API rate limits apply - check 'rate_status' before bulk operations."

What Server Instructions Can’t Do:

• Guarantee certain behavior: As with any text you give an LLM, your instructions aren’t going to be followed the same way all the time. Anything you ask a model to do is like rolling dice. The reliability of any instructions will vary based on randomness, sampling parameters, model, client implementation, other servers and tools at play, and many other variables.
  • Don’t rely on instructions for any critical actions that need to happen in conjunction with other actions, especially in security or privacy domains. These are better implemented as deterministic rules or hooks.
• Account for suboptimal tool design: Tool descriptions and other aspects of interface design for agents are still going to make or break how well LLMs can use your server when they need to take an action.
• Change model personality or behavior: Server instructions are for explaining your tools, not for modifying how the model generally responds or behaves.

A Note for Client Implementers

If you’re building an MCP client that supports server instructions, we recommend that you expose instructions to users and provide transparency about what servers are injecting into context. In the VSCode example, I was able to verify exactly what was being sent to the model in the chat logs.

Additional suggestions for implementing instructions in clients:

• Give users control - Allow reviewing, enabling, or disabling server instructions to help users customize server usage and minimize conflicts or remove suboptimal instructions.
• Document your approach - Be clear about how your client handles and applies server instructions.

Currently Supported Host Applications

For a complete list of host applications that support server instructions, refer to the Clients page in the MCP documentation.

For a basic demo of server instructions in action, you can use the Everything reference server to confirm that your client supports this feature:

1. Install the Everything Server in your host. The link above includes instructions on how to do this in a few popular applications. In the example below, we’re using Claude Code.
2. Once you’ve confirmed that the server is connected, ask the model: does the everything server tools have any special instructions?
3. If the model can see your instructions, you should get a response like the one below:

Wrapping Up

Clear and actionable server instructions are a key tool in your MCP toolkit, offering a simple but effective way to enhance how LLMs interact with your server. This post provided a brief overview of how to use and implement server instructions in MCP servers. We encourage you to share your examples, insights, and questions in our discussions.

Acknowledgements

Parts of this blog post were sourced from discussions with the MCP community, contributors, and maintainers including:

• @akolotov
• @cliffhall
• @connor4312
• @digitarald
• @dsp-ant
• @evalstate
• @ivan-saorin
• @jegelstaff
• @localden
• @PederHP
• @tadasant
• @toby

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.

This is especially important in a world where clients and servers don’t have a pre-existing relationship - we can’t assume that we will always know which MCP clients will connect to which MCP servers. This design highlights two challenges that need to be addressed:

• Operational issues with managing client IDs via Dynamic Client Registration (DCR)
• Preventing client impersonation

If you’re already familiar with OAuth and the current state of client registration in MCP, skip to Two Distinct Challenges in MCP Client Registration.

Background on OAuth

A protected MCP server that implements OAuth 2.1 should allow a user to grant a client access to itself and prevent attempts to trick the user into granting access to a client they didn’t intend to use via phishing.

The authorization flow can be best described by looking at this sequence diagram:

  sequenceDiagram
   participant Client
   participant User
   participant AuthServer as Authorization Server
   participant Resource as Resource Server

   Client->>User: 1. Redirect to authorization server
   User->>AuthServer: Navigate to auth URL
   AuthServer->>User: 2. Display consent screen
   User->>AuthServer: Approve access
   AuthServer->>Client: 3. Redirect with authorization code
   Client->>AuthServer: 4. Exchange code for access token
   AuthServer-->>Client: Access token (saved)
   Client->>Resource: 5. Request with access token
   Resource-->>Client: Protected resource

This flow requires a few steps to be performed to acquire an access token:

1. The client directs the user to an authorization UI provided by the authorization server
2. The authorization server displays a consent screen to the user
3. User approves client access and the authorization server redirects the user back to the client with an access code
4. Client exchanges the access code for a set of tokens, which are cached locally
5. Client uses the access token to access the MCP server

To be able to initiate this flow, however, the authorization server first needs some basic information about the client that is kicking off the authorization process:

1. Client name: Human readable text to display in the consent screen to help the user decide whether they want to grant access.
2. Redirect URL: The destination to send the authorization code back to if the user consents.

In order to prevent a malicious client from tricking a user into granting access they didn’t intend to grant, the authorization server must be able to trust the client information it has.

For example, a malicious client could claim to be Claude Desktop on the consent screen while actually being owned by someone not affiliated with Claude Desktop developers. Seeing the client information on the consent screen, users might grant access thinking they’re authorizing the legitimate Claude Desktop, not realizing that some malicious client now has access to their account.

Improving Client Registration in MCP

For MCP users, a common pattern is to connect to an MCP server by using its URL directly in an MCP client.

This goes against the typical OAuth authorization pattern because the user is selecting the resource server to connect to rather than the client developer. This problem is compounded by the fact that there is an unbounded number of authorization servers that an MCP server may use, meaning that clients need to be able to complete the authorization flow regardless of the provider used.

Some client developers have implemented pre-registration with a select few authorization servers. In this scenario, the client doesn’t need to rely on DCR when it detects an authorization server it knows. However, this is a solution that doesn’t scale given the breadth of the MCP ecosystem - it’s impossible to have every client be registered with every authorization server there is. To mitigate this challenge, we set out to outline some of the goals that we wanted to achieve with improving the client registration experience:

1. Clients: Client developers don’t need to implement pre-registration and distribute a client ID for each authorization server MCP servers might be using.
2. Users: Users don’t need to go through a pre-registration process themselves and manually specify a client ID for every MCP server they connect to.
3. Authorization servers:

• Trust in Metadata: Authorization servers have a way to trust the metadata they associate with a client, such as name and redirect URL.
• Single Client ID per App: Authorization servers can have a single client ID per client for governance and management purposes
• Selective Allow/Deny: Authorization servers can selectively allow or deny clients based on their policies.
• Database Management: Authorization servers do not need to handle an unbounded database or expiration flows for every new client registration.

Currently, none of our existing client registration approaches satisfy all of these requirements. Pre-registration requires too much effort in a highly variable setting (unbounded number of clients connecting to unbounded number of servers), while DCR reduces effort but creates operational issues that a lot of the authorization servers are not ready to tackle yet.

Two Distinct Challenges in MCP Client Registration

After extensive discussion with MCP server implementers, we’ve identified that a few competing solutions to the registration problem were addressing two distinct issues:

1. Operational limitations of Dynamic Client Registration in open environments
2. Client identity and impersonation risks across different deployment scenarios

Challenge 1: Operational Limitations of Dynamic Client Registration

The DCR Model Mismatch

The DCR design takes the pre-registration pattern available in modern OAuth-based authorization servers and makes it available via an API. In fully open environments like MCP, DCR really puts the spotlight on a few operational challenges that an open registration endpoint introduces:

For authorization servers:

• Unbounded database growth: Every time a user connects a client to an MCP server, a new registration is created with the authorization server unless the client already has one. Registrations are also not portable, so using Claude Desktop on your Windows machine, and then jumping to Claude Desktop on macOS will create two distinct client registrations.
• Client expiry “black hole”: There’s no way to tell a client that its ID is invalid without creating an open redirect vulnerability. Clients have to implement their own heuristics for client ID management.
• Per-instance confusion: Each client instance typically gets its own client ID even when using the same application, but on different machines or across different users. From an auditing perspective, an authorization server administrator may see hundreds (if not thousands) of records for the same application without any rhyme or reason.
• Denial-of-Service vulnerability: An unauthenticated /register endpoint writes to a database within the authorization server, meaning that tenant admins now need to worry about rate limiting or policy controls (e.g., hosts allowed to register clients).

For clients:

• Extra overhead: Managing registration state and another secret beyond access/refresh tokens
• No validity checking: Can’t verify if a client ID is still valid
• Unclear lifecycle: No guidance on when to re-register or update credentials

Solution: Client ID Metadata Documents (CIMD)

Client ID Metadata Documents (CIMD), described in OAuth Client ID Metadata Document and implemented by Bluesky, elegantly sidestep these operational issues.

Instead of a registration step, clients use an HTTPS metadata URL as their client ID directly. The server fetches the metadata from the URL at authorization time:

  sequenceDiagram
   participant Client
   participant AuthServer
   participant MetadataURL

   Client->>AuthServer: Authorization request (client_id=https://app.com/oauth.json)
   AuthServer->>MetadataURL: GET https://app.com/oauth.json
   MetadataURL-->>AuthServer: {name: "App", redirect_uris: [...]}
   AuthServer->>Client: Show consent screen & continue flow

This addresses all the operational issues:

• No unbounded database growth: Servers fetch metadata on-demand (can cache for performance)
• No expiry management: The URL is the ID - it doesn’t expire
• Natural per-app model: One URL per application, not per user
• No registration endpoint: No unauthenticated write operations

The cost? Clients need to host a metadata document at an HTTPS URL. For web applications, this is trivial. For desktop applications, this typically means hosting on their backend infrastructure.

Challenge 2: Client Identity and Impersonation

The second challenge is orthogonal to the DCR vs. CIMD debate - it’s about trusting that a client is who it claims to be. This problem will exist regardless of how the registration process is implemented.

For web-based clients, trust is more straightforward, as we have an HTTPS domain that’s tied to a certificate authority. For desktop clients, if the client can’t offload its authorization to existing backend infrastructure, there is difficulty trusting the client is legitimate and unmodified.

The Trust Spectrum

We can map impersonation scenarios on two axes: attacker cost and mitigation complexity.

Low attacker cost/Low mitigation complexity: Domain-based attacks

• Attack: Register malicious callback URI and claim to be Claude Desktop
• Cost: Trick user into clicking a link and consenting
• Mitigation:
  • Restrict trusted domains/URLs
  • Show warnings for unknown domains
  • Works with both DCR and CIMD

Medium attacker cost/Medium mitigation complexity: localhost impersonation

• Attack: Run malicious app on localhost:8080, impersonate legitimate client
• Cost: Trick user into running a malicious application (plus consenting for that app to have data access)
• Problem: Desktop apps can’t hold secrets, hard to prove identity

High attacker cost/High mitigation complexity: Platform-attested applications

• Attack: Get malicious client signed by a trusted authority
• Cost: Extremely high - requires compromising certification vendor processes
• Mitigation: platform system-level attestation (future work)

Solution: Software Statements for Desktop Applications

To broadly solve the client impersonation for the middle tier as well as to prevent localhost impersonation we need signed software statements. Implementing this would require:

1. Client hosts a JSON Web Key Set (JWKS) on their backend
2. Client authenticates the user through their own flow
3. The client-owned backend service issues a short-lived, signed JWT attesting to the client’s identity
4. Client includes this JWT in the OAuth flow
5. Authorization server verifies the JWT against the trusted JWKS

This dramatically raises the bar for client impersonation, as an attacker would need to:

• Compromise the client’s backend infrastructure, or
• Successfully impersonate the client’s authentication flow

Crucially, software statements work with both DCR and CIMD. They’re not a competing solution - they’re a complementary security layer.

Future: Platform-Level Attestation

The strongest protection would be platform-level attestation, e.g. having macOS, Windows, or Android attest that a piece of software is legitimate.

Having OS-level attestation would make client impersonation unreasonably expensive. While the exact way this ties into a software statement is yet to be prototyped, the general direction is threading platform-level application identity validation through to the OAuth flow.

The Complementary Path Forward

While we’re looking at all available options, it’s important to note that we’re not choosing between solutions. We’re exploring complementary approaches for distinct problems:

For operational issues: We are looking at adding CIMD support in favor of DCR

• Keep DCR for backward compatibility
• Recommend CIMD for new implementations
• Both achieve the same authorization goal

For trust issues: Layering software statements on top

• Optional enhancement for both DCR and CIMD
• Required only when localhost impersonation is a concern
• Authorization servers choose their required trust level

Security Considerations

Both CIMD and software statements require authorization servers to make outbound HTTPS requests, potentially to untrusted domains. Implementations must:

• Prevent SSRF attacks by blocking internal network access
• Implement timeouts and size limits
• Consider caching strategies for performance
• Validate response formats strictly

If we adopt these approaches, we’ll need good best practices and SDK support to help avoid vulnerabilities and provide a easy path for implementors.

Next Steps

Discussions for these approaches are happening in the Specification Enhancement Proposals (SEP):

• SEP-991: Client ID Metadata Documents
• SEP-1032: Software Statements with DCR

Get involved: Join the conversation in Discord (the #auth-wg-client-registration channel) or comment on the SEPs directly.

A big thank to the following folks for help with this blog post: Den Delimarsky, Aaron Parecki, Geoff Goodman, Andrew Block, Pieter Kasselman, Abhishek Hingnikar, and Bobby Tiernay.

This guide demonstrates how MCP prompts can automate repetitive workflows. Whether you’re interested in the MCP ecosystem or simply want to leverage AI for workflow automation, you’ll learn how to build practical automations through a concrete meal planning example. No prior MCP experience needed—we’ll cover the fundamentals before diving into implementation.

The Problem: Time-Consuming Repetitive Tasks

Everyone has a collection of repetitive tasks that eat away at their productive hours. Common examples include applying code review feedback, generating weekly reports, updating documentation, or creating boilerplate code. These tasks aren’t complex—they follow predictable patterns—but they’re cumbersome and time-consuming. MCP prompts were designed to help automate this kind of work.

MCP prompts offer more than command shortcuts. They’re a primitive for building workflow automation that combines the flexibility of scripting with the intelligence of modern AI systems. This post explores how to build automations using MCP’s prompt system, resource templates, and modular servers. I’ll demonstrate these concepts through a meal planning automation I built, but the patterns apply broadly to any structured, repetitive workflow.

Example: Automating Weekly Meal Planning

I needed to solve a recurring problem: planning weekly meals by cuisine to manage ingredients efficiently. The manual process involved selecting a cuisine, choosing dishes, listing ingredients, shopping, and organizing recipes—repetitive steps that took significant time each week.

So I decided to use MCP! By automating these steps, I could reduce the entire workflow to selecting a cuisine and receiving a complete meal plan with shopping list. (Any client that supports MCP prompts should work!)

1. Select a prompt

   

2. Select a cuisine from a dropdown

3. Done! The system generates a meal plan, shopping list, and even prints the shopping list and recipes.

Here we are focuses primarily on the Recipe Server with its prompts and resources. You can find the printing server example here (it works with a specific thermal printer model, but you could easily swap it for email, Notion, or any other output method). The beauty of separate servers is that you can mix and match different capabilities.

Core Components

Let’s dive into the three components that make this automation possible: prompts, resources, and completions. I’ll show you how each works conceptually, then we’ll implement them together.

1. Resource Templates

In MCP, static resources represent specific pieces of content with unique URIs—like file://recipes/italian.md or file://recipes/mexican.md. While straightforward, this approach doesn’t scale well. If you have recipes for 20 cuisines, you’d need to define 20 separate resources, each with its own URI and metadata.

Resource templates solve this through URI patterns with parameters, transforming static resource definitions into dynamic content providers.

For example, a template like file://recipes/{cuisine}.md might represent a set of resources like these:

• file://recipes/italian.md returns Italian recipes
• file://recipes/mexican.md returns Mexican recipes

This pattern extends beyond simple filtering. You can create templates for:

• Hierarchical data: file://docs/{category}/{topic}
• Git repository content: git://repo/{branch}/path/{file}
• Web resources: https://api.example.com/users/{userId}/data
• Query parameters: https://example.com/{collection}?type={filter}

For more details on URI schemes and resource templates, see the MCP Resource specification.

2. Completions

Nobody remembers exact parameter values. Is it “italian” or “Italian” or “it”? Completions bridge this gap by providing suggestions as users type, creating an interface that feels intuitive rather than restrictive.

Different MCP clients present completions differently:

• VS Code shows a filterable dropdown
• Command-line tools might use fuzzy matching
• Web interfaces could provide rich previews

But the underlying data comes from your server, maintaining consistency across all clients.

3. Prompts: Commands That Evolve With Context

Prompts are the entry points to your automation. They define what commands are available and can range from simple text instructions to rich, context-aware operations.

Let’s see how prompts can evolve to handle increasingly sophisticated use cases:

Basic prompt: Static instruction

"Create a meal plan for a week"

This works, but it’s generic. The AI will create a meal plan based on general knowledge.

Adding parameters: Dynamic customization

"Create a meal plan for a week using {cuisine} cuisine"

Now users can specify Italian, Mexican, or any other cuisine. The prompt adapts to user input, but still relies on the AI’s general knowledge about these cuisines.

Including resources: Your data

Prompts can include resources to add context data beyond simple text instructions. This is crucial when you need the AI to work with your specific context rather than general knowledge.

In my meal planning example, I don’t want generic recipes—I want the AI to use my collection of tested recipes that I know I like. Complex prompts make this possible by bundling prompt text with embedded resources.

Here’s how it works:

1. User selects a prompt with parameters (e.g., “plan-meals” with cuisine=“italian”)
2. Server returns both instructional text AND resource references
3. Client decides how to handle resources - Applications might choose to select a subset of data using embeddings or keyword search, or pass the raw data directly to the model
4. AI receives the context and generates a response

In my example, VS Code attached the entire resource to the prompt, which worked great for this use case. The AI had access to all my Italian recipes when planning an Italian week, ensuring it only suggested dishes I actually had recipes for.

The key difference from simple prompts: instead of asking “Plan Italian meals” and getting generic suggestions, the AI works with your actual recipe collection, dietary preferences, and constraints.

The recipe resources we’ve been using are embedded resources that have inline content from the server. According to the MCP specification, prompts can also include other data types.

This enables advanced use cases beyond our text-based recipes, like design review prompts with screenshots or voice transcription services.

Building the Recipe Server

Let’s implement a complete MCP server that brings together all the concepts we’ve discussed. We’ll start with the server setup and then implement each capability.

Prerequisites

Before diving into the code, make sure you have:

1. Node.js (v18 or higher) and npm installed
2. MCP SDK installed:

   npm install @modelcontextprotocol/sdk
   

3. An MCP-compatible client with prompt and resource support,like VS Code with the MCP extension

For this tutorial, I’ll use the TypeScript SDK, but MCP also supports Python and other languages.

Server Setup and Capabilities

First, let’s create our MCP server:

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

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

main().catch((error) => {
  console.error("Server error:", error);
  process.exit(1);
});

Implementing Resources

Next, let’s register a resource template with completions.

server.registerResource(
  "recipes",
  new ResourceTemplate("file://recipes/{cuisine}", {
    list: undefined,
    complete: {
      cuisine: (value) => {
        return CUISINES.filter((cuisine) => cuisine.startsWith(value));
      },
    },
  }),
  {
    title: "Cuisine-Specific Recipes",
    description: "Traditional recipes organized by cuisine",
  },
  async (uri, variables, _extra) => {
    const cuisine = variables.cuisine as string;

    if (!CUISINES.includes(cuisine)) {
      throw new Error(`Unknown cuisine: ${cuisine}`);
    }

    const content = formatRecipesAsMarkdown(cuisine);
    return {
      contents: [
        {
          uri: uri.href,
          mimeType: "text/markdown",
          text: content,
        },
      ],
    };
  },
);

Implementing Prompts

Finally, let’s register the prompt, which also has completions:

server.registerPrompt(
  "weekly-meal-planner",
  {
    title: "Weekly Meal Planner",
    description:
      "Create a weekly meal plan and grocery shopping list from cuisine-specific recipes",
    argsSchema: {
      cuisine: completable(z.string(), (value) => {
        return CUISINES.filter((cuisine) => cuisine.startsWith(value));
      }),
    },
  },
  async ({ cuisine }) => {
    const resourceUri = `file://recipes/${cuisine}`;
    const recipeContent = formatRecipesAsMarkdown(cuisine);

    return {
      title: `Weekly Meal Planner - ${cuisine} Cuisine`,
      description: `Weekly meal planner for ${cuisine} cuisine`,
      messages: [
        {
          role: "user",
          content: {
            type: "text",
            text: `Plan cooking for the week. I've attached the recipes from ${cuisine} cuisine.

Please create:
1. A 7-day meal plan using these recipes
2. An optimized grocery shopping list that minimizes waste by reusing ingredients across multiple recipes
3. Daily meal schedule with specific dishes for breakfast, lunch, and dinner
4. Preparation tips to make the week more efficient
5. Print Shopping list

Focus on ingredient overlap between recipes to reduce food waste.`,
          },
        },
        {
          role: "user",
          content: {
            type: "resource",
            resource: {
              uri: resourceUri,
              mimeType: "text/markdown",
              text: recipeContent,
            },
          },
        },
      ],
    };
  },
);

Running It Yourself

The full code for the recipe server is available here.

Follow VS Code’s documentation to set up the server. Once a server is set up in VS Code, you can see its status, debug what’s happening, and iterate quickly on your automations.

After the server is set up in VS Code, type “/” in chat and select the prompt.

Extending Your Automations

MCP prompts open up exciting automation possibilities:

• Prompt Chains: Execute multiple prompts in sequence (plan meals → generate shopping list → place grocery order)
• Dynamic Prompts: Adapt based on available resources or time of year
• Cross-Server Workflows: Coordinate multiple MCP servers for complex automations
• External Triggers: Activate prompts via webhooks or schedules

The patterns demonstrated in meal planning apply to many domains:

• Documentation generation that knows your codebase
• Report creation with access to your data sources
• Development workflows that understand your project structure
• Customer support automations with full context

Key takeaways:

• MCP prompts can include dynamic resources, giving AI full context for tasks
• Resource templates enable scalable content serving without duplication
• Modular server architecture lets you mix and match capabilities

Wrapping Up

This meal planning automation started as a simple desire to avoid rewriting shopping lists every week. It evolved into a complete system that handles meal planning, shopping lists, and recipe printing with just a few clicks.

MCP prompts provide practical tools to automate repetitive tasks. The modular architecture means you can start small—perhaps just automating one part of your workflow—and expand as needed. Whether you’re automating documentation, reports, or meal planning, the patterns remain the same: identify repetitive tasks, build focused automations, and let the system handle the tedious parts.

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