{"id":"src_X8ZXQCSS5rTayfgetxzQ3","slug":"mcp-blog","name":"Blog","type":"feed","url":"https://blog.modelcontextprotocol.io/","orgId":"org_8KCcpRQyRim07ckEHrKIu","productId":null,"productSlug":null,"org":{"id":"org_8KCcpRQyRim07ckEHrKIu","slug":"modelcontextprotocol","name":"Model Context Protocol"},"isPrimary":false,"isHidden":false,"discovery":"curated","metadata":"{\"feedUrl\":\"https://blog.modelcontextprotocol.io/index.xml\",\"feedType\":\"rss\",\"marketingFilter\":true,\"marketingFilterHint\":\"Keep posts announcing spec revisions and release candidates, SDK launches or major versions, and new protocol features or extensions (e.g. MCP Apps, MCP Registry, enterprise-managed auth). Treat governance/process updates (maintainer changes, SEP process, foundation membership) and how-to or opinion essays as non-release.\",\"feedEtag\":\"W/\\\"6a8ab83a-6bea8\\\"\",\"feedLastModified\":\"Sun, 23 Aug 2026 09:07:06 GMT\",\"sourceActor\":{\"nextAlarmAt\":\"2026-10-25T00:04:55.398Z\",\"lastAlarmAt\":\"2026-10-24T04:02:41.787Z\",\"managed\":true}}","notice":null,"kind":null,"stars":null,"starsFetchedAt":null,"releaseCount":24,"releasesLast30Days":0,"avgReleasesPerWeek":0.2,"latestVersion":null,"latestDate":"2026-08-22T09:00:00.000Z","changelogUrl":null,"hasChangelogFile":false,"lastFetchedAt":"2026-10-23T23:12:19.562Z","lastPolledAt":"2026-10-24T00:04:55.398Z","changeDetectedAt":null,"trackingSince":"2025-07-02T10:46:28.000Z","releases":[{"id":"rel_o52qyMw6XNvJ2IgJNHukN","version":null,"type":"feature","title":"The New MCP Roadmap","summary":"The new roadmap, developed by Core Maintainers with community working groups, organizes protocol work into five priority areas: agentic messaging primitives, HTTP-native transport unification and hardening, agent identity and enterprise-ready security, improved primitives, and improved SDK developer experience. It follows the 2026-07-28 specification release, which removed protocol-level sessions and the initialization handshake, reworked Tasks into an official extension, and added authorization improvements including CIMD and stable Enterprise-Managed Authorization.","titleGenerated":"MCP publishes new roadmap with five priority areas beyond next spec release","titleShort":"MCP roadmap sets five priority areas for protocol work","breaking":"unknown","importance":3,"content":"Today we’re excited to publish an updated [roadmap](https://modelcontextprotocol.io/development/roadmap) for the Model Context Protocol (MCP), covering the next specification release and beyond.\n\nIt sets the direction for protocol work over the coming months and was developed by the Core Maintainers together with our community of maintainers and Working Groups.\n\n[Explore the roadmap →](https://modelcontextprotocol.io/development/roadmap) .mcp-button { display: inline-block; padding: 8px 16px; font-size: 14px; font-weight: 500; text-decoration: none; border-radius: 4px; transition: all 0.2s ease; margin: 12px 0; background-color: #1a1a1a; color: #ffffff; border: 1px solid #333; } .mcp-button:hover { background-color: #333; color: #ffffff; } .mcp-button-arrow { margin-left: 6px; transition: transform 0.2s ease; display: inline-block; } .mcp-button:hover .mcp-button-arrow { transform: translateX(3px); } .dark .mcp-button { background-color: #ffffff; color: #1a1a1a; border: 1px solid #e5e5e5; } .dark .mcp-button:hover { background-color: #f0f0f0; color: #1a1a1a; }\n\n## Looking back\n\nThe [previously published roadmap](/posts/2026-mcp-roadmap/) came out in March with four priority areas: **transport evolution and scalability**, **agent communication**, **governance maturation**, and **enterprise readiness**. We’ve made significant progress in all of these over the past five months.\n\nThe bulk of the changes landed in the [2026-07-28 specification release](/posts/2026-07-28/) - you might’ve already seen them in our SDKs and documentation. The improvements ranged from minor modifications to major protocol overhauls.\n\nOne of the biggest changes we shipped is that protocol-level sessions and the initialization handshake are gone, so a server can scale horizontally without holding state ([SEP-2575](https://modelcontextprotocol.io/seps/2575-stateless-mcp), [SEP-2567](https://modelcontextprotocol.io/seps/2567-sessionless-mcp)). Additionally, clients can now call `server/discover` to learn a server’s supported versions and capabilities before doing anything else. List results are also cacheable ([SEP-2549](https://modelcontextprotocol.io/seps/2549-TTL-for-list-results)).\n\nOn the agent communication side, Tasks were reworked based on early adopter feedback - we moved them into an official extension ([SEP-2663](https://modelcontextprotocol.io/seps/2663-tasks-extension)). The brand-new Multi Round-Trip Requests pattern ([SEP-2322](https://modelcontextprotocol.io/seps/2322-MRTR)) replaced server-initiated requests so that elicitation and similar flows work on stateless servers.\n\nThe [Server Card Working Group](https://modelcontextprotocol.io/community/working-groups/server-card) continues to work through the `.well-known` metadata conventions for MCP servers, so a server can be discovered and reasoned over without connecting to it.\n\nGovernance has evolved as well. We formally adopted a [Contributor Ladder](https://modelcontextprotocol.io/community/contributor-ladder), Working Groups now triage SEPs in their own area, and the specification has a proper [feature lifecycle and deprecation policy](https://modelcontextprotocol.io/community/feature-lifecycle) that the `2026-07-28` deprecations were the first to follow.\n\nEnterprise readiness was heavily focused on security in the past release cycle, and as expected most of this work arrived as authorization improvements: issuer validation, issuer-bound client credentials, and Client ID Metadata Documents (CIMD) as the preferred registration path for clients, with [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) available as an extension (which is also [now stable](/posts/enterprise-managed-auth/)).\n\nThis is significant progress in a very short span. The updated roadmap picks up from here.\n\n## Priority areas\n\nThe new roadmap is organized into five priority areas. Several of them pick up work that the [previous version of the roadmap](/posts/2026-mcp-roadmap/) listed as being on the horizon, including server-initiated events, result type improvements, and agent identity, which have since matured enough to become priorities in their own right. Each area has a set of Core Maintainers responsible for it and one or more Working Groups.\n\n\n\n### Agentic messaging primitives\n\nModern agentic workloads no longer fit the standard [request-and-response pattern](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns). Loops can run for longer, servers can push streamed results, and there is a clear need to steer work mid-flight. MCP has been growing to meet these requirements, introducing [Tasks](https://modelcontextprotocol.io/extensions/tasks/overview), [`subscriptions/listen`](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), and [progress notifications](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/progress). We want to make sure that we not only offer the right primitives for the job, but also that they work well together. The work here spans server-initiated events (webhooks and channels, so clients aren’t left polling for results), a composition review across the [Agents](https://modelcontextprotocol.io/community/working-groups/agents), Transports, and [Triggers & Events](https://modelcontextprotocol.io/community/working-groups/triggers-events) Working Groups, and maturing the Tasks extension ([SEP-2663](https://modelcontextprotocol.io/seps/2663-tasks-extension)) so it can move into the specification.\n\n### HTTP-native transport unification and hardening\n\nWith the [2026-07-28 release](https://modelcontextprotocol.io/specification/2026-07-28/changelog), a remote MCP server is now no different from any other HTTP workload, making it easy to host and operate one on any infrastructure that developers and organizations already use for their APIs and services. This approach has proven to scale, and we want to stretch it to cover other deployment modes as well, including local servers speaking [Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) over [stdio](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdio). Unifying on one transport lets us simplify MCP server and client development even further.\n\n### Agent identity and enterprise-ready security\n\n[MCP authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens.\n\nThe work here covers finalizing [Demonstrating Proof of Possession](https://www.rfc-editor.org/rfc/rfc9449) (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through [Workload Identity Federation](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1933), the ID-JAG grant behind [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization), and standard token exchange. We will also continue to grow our engagement with the OAuth standards bodies, including the IETF OAuth and [WIMSE](https://datatracker.ietf.org/wg/wimse/about/) working groups, to help the underlying standards evolve with the building blocks that agent identity needs.\n\n### Improved primitives\n\nTool calling is the part of MCP most developers touch first, and it has held up well over the lifetime of the protocol. Where it falls a bit short, however, is in the result handling. A [`tools/call`](https://modelcontextprotocol.io/specification/2026-07-28/server/tools#tool-result) response can carry the same output in more than one form, and a server developer today has no way to know which form a given client will put in front of the model. We aim to make this easier by standardizing on one clear contract.\n\nThe other challenge we need to address for primitives is their ever-growing scale. Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows. We’re starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows.\n\n### Improved SDK developer experience\n\nOur SDKs are how developers experience MCP. We are investing in their ergonomics and their [conformance with the specification](https://modelcontextprotocol.io/community/sdk-tiers#conformance-testing), and in making them intuitive and well-documented across every platform and language we support. This is even more important now that many developers build MCP clients and servers by pointing an agent at our libraries, where clear APIs and accurate docs decide whether the code will work with minimal friction.\n\n## Proposal prioritization\n\n[Specification Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines) (SEPs) that fall within these priority areas get expedited review and have the best chance of acceptance. Proposals outside them aren’t rejected automatically, but maintainer review time is scarce and goes to these areas first.\n\nIf you’re considering a SEP, identify the priority area it belongs to, raise it with the relevant [Working Group](https://modelcontextprotocol.io/community/working-interest-groups), and work with its members to shape your proposal. Each area on the [roadmap](https://modelcontextprotocol.io/development/roadmap) names the Core Maintainers responsible for it, and anyone interested in contributing can reach them on [Discord](https://modelcontextprotocol.io/community/communication#discord). We’re excited to work with the community to review and build on the proposals that support this roadmap.\n\n## Get involved\n\nEvery priority area above has a Working Group behind it or forming around it, and all of them have room for more contributors. There are several ways to participate:\n\n- **Join a Working Group or Interest Group**: see the [Working and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups) page and the [community channels](https://modelcontextprotocol.io/community/communication).\n- **Propose or comment on a SEP**: read the [SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines), then open one or weigh in.\n- **Start an experimental extension**: [SEP-2133](https://modelcontextprotocol.io/seps/2133-extensions) lets any WG or IG experiment in an `experimental-ext-` repository before a formal SEP.\n- **Contribute directly**: the [contributing guide](https://modelcontextprotocol.io/community/contributing) covers the specification, SDKs, and tooling.\n\nWe look forward to growing and evolving MCP together!","publishedAt":"2026-08-22T09:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.256Z","url":"https://blog.modelcontextprotocol.io/posts/mcp-roadmap/","media":[],"coverageCount":0},{"id":"rel_i_RyopU2WWSGXC6V_ZZkL","version":null,"type":"feature","title":"The 2026-07-28 Specification","summary":"The 2026-07-28 MCP specification replaces the initialize/initialized handshake and Mcp-Session-Id header with a stateless request/response core where each request carries protocol version, client identity, and capabilities in _meta, plus new Mcp-Method and Mcp-Name routing headers. Server-to-client requests move to Multi Round-Trip Requests, list responses gain ttlMs and cacheScope hints, DCR is formally deprecated in favor of CIMD, and Roots, Sampling, and Logging are deprecated with a twelve-month window.","titleGenerated":"MCP 2026-07-28 spec retires sessions and handshake for stateless core","titleShort":"MCP goes stateless; initialize and session IDs retired","breaking":"unknown","importance":5,"content":"Since our [last November release](/posts/2025-11-25-first-mcp-anniversary/) MCP continued to grow at an astonishing rate. Across our Tier 1 SDKs, we’re seeing close to half-a-billion downloads a month, with both TypeScript and Python SDKs crossing the 1 billion total downloads threshold. In just a few months, the protocol continued to grow as the data and interactivity substrate for agentic workflows.\n\nToday, 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.\n\nThe 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.\n\n \n\nThere is, of course, more to what we’re introducing with this version:\n\n- 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.\n- Method and tool names travel in the `Mcp-Method` and `Mcp-Name` HTTP headers, so gateways can route and authorize on headers directly.\n- 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.\n- List responses carry cache hints and a deterministic order, so clients can cache tool catalogs and keep upstream prompt caches stable across reconnects.\n- Formally locking in on a proper extensions framework, with Tasks joining other extensions, such as MCP Apps and Enterprise Managed Authorization (EMA).\n- 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).\n- A formal deprecation policy with a twelve-month minimum window so you can plan upgrades instead of reacting to them.\n\nThe 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.\n\n## What changed\n\n### No handshake or sessions\n\nWith the new spec version, we’ve officially retired the `initialize`/`initialized` exchange along with the `Mcp-Session-Id` header (refer to [SEP-2575](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575), [SEP-2567](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\n```http\nPOST /mcp HTTP/1.1\nMCP-Protocol-Version: 2026-07-28\nMcp-Method: tools/call\nMcp-Name: search\n\n{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"tools/call\",\n \"params\":{\"name\":\"search\",\"arguments\":{\"q\":\"otters\"},\n \"_meta\":{\"io.modelcontextprotocol/clientInfo\":{\"name\":\"my-app\",\"version\":\"1.0\"}}}}\n\n```\n\nDropping 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.\n\n### Multi Round-Trip Requests (MRTR)\n\nMRTR replaces the server-initiated `elicitation/create`, `sampling/createMessage`, and `roots/list` requests that previously required a held-open stream.\n\nSometimes a tool needs something from the user mid-call, such as a confirmation or a missing parameter. MRTR ([SEP-2322](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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`.\n\n### Header-based routing\n\nStreamable HTTP requests now must include `Mcp-Method` and `Mcp-Name` ([SEP-2243](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2243)). Your gateway, rate limiter, or WAF can route and meter on those headers instead of parsing JSON bodies.\n\n### List results are cacheable\n\nResponses from `tools/list`, `prompts/list`, `resources/list`, and `resources/read` now carry `ttlMs` and `cacheScope` ([SEP-2549](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2549)). This allows clients to determine the best caching strategy for responses and reduce unnecessary re-fetching.\n\n### Authorization\n\nFrom 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.\n\n- Authorization servers should return the `iss` parameter per [RFC 9207](https://www.rfc-editor.org/rfc/rfc9207), and clients must validate it before redeeming a code ([SEP-2468](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2468)). This closes an authorization-server mix-up hole.\n- Clients set `application_type` during Dynamic Client Registration (DCR) so authorization servers stop rejecting `localhost` redirects for desktop and CLI apps ([SEP-837](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n- Client credentials are bound to the issuer that minted them. No reuse across authorization servers ([SEP-2352](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2352)).\n- 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.\n\n### Tasks\n\nTasks 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](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663)). Change notifications move from the old HTTP GET endpoint to a single `subscriptions/listen` stream that clients opt into per notification type.\n\n### Deprecations\n\nRoots, Sampling, and Logging are deprecated ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\n## SDKs\n\nAll four Tier 1 SDKs speak `2026-07-28` as of today:\n\n- [TypeScript](https://github.com/modelcontextprotocol/typescript-sdk)\n- [Python](https://github.com/modelcontextprotocol/python-sdk)\n- [Go](https://github.com/modelcontextprotocol/go-sdk)\n- [C#](https://github.com/modelcontextprotocol/csharp-sdk)\n\nBeyond the Tier 1 set, the [Rust SDK](https://github.com/modelcontextprotocol/rust-sdk) supports the new spec in beta.\n\nThe 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](/posts/sdk-betas-2026-07-28/), 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.\n\n## Ecosystem support\n\nAs 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.\n\n> 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.\n\nDavid Soria Parra Member of Technical Staff, Co-Inventor of MCP\n\n> 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.\n\nAlex Salazar CEO & Co-Founder\n\n> 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.\n\nSwami Sivasubramanian VP of Agentic AI\n\n> 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.\n\nBrendan Irvine-Broque Senior Director Product Management\n\n> 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.\n\nJosh Clemm VP of Engineering\n\n\n\n> 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.\n\nAnna Berenberg Engineering Fellow\n\n> 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.\n\nAustin Parker Director of AI Strategy\n\n> 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.\n\nEnrico Toniato CTO\n\n> 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.\n\nTina Schuchman Corporate Vice President for Engineering, Microsoft Foundry\n\n> 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.\n\nSean Roberts VP of Applied AI\n\n> 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.\n\nNick Cooper MTS & MCP Core Maintainer\n\n> 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.\n\nPaul D'Ambra Product Engineer\n\n> 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.\n\nJeremiah Lowin CEO\n\n> 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.\n\nTal Peretz Co-founder & CPO\n\n> 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.\n\nCraig McLuckie CEO\n\n> 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.\n\nInian Parameshwaran Head of Product\n\n\n\n> 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.\n\nAndrew Goodman VP of AI\n\n(function () { var reduceMotion = window.matchMedia(\"(prefers-reduced-motion: reduce)\"); function init(root) { var track = root.querySelector(\".mcp-quotes-track\"); var nav = root.querySelector(\".mcp-quotes-nav\"); if (!track || !nav) return; var prev = nav.querySelector(\".mcp-quotes-prev\"); var next = nav.querySelector(\".mcp-quotes-next\"); var dotsBox = nav.querySelector(\".mcp-quotes-dots\"); var dots = \\[\\]; var pending = null; var settle = 0; function step() { var card = track.querySelector(\".mcp-quote\"); return card ? card.getBoundingClientRect().width : track.clientWidth; } function perPage() { return Math.max(1, Math.floor(track.clientWidth / step() + 0.001)); } function pageCount() { var cards = track.querySelectorAll(\".mcp-quote\").length; return Math.max(1, Math.ceil(cards / perPage())); } function position() { return pending === null ? track.scrollLeft : pending; } function current() { var max = track.scrollWidth - track.clientWidth; if (max <= 0) return 0; if (position() >= max - 2) return pageCount() - 1; return Math.round(position() / step() / perPage()); } function goTo(i) { var max = track.scrollWidth - track.clientWidth; var left = Math.max(0, Math.min(Math.round(i \\* perPage() \\* step()), max)); pending = left; track.scrollTo({ left: left, behavior: reduceMotion.matches ? \"auto\" : \"smooth\", }); update(); } function update() { var i = current(); var max = track.scrollWidth - track.clientWidth; prev.disabled = position() <= 2; next.disabled = position() >= max - 2; dots.forEach(function (dot, j) { dot.setAttribute(\"aria-current\", j === i ? \"true\" : \"false\"); }); } function build() { var n = pageCount(); pending = null; nav.hidden = n < 2; dotsBox.textContent = \"\"; dots = \\[\\]; for (var i = 0; i < n; i++) { var dot = document.createElement(\"button\"); dot.type = \"button\"; dot.className = \"mcp-quotes-dot\"; dot.setAttribute(\"aria-label\", \"Go to quotes page \" + (i + 1)); dot.addEventListener(\"click\", goTo.bind(null, i)); dotsBox.appendChild(dot); dots.push(dot); } update(); } prev.addEventListener(\"click\", function () { goTo(current() - 1); }); next.addEventListener(\"click\", function () { goTo(current() + 1); }); track.addEventListener(\"scroll\", function () { if (pending !== null && Math.abs(track.scrollLeft - pending) <= 2) pending = null; clearTimeout(settle); settle = setTimeout(function () { pending = null; update(); }, 150); requestAnimationFrame(update); }); window.addEventListener(\"resize\", build); build(); } function initAll() { document.querySelectorAll(\".mcp-quotes\").forEach(init); } if (document.readyState === \"loading\") { document.addEventListener(\"DOMContentLoaded\", initAll); } else { initAll(); } })();\n\n## Getting started\n\nWe’re excited to have developers build on the new spec. To get started, refer to the following resources:\n\n- [Specification](https://modelcontextprotocol.io/specification/2026-07-28)\n- [Full changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog)\n- [Documentation and guides](https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro)\n\n## Thank you\n\nThis 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!","publishedAt":"2026-07-28T09:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.256Z","url":"https://blog.modelcontextprotocol.io/posts/2026-07-28/","media":[],"coverageCount":0},{"id":"rel_D5CLyd5ZOydMJZNjoKPYT","version":"1.0","type":"feature","title":"The Official Ruby SDK for MCP Reaches 1.0","summary":"The mcp gem's first stable release implements the 2025-06-18 and 2025-11-25 spec revisions and passes 100% of server and client conformance scenarios, with the public API now stable so breaking changes ship only in major releases. It includes full server and client support for tools, prompts, resources, OAuth with dynamic client registration and PKCE, plus stdio and Streamable HTTP transports that mount directly in Rails routes.","titleGenerated":"Official MCP Ruby SDK reaches 1.0 with stable public API and full Tier 2 conformance","titleShort":"Ruby SDK hits 1.0; public API stable, breaking changes major-only","breaking":"unknown","importance":3,"content":"[Version 1.0.0](https://github.com/modelcontextprotocol/ruby-sdk/releases/tag/v1.0.0) of the official [Ruby SDK](https://github.com/modelcontextprotocol/ruby-sdk) for the Model Context Protocol is now available. This is the first stable release of the [`mcp` gem](https://rubygems.org/gems/mcp): the public API is now stable, and breaking changes ship only in major releases, following the Semantic Versioning policy documented in [VERSIONING.md](https://github.com/modelcontextprotocol/ruby-sdk/blob/main/VERSIONING.md).\n\nAlongside the release, the Ruby SDK now meets every Tier 2 requirement of the [SDK tiering system](https://modelcontextprotocol.io/community/sdk-tiers), as recorded in the [Tier 2 assessment](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/3127), and development toward Tier 1 is ongoing.\n\n## What is in 1.0\n\nThe 1.0 release implements the 2025-06-18 and 2025-11-25 specification revisions and passes 100% of the server and client conformance scenarios. It includes:\n\n- MCP servers with tools, prompts, resources (including templates and subscriptions), completions, logging, pagination, progress, and cancellation, plus server-to-client requests for sampling, elicitation (form and URL mode), and roots\n- An MCP client with a complete OAuth flow, including dynamic client registration, PKCE, and scope handling\n- stdio and Streamable HTTP transports; the HTTP transport is a standard Rack app, so it can be mounted directly in Rails routes or any Rack-compatible framework\n\n## From Tier 3 to Tier 2\n\nThe Ruby SDK was assessed at [Tier 3](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2340) in March 2026. Since then:\n\n- Server conformance moved from 83.3% to 100%, with no baselined failures\n- A conformance client was implemented and passes 100% of client scenarios\n- Sampling, elicitation, and progress notifications were implemented on both the server and client sides\n- [ROADMAP.md](https://github.com/modelcontextprotocol/ruby-sdk/blob/main/ROADMAP.md) and [VERSIONING.md](https://github.com/modelcontextprotocol/ruby-sdk/blob/main/VERSIONING.md) were published\n\nWork is also under way to support the upcoming [2026-07-28 specification release](/posts/sdk-betas-2026-07-28/).\n\n## Get started\n\nInstall the gem:\n\n```console\n$ gem install mcp\n\n```\n\nA minimal stdio server looks like this:\n\n```ruby\nrequire \"mcp\"\n\nclass ExampleTool < MCP::Tool\n description \"A simple example tool that echoes back its arguments\"\n input_schema(\n properties: {\n message: { type: \"string\" },\n },\n required: [\"message\"]\n )\n\n class << self\n def call(message:, server_context:)\n MCP::Tool::Response.new([{\n type: \"text\",\n text: \"Hello from example tool! Message: #{message}\",\n }])\n end\n end\nend\n\nserver = MCP::Server.new(\n name: \"example_server\",\n tools: [ExampleTool],\n)\n\nMCP::Server::Transports::StdioTransport.new(server).open\n\n```\n\nSee the [Ruby SDK documentation](https://ruby.sdk.modelcontextprotocol.io) for guides on building servers and clients, including Rails integration.\n\n## Give us your feedback\n\nIf you run into problems or unexpected behavior while using the SDK, please report them on the [issue tracker](https://github.com/modelcontextprotocol/ruby-sdk/issues). Reports from real-world usage are especially valuable.\n\nThe Ruby SDK began at [Shopify](https://www.shopify.com/) and is maintained by [Topher Bullock](https://github.com/topherbullock), [Koichi Ito](https://github.com/koic), [Ateş Göral](https://github.com/atesgoral), and [Jonathan Hefner](https://github.com/jonathanhefner) together with the wider Ruby community. Thank you to everyone for the feedback and contributions on the road to 1.0.","publishedAt":"2026-07-27T09:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.256Z","url":"https://blog.modelcontextprotocol.io/posts/ruby-sdk-1-0/","media":[],"coverageCount":0},{"id":"rel_oNd4cRJ0rxwVidlhUjdDI","version":null,"type":"feature","title":"Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here","summary":"Python v2 and TypeScript v2 lead four Tier 1 beta SDKs (with Go and C# betas) implementing the 2026-07-28 release candidate, whose stateless core removes the initialize handshake and protocol-level session so servers can scale behind a round-robin load balancer. The release also adds Multi Round-Trip Requests, routable transport headers, authorization hardening, and standard error codes, while roots, sampling, and logging get advisory deprecation annotations.","titleGenerated":"MCP ships beta SDKs for its biggest protocol revision yet","titleShort":"Stateless MCP arrives in beta SDKs ahead of July 28 spec","breaking":"unknown","importance":5,"content":"The MCP protocol is about to undergo its biggest revision since launch. As you might’ve seen from [our recent release candidate announcement](/posts/2026-07-28-release-candidate/), the new protocol revision goes stateless, removing the `initialize` handshake and the protocol-level session, and completing the plan we laid out in [The Future of MCP Transports](/posts/2025-12-19-mcp-transport-future/). If you’re building MCP servers, you can now scale them using a simple round-robin load balancer, removing the need to manage sticky sessions and to store shared sessions. For client developers, new patterns, like [Multi Round-Trip Requests (MRTR)](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr) enable a whole new range of possibilities for server-to-client interactions. You can check out the [full changelog](https://modelcontextprotocol.io/specification/draft/changelog) to see what’s coming.\n\nStarting today you can test all the forthcoming updates to the protocol with all four [Tier 1](https://modelcontextprotocol.io/community/sdk-tiers) SDKs, led by [Python](https://github.com/modelcontextprotocol/python-sdk) v2 and [TypeScript](https://github.com/modelcontextprotocol/typescript-sdk) v2, with [Go](https://github.com/modelcontextprotocol/go-sdk) and [C#](https://github.com/modelcontextprotocol/csharp-sdk) 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.\n\n\n\n## Your existing server keeps working\n\nFirst, 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.\n\nThe 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.\n\nYou 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.\n\nTrying 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.\n\nIf you want to make sure your own users are not caught out:\n\n- 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.\n- When you test a beta, pin the exact version. Public APIs may still change between the beta and the stable releases.\n\n## What beta SDKs implement\n\nAll 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](/posts/2026-07-28-release-candidate/) covers the changes in depth, but if you’re curious about the short version:\n\n- **The stateless core** ([SEP-2575](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575), [SEP-2567](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2567)). Every request is self-describing, capabilities come from `server/discover`, and any server instance can handle any request.\n- **Multi Round-Trip Requests (MRTR)** ([SEP-2322](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322)). Tools can return `InputRequiredResult` to ask the user something mid-call, and the client retries with the answers. No long-lived stream required!\n- **Routable transport headers** ([SEP-2243](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n- **Authorization hardening**, including `iss` validation per [RFC 9207](https://www.rfc-editor.org/rfc/rfc9207) ([SEP-2468](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2468)), `application_type` in Dynamic Client Registration ([SEP-837](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/837)), scope accumulation on step-up ([SEP-2350](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2350)), and credential binding to the issuing authorization server ([SEP-2352](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n- **Standard error codes** ([SEP-2164](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n- **Deprecation annotations** ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\nThe full protocol text is in the [draft specification](https://modelcontextprotocol.io/specification/draft), and the [changelog](https://modelcontextprotocol.io/specification/draft/changelog) lists every change against `2025-11-25`.\n\n## Python: `mcp` v2\n\nThe 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:\n\n```python\nfrom mcp.server import MCPServer\n\nmcp = MCPServer(\"Demo\")\n\n\n@mcp.tool()\ndef add(a: int, b: int) -> int:\n \"\"\"Add two numbers.\"\"\"\n return a + b\n\n\n@mcp.resource(\"greeting://{name}\")\ndef greeting(name: str) -> str:\n \"\"\"Greet someone by name.\"\"\"\n return f\"Hello, {name}!\"\n\n```\n\nAs 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:\n\n```bash\nuv add \"mcp[cli]==2.0.0b1\"\n# or\npip install \"mcp[cli]==2.0.0b1\"\n\n```\n\nIf you have a v1 server today, the [migration guide](https://py.sdk.modelcontextprotocol.io/v2/migration/) walks through every breaking change.\n\nOn 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](https://py.sdk.modelcontextprotocol.io/v2/) has the tutorial and the full API reference.\n\n## TypeScript: split packages\n\nTypeScript 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](https://standardschema.dev/), so you can bring Zod v4, Valibot, ArkType, or any compatible library.\n\nYou can bootstrap a minimal server like this:\n\n```typescript\nimport { McpServer } from \"@modelcontextprotocol/server\";\nimport { StdioServerTransport } from \"@modelcontextprotocol/server/stdio\";\nimport * as z from \"zod/v4\";\n\nconst server = new McpServer({ name: \"greeting-server\", version: \"1.0.0\" });\n\nserver.registerTool(\n \"greet\",\n {\n description: \"Greet someone by name\",\n inputSchema: z.object({ name: z.string() }),\n },\n async ({ name }) => ({\n content: [{ type: \"text\", text: `Hello, ${name}!` }],\n }),\n);\n\nasync function main() {\n const transport = new StdioServerTransport();\n await server.connect(transport);\n}\n\nmain();\n\n```\n\nTo install any of the packages, you can use the now-familiar `npm` commands:\n\n```bash\nnpm install @modelcontextprotocol/server@beta\nnpm install @modelcontextprotocol/client@beta\n\n```\n\nFor 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.\n\nMigrating 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:\n\n```bash\nnpx @modelcontextprotocol/codemod@beta v1-to-v2 .\n\n```\n\nThe repository ships two guides that will help you along the way:\n\n- [Upgrading from v1 to v2](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/docs/migration/upgrade-to-v2.md)\n- [Adopting the 2026-07-28 revision](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/docs/migration/support-2026-07-28.md)\n\nWhile 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](https://ts.sdk.modelcontextprotocol.io/v2/) covers the rest.\n\n## Go and C#\n\nThe 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.\n\nThe 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:\n\n```bash\ngo get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1\n\n```\n\nServing 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](https://github.com/modelcontextprotocol/go-sdk/releases/tag/v1.7.0-pre.1) walk through every protocol change and the [SDK documentation](https://go.sdk.modelcontextprotocol.io) will cover the updated API.\n\nThe C# beta, in turn, is released as the `2.0.0-preview.1` version of the `ModelContextProtocol` packages:\n\n```bash\ndotnet add package ModelContextProtocol --prerelease\n\n```\n\nStable 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](https://github.com/modelcontextprotocol/csharp-sdk/releases/tag/v2.0.0-preview.1) include a per-SEP implementation table, and the [SDK documentation](https://csharp.sdk.modelcontextprotocol.io) will have the updated API reference once the package is stable.\n\n## Give us your feedback\n\nWe’re a mere four weeks away until the specification is final. We need your help to make the release smoother!\n\n1. Install a beta in a branch of your server and run your real traffic against it, not just the happy path.\n \n2. 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.\n \n3. File what you find. SDK problems go to the issue tracker for the SDK you are using:\n \n - [Python](https://github.com/modelcontextprotocol/python-sdk/issues)\n - [TypeScript](https://github.com/modelcontextprotocol/typescript-sdk/issues)\n - [Go](https://github.com/modelcontextprotocol/go-sdk/issues)\n - [C#](https://github.com/modelcontextprotocol/csharp-sdk/issues)\n \n And if you spot issues with the protocol itself, go to the [specification repository](https://github.com/modelcontextprotocol/modelcontextprotocol/issues).\n \n\nIt’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](https://modelcontextprotocol.io/community/communication#discord).\n\nWe’re excited to see what you build!","publishedAt":"2026-06-29T09:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.438Z","url":"https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/","media":[],"coverageCount":0},{"id":"rel_vMk58uZUi9ppNPbP7O1m0","version":null,"type":"feature","title":"Enterprise-Managed Authorization: Zero-touch OAuth for MCP","summary":"The Enterprise-Managed Authorization extension is now stable, letting organizations control MCP server access centrally through their identity provider: clients obtain an Identity Assertion JWT Authorization Grant during single sign-on and exchange it for server access tokens, so users connect all authorized servers on first login instead of per-server OAuth. Okta is the first supported identity provider, with Anthropic, Visual Studio Code, and servers including Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase supporting it.","titleGenerated":"MCP Enterprise-Managed Authorization extension reaches stable","titleShort":"Enterprise-Managed Authorization reaches stable","breaking":"unknown","importance":4,"content":"*The Enterprise-Managed Authorization extension is now stable. Organizations can centrally manage authorization for MCP servers and end-users can access all connected MCP servers through a single log in. The extension is being adopted by Anthropic, Microsoft, Okta and a growing number of MCP servers.*\n\nThe [Enterprise-Managed Authorization (EMA) extension](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) 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.\n\nEMA 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.\n\n\n\n## Per-user auth is high friction\n\nThe 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:\n\n- **Every employee has to authorize every server individually**: onboarding means manually connecting service after service.\n- **Security teams cannot enforce consistent policy**: access is whatever each user authorized, with no central control or audit trail.\n- **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.\n\nThis 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.\n\n## Authorize once, inherit everywhere\n\n[Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/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.\n\nUnder the hood, the client obtains an [Identity Assertion JWT Authorization Grant (ID-JAG)](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) 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:\n\n- **Authorize once, inherit everywhere:** admins enable a server for the org. Users get it automatically, scoped to the groups and roles they already have.\n- **Centralized policy and audit:** access decisions live in the IdP admin console, with one auditable trail across every connector.\n- **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.\n\nWe 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.\n\n## Early adopters\n\nThis launch brought together three groups that collaborated closely on making the implementation real:\n\n- **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)](https://www.okta.com/identity-101/cross-app-access-securing-ai-agent-and-app-to-app-connections/).\n- **Clients:** [Anthropic has implemented the extension](https://claude.com/blog/enterprise-managed-auth) 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](https://code.visualstudio.com/updates/v1_123#_enterprise-managed-mcp-authentication-preview) for EMA right in the IDE.\n- **Servers:** Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase now support EMA, with Slack and more actively adding support.\n\nWe’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.\n\n> “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.”\n> \n> — **Aaron Parecki, Director of Identity Standards, Okta**\n\n> “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.”\n> \n> — **Devdatta Akhawe, VP of Engineering, Figma**\n\n> “Logging in once and automatically having all your MCP connectors automatically setup is pretty magical.”\n> \n> — **Tom Moor, Head of Engineering, Linear**\n\n## Get involved\n\nAs 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:\n\n- **Read the requirements:** the [Enterprise-Managed Authorization page](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) documents the flow for clients, servers, and authorization servers.\n- **Source and spec:** see the [ext-auth repository](https://github.com/modelcontextprotocol/ext-auth) and the [specification](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization.mdx) for the latest in EMA evolution as well as any support materials that will help you get started.\n\nIf you’re interested in discussing the extension, sharing compatibility reports, or iterating on the extension, join the [EMA Interest Group](https://modelcontextprotocol.io/community/interest-groups/enterprise-managed-authorization).\n\n## Acknowledgements\n\nEnterprise-Managed Authorization is the work of the MCP community: the authors of SEP-990, the maintainers of the [ext-auth repository](https://github.com/modelcontextprotocol/ext-auth), and the identity and MCP providers who tested early implementations and pushed the spec forward. Thank you to everyone who contributed.","publishedAt":"2026-06-18T17:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.438Z","url":"https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/","media":[],"coverageCount":0},{"id":"rel_uMOuug5TkYFh2uThgAZST","version":null,"type":"feature","title":"The 2026-07-28 MCP Specification Release Candidate","summary":"The 2026-07-28 release candidate revises MCP to a stateless protocol layer: the initialize/initialized handshake and Mcp-Session-Id header are removed, with protocol version and client info traveling in _meta on every request, so remote servers can run behind a plain round-robin load balancer without sticky sessions or a shared session store. It also adds extensions for server-rendered UIs via MCP Apps and long-running work via Tasks, authorization closer to OAuth/OIDC, and a formal deprecation policy; the final spec ships July 28, 2026 with breaking changes.","titleGenerated":"MCP 2026-07-28 release candidate makes the protocol stateless","titleShort":"MCP goes stateless; session and handshake removed","breaking":"unknown","importance":5,"content":"The release candidate for MCP **`2026-07-28`** is now available. It is the largest revision of the protocol since launch and delivers on the [2026 roadmap](/posts/2026-mcp-roadmap/):\n\n- **a stateless core** that scales on ordinary HTTP infrastructure\n- **extensions** including server-rendered UIs through MCP Apps and long-running work through the Tasks extension\n- **authorization** that aligns more closely with OAuth and OpenID Connect deployments\n- **a formal deprecation policy** so the protocol can evolve without breaking what you’ve built,\n\nand many other changes.\n\nThe 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.\n\n> 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.\n\n## A Stateless Protocol\n\nThe headline change is that MCP is now stateless at the protocol layer. Six [Specification Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines) (SEPs) work together to get there, completing the plan we laid out in [The Future of MCP Transports](/posts/2025-12-19-mcp-transport-future/) in December.\n\n\n\n### Before and after\n\nIn [`2025-11-25`](/posts/2025-11-25-first-mcp-anniversary/), calling a tool over Streamable HTTP means establishing a session first:\n\n```http\nPOST /mcp HTTP/1.1\nContent-Type: application/json\n\n{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\n \"params\":{\"protocolVersion\":\"2025-11-25\",\"capabilities\":{},\n \"clientInfo\":{\"name\":\"my-app\",\"version\":\"1.0\"}}}\n\n```\n\nThe server responds with an `Mcp-Session-Id` that every subsequent request must carry, pinning the client to whichever instance issued it:\n\n```http\nPOST /mcp HTTP/1.1\nMcp-Session-Id: 1868a90c-3a3f-4f5b\nContent-Type: application/json\n\n{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/call\",\n \"params\":{\"name\":\"search\",\"arguments\":{\"q\":\"otters\"}}}\n\n```\n\nIn `2026-07-28`, the same call is a single self-contained request that any server instance can handle:\n\n```http\nPOST /mcp HTTP/1.1\nMCP-Protocol-Version: 2026-07-28\nMcp-Method: tools/call\nMcp-Name: search\nContent-Type: application/json\n\n{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"tools/call\",\n \"params\":{\"name\":\"search\",\"arguments\":{\"q\":\"otters\"},\n \"_meta\":{\"io.modelcontextprotocol/clientInfo\":{\"name\":\"my-app\",\"version\":\"1.0\"}}}}\n\n```\n\n### The handshake and session are gone\n\nThe `initialize`/`initialized` handshake is removed ([SEP-2575](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\nThe `Mcp-Session-Id` header and the protocol-level session that came with it are also removed ([SEP-2567](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\n### Stateless protocol, stateful applications\n\nRemoving 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.\n\n\n\nIn 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.\n\nThe 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.\n\n### Server-to-client requests, restructured\n\nA 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.\n\nServer-initiated requests may now only be issued while the server is actively processing a client request ([SEP-2260](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\nMulti Round-Trip Requests ([SEP-2322](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322)) change how those prompts are delivered. Instead of holding a Server-Sent Events (SSE) stream open, the server returns an `InputRequiredResult`:\n\n```json\n{\n \"resultType\": \"input_required\",\n \"inputRequests\": {\n \"confirm\": {\n \"type\": \"elicitation\",\n \"message\": \"Delete 3 files?\",\n \"schema\": { \"type\": \"boolean\" }\n }\n },\n \"requestState\": \"eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0=\"\n}\n\n```\n\nThe 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.\n\n### Routable, cacheable, traceable\n\nThree smaller changes make the resulting traffic easier to operate.\n\nThe Streamable HTTP transport now requires `Mcp-Method` and `Mcp-Name` headers ([SEP-2243](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\nList and resource read results now carry `ttlMs` and `cacheScope` ([SEP-2549](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\nW3C Trace Context propagation in `_meta` is now documented ([SEP-414](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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](https://opentelemetry.io/)\\-compatible backend.\n\n## Extensions Become First-Class\n\nExtensions existed in the `2025-11-25` release but had no formal process behind them. [SEP-2133](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\nThis release includes two official extensions.\n\n### MCP Apps: server-rendered user interfaces\n\n[MCP Apps](/posts/2026-01-26-mcp-apps/) ([SEP-1865](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\n### Tasks graduates to an extension\n\nTasks shipped as an experimental core feature in [`2025-11-25`](https://modelcontextprotocol.io/specification/2025-11-25/server/tasks). Production use surfaced enough redesign that the right home for it is an extension rather than the specification.\n\nThe [Tasks extension](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663) 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.\n\nAnyone who shipped against the `2025-11-25` experimental Tasks API will need to migrate to the new lifecycle.\n\n## Authorization Hardening\n\nSix SEPs harden the [authorization specification](https://modelcontextprotocol.io/specification/draft/basic/authorization) to align more closely with how OAuth 2.0 and OpenID Connect are deployed in practice.\n\nClients must now validate the `iss` parameter on authorization responses per [RFC 9207](https://www.rfc-editor.org/rfc/rfc9207) ([SEP-2468](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\nClients now declare their OpenID Connect `application_type` during Dynamic Client Registration ([SEP-837](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2352)). The spec also documents how to request refresh tokens from OpenID Connect-style authorization servers ([SEP-2207](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2207)), and clarifies scope accumulation during step-up ([SEP-2350](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2350)) and the `.well-known` discovery suffix ([SEP-2351](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2351)).\n\n## Roots, Sampling, and Logging Are Deprecated\n\nThree core features are deprecated under the new feature lifecycle policy ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)):\n\nFeature\n\nReplacement\n\nRoots\n\n[Tool parameters](https://modelcontextprotocol.io/specification/draft/server/tools), resource URIs, or server configuration\n\nSampling\n\nDirect integration with LLM provider APIs\n\nLogging\n\n`stderr` for stdio transports; [OpenTelemetry](https://opentelemetry.io/) for structured observability\n\nThese 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.\n\n## Full JSON Schema 2020-12 for Tools\n\nTool `inputSchema` and `outputSchema` are lifted to full [JSON Schema 2020-12](https://json-schema.org/draft/2020-12) ([SEP-2106](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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.\n\nSeparately, the error code for a missing resource changes from the MCP-custom `-32002` to the JSON-RPC standard `-32602` Invalid Params ([SEP-2164](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2164)). If your client matches on the literal `-32002` value, update it.\n\n## How the Protocol Evolves From Here\n\nThis release contains breaking changes. We don’t intend for that to be the norm.\n\nThree governance SEPs in this release are designed so that future revisions can evolve the protocol without breaking core capabilities. The [feature lifecycle policy](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596) 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](https://github.com/modelcontextprotocol/conformance) ([SEP-2484](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2484)), which is the same suite the new [SDK tier system](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1777) scores official SDKs against.\n\nThe 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.\n\n## Release Timeline and Validation\n\nThe 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](https://modelcontextprotocol.io/docs/sdk), Tier 1 SDKs are expected to ship support within this window.\n\nThe full release candidate is in the [draft specification](https://modelcontextprotocol.io/specification/draft), and the [changelog](https://modelcontextprotocol.io/specification/draft/changelog) will list every change against `2025-11-25`.\n\nIf you find a problem, open an issue in the [specification repository](https://github.com/modelcontextprotocol/modelcontextprotocol/issues). For implementation questions, the relevant [Working Group](https://modelcontextprotocol.io/community/working-interest-groups) channel in the [contributor Discord](https://modelcontextprotocol.io/community/communication#discord) is the fastest path to an answer.\n\n## Looking Ahead\n\nThis 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.\n\nThank 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.","publishedAt":"2026-05-21T09:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.438Z","url":"https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/","media":[],"coverageCount":0},{"id":"rel_srUFRrpUf6SujR_6e92tb","version":null,"type":"feature","title":"Expanding the MCP Maintainer Team","summary":"Clare Liguori, a Senior Principal Engineer at AWS working on Kiro and the Strands Agents SDK, joins the Core Maintainer group, and Den Delimarsky steps up from Core Maintainer to Lead Maintainer alongside the existing lead. Delimarsky's work spans MCP authorization and security, including the authorization specification, RFC 8707 Resource Indicators, and the 2025-11-25 specification release.","titleGenerated":"MCP adds Clare Liguori as Core Maintainer and Den Delimarsky as Lead Maintainer","titleShort":"MCP expands maintainer team; Delimarsky steps up to lead","breaking":"unknown","importance":2,"content":"I’m happy to share two updates to the maintainer team: **Clare Liguori** is joining the [Core Maintainer](https://modelcontextprotocol.io/community/governance#current-core-maintainers) group, and **Den Delimarsky** is joining me as a [Lead Maintainer](https://modelcontextprotocol.io/community/governance#current-lead-maintainers).\n\nWhen we [introduced the MCP governance model](/posts/2025-07-31-governance-for-mcp/) 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)](/posts/2025-12-09-mcp-joins-agentic-ai-foundation/), and a steady increase in SEP volume, and these changes give the project the leadership capacity it needs for what comes next.\n\n## Welcoming Clare Liguori as Core Maintainer\n\n\n\nI’m pleased to welcome [Clare Liguori](https://github.com/clareliguori) to the [Core Maintainer](https://modelcontextprotocol.io/community/governance#current-core-maintainers) team.\n\nClare is a Senior Principal Engineer at Amazon Web Services, where she works on agentic AI developer tooling. Her current focus is [Kiro](https://kiro.dev/) 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.\n\nClare has been bringing that depth of developer-tooling and agent-runtime experience directly into MCP’s design work, particularly the discussions around [unsolicited tasks](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2229), the agent execution model, and the [Triggers & Events working group](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2459). 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.\n\nWelcome, Clare!\n\n## Den Delimarsky Joins as Lead Maintainer\n\n\n\n[Den Delimarsky](https://github.com/localden) is stepping up from Core Maintainer to Lead Maintainer, joining me in that role.\n\nDen 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.\n\nDen’s work is most visible in authorization and security. He co-authored the [authorization specification](https://modelcontextprotocol.io/specification/draft/basic/authorization), brought [RFC 8707 Resource Indicators](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/734) into the spec, and has continued to build on it through [SEP-835](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/835), [SEP-1024](https://modelcontextprotocol.io/seps/1024-mcp-client-security-requirements-for-local-server-), and the [SEP-2350](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2350) family of proposals, among others. He also led the [2025-11-25 specification release](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1887), co-leads the Security Interest Group, and built [a contribution tracker](https://localden.github.io/mcp-repo-data-tracker/) that gives SDK and spec maintainers a birds-eye view of activity across the project’s repositories.\n\nI’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.\n\n## What’s Next\n\nMCP 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.\n\nWith 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](https://modelcontextprotocol.io/community/governance) explain how the project is organized, the [Contributor Ladder](https://modelcontextprotocol.io/community/contributor-ladder) shows how people grow into these roles, the [roadmap](https://modelcontextprotocol.io/development/roadmap) shows where we’re headed, and our [Discord](https://modelcontextprotocol.io/community/communication#discord) is the best place to talk to the people working on it. Come build with us.","publishedAt":"2026-04-08T00:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.524Z","url":"https://blog.modelcontextprotocol.io/posts/2026-04-08-maintainer-update/","media":[],"coverageCount":0},{"id":"rel_9Bu9b80g3-ym4eoSURGAp","version":null,"type":"feature","title":"Understanding MCP Extensions","summary":"The post explains that MCP is structured in three layers — core specification, projects like the Registry and Inspector, and extensions — and that extensions are strictly additive patterns built on existing MCP mechanisms, so a client or server that doesn't recognize one skips it during negotiation and the baseline protocol keeps working. MCP Apps, the first official extension, went GA in January 2026 with support in ChatGPT, Claude, VS Code, and Goose, and OAuth Client Credentials and Enterprise-Managed Authorization auth extensions are live.","titleGenerated":"MCP publishes guide to extensions for layering UI, auth, and domain features","titleShort":"Guide explains MCP extensions as additive layers","breaking":"unknown","importance":3,"content":"You’ve built an MCP server that works quite well, but now you’re wondering: *How do I add richer UI elements? Custom auth flows? What about domain-specific conventions, like those for finance or healthcare?*\n\nThis 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.\n\nIn 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.\n\n## How MCP is structured\n\nIt helps to think of MCP in three layers:\n\n- **MCP core specification:** [The protocol itself](https://modelcontextprotocol.io/specification/latest). This is how clients and servers talk to each other. It also represents the absolute minimum bar for client and server interoperability.\n- **MCP projects:** Supporting infrastructure like the [Registry](https://registry.modelcontextprotocol.io/), that helps developers discover MCP servers, or [Inspector](https://modelcontextprotocol.io/docs/tools/inspector), that makes MCP server testing and debugging easier.\n- **MCP extensions:** Optional patterns that developers can adopt for specialized use cases, built on top of the MCP core specification.\n\nExtensions 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.\n\nThe [Extensions documentation](https://modelcontextprotocol.io/extensions/overview) covers the full details — including extension identifiers, capability negotiation during the initialization handshake, and the SEP (Specification Enhancement Proposal) process for proposing new ones.\n\nHere’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.\n\nIn practice, a few of these patterns have already emerged — some now formalized as official extensions, others still exploratory:\n\n- **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](https://modelcontextprotocol.io/extensions/apps/overview) enables. It’s the first official MCP extension and [went GA in January 2026](https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/), with support already live in ChatGPT, Claude, VS Code, Goose, and [more](https://modelcontextprotocol.io/extensions/client-matrix).\n- **Authorization extensions:** Need machine-to-machine auth without a user in the loop, or centralized enterprise IdP control? The [auth extensions](https://modelcontextprotocol.io/extensions/auth/overview) layer these on top of MCP’s core OAuth framework — OAuth Client Credentials and Enterprise-Managed Authorization are both live today.\n- **Domain-specific extensions:** Community groups are already exploring conventions for verticals like financial services, where developers might want standardized ways to handle compliance metadata.\n\nAnother 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.\n\nExtensions 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.\n\n### How extensions are governed\n\nExtensions are community-driven, and **all of them are optional**. Developers adopt what makes sense for their use case.\n\nAt 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](https://github.com/modelcontextprotocol) where they’re maintained collaboratively, following the [Extensions Track SEP process](https://modelcontextprotocol.io/seps/2133-extensions).\n\nBeyond officially-supported extensions, community members and working groups are also free to define their own extensions for any custom needs.\n\n### A note on proprietary integrations\n\nSome 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.\n\n## Get started\n\nIf you’re building on MCP and want to explore extensions:\n\n- **Read the docs:** The [Extensions overview](https://modelcontextprotocol.io/extensions/overview) covers identifiers, negotiation, governance, and the full list of official extensions.\n- **Build an MCP App:** Follow the [MCP Apps quickstart](https://modelcontextprotocol.io/extensions/apps/build) to ship an interactive UI that works across supporting clients today.\n- **Check client support:** See the [Extension Support Matrix](https://modelcontextprotocol.io/extensions/client-matrix) for which clients already implement which extensions.\n- **Propose your own:** If you have an idea for a new extension, the [SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines) walk you through opening an Extensions Track SEP.\n\n## Thank you\n\nThis post wouldn’t exist without the [MCP community](https://modelcontextprotocol.io/community/communication). The ideas here grew out of countless conversations - working group calls, GitHub threads, extension proposals, and plenty of back-and-forth in [Discord](https://modelcontextprotocol.io/community/communication#discord).\n\nTo everyone who’s contributed ideas, challenged our initial assumptions, and helped shape where this is all going: thank you.\n\nWe’ll keep sharing updates here on the blog and in the [public repos](https://github.com/modelcontextprotocol). See you there.","publishedAt":"2026-03-11T00:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.524Z","url":"https://blog.modelcontextprotocol.io/posts/2026-03-11-understanding-mcp-extensions/","media":[],"coverageCount":0},{"id":"rel_4QMKSwujfCdhyN5wJt1H7","version":null,"type":"feature","title":"The 2026 MCP Roadmap","summary":"The 2026 MCP roadmap drops release milestones in favor of four priority areas driven by Working Groups: transport evolution and scalability, agent communication, governance maturation, and enterprise readiness. SEPs aligned with these areas get expedited review, and no additional official transports will be added this cycle.","titleGenerated":"MCP 2026 roadmap reorganizes around four working-group priority areas","titleShort":"MCP 2026 roadmap shifts from releases to priority areas","breaking":"unknown","importance":4,"content":"MCP’s [current spec release](https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/) came out in November 2025. We haven’t cut a new version since, but the project hasn’t stood still. Over the past year MCP has moved well past its origins as a way to wire up local tools. It now runs in production at companies large and small, powers agent workflows, and is shaped by a growing community through Working Groups, [Spec Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines) (SEPs), and a formal governance process. None of that is news, but it’s the foundation we’re building on.\n\nWe 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](https://modelcontextprotocol.io/development/roadmap) that lays out where we’re headed.\n\nIf you read the [January update](/posts/2026-01-22-core-maintainer-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.\n\n## From Releases to Working Groups\n\nPrevious 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.\n\n[Working and Interest Groups](https://modelcontextprotocol.io/community/working-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.\n\nThis 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.\n\n## The Priority Areas\n\nCore 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.\n\n### Transport Evolution and Scalability\n\nStreamable 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.\n\nThe 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.\n\nOne 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](https://modelcontextprotocol.io/community/design-principles).\n\n### Agent Communication\n\nThe Tasks primitive ([SEP-1686](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/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.\n\nThis 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.\n\n### Governance Maturation\n\nRight now, every SEP requires full [Core Maintainer](https://modelcontextprotocol.io/community/sep-guidelines) 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.\n\nThe 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.\n\n### Enterprise Readiness\n\nEnterprises are deploying MCP and running into a predictable set of problems: audit trails, SSO-integrated auth, gateway behavior, and configuration portability.\n\nThis 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.\n\nA dedicated Enterprise WG does not yet exist. If you work in enterprise infrastructure and want to lead or join one, the [Working Groups page](https://modelcontextprotocol.io/community/working-interest-groups) explains how to get started. We also recommend joining the [contributor Discord](https://modelcontextprotocol.io/community/communication#discord) to make sure you’re not duplicating work or going solo on new proposals.\n\nWe 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.\n\n## SEP Prioritization: What It Means for Contributors\n\nOne of the most practical additions to the roadmap is explicit guidance on how SEP review capacity gets allocated.\n\nThe 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.\n\nIf you’re considering writing a SEP, start with the [SEP Guidelines](https://modelcontextprotocol.io/community/sep-guidelines). Once you’re familiar with those:\n\n1. **Check whether your proposed change maps to one of the priority areas**. If it does not, be prepared for delays in reviews.\n2. **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.\n\n## On the Horizon\n\nNot 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.\n\nThese 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.\n\nSome of these already have active proposals in review, such as [SEP-1932 (DPoP)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1932) and [SEP-1933 (Workload Identity Federation)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1933). Others, like triggers and event-driven updates, would benefit from a new Working Group.\n\n## Get Involved\n\nEvery 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:\n\n- **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](https://modelcontextprotocol.io/community/working-interest-groups) page lists what’s active and how to connect.\n- **Propose a SEP**: SEPs are how changes to the protocol get proposed and reviewed. The [SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines) walk through the process.\n- **Start an extension**: Extensions let us experiment with new capabilities outside the core spec. You can learn more in our [official Extensions documentation](https://modelcontextprotocol.io/extensions/overview).\n\nIf you’re not sure where to start, the easiest first step is to join a Working Group meeting and introduce yourself.\n\nWe’re excited to build the protocol together!","publishedAt":"2026-03-09T09:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.580Z","url":"https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/","media":[],"coverageCount":0},{"id":"rel_IwiiQu6LgBY0qsK0uAu7n","version":null,"type":"feature","title":"MCP Apps - Bringing UI Capabilities To MCP Clients","summary":"MCP Apps are live as the first official MCP extension, letting tools declare a `_meta.ui.resourceUri` that points to a `ui://` resource the host renders in a sandboxed iframe with bidirectional JSON-RPC over postMessage. ChatGPT, Claude, Goose, and VS Code have shipped support, and the `@modelcontextprotocol/ext-apps` package provides an App class for building them.","titleGenerated":"MCP Apps extension ships interactive UI components for MCP clients","titleShort":"MCP Apps: tools now return interactive UI in the conversation","breaking":"unknown","importance":4,"content":"Today, we’re announcing that **MCP Apps are now live as an official MCP extension**. Tools can now return interactive UI components that render directly in the conversation: dashboards, forms, visualizations, multi-step workflows, and more. This is the first official MCP extension, and it’s ready for production.\n\n[Video](https://www.youtube.com/watch?v=bluAmTHoEow)\n\n.youtube-container { position: relative; width: 100%; padding-bottom: 56.25%; margin: 24px 0; } .youtube-container iframe { position: absolute; top: 0; left: 0; width: 100%; height: 100%; border-radius: 8px; }\n\nWe proposed MCP Apps [last November](https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/), building on the amazing work of [MCP-UI](https://mcpui.dev) and the [OpenAI Apps SDK](https://developers.openai.com/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.\n\nSince 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.\n\n[Get Started with MCP Apps →](https://apps.extensions.modelcontextprotocol.io/api/documents/Quickstart.html) .mcp-button { display: inline-block; padding: 8px 16px; font-size: 14px; font-weight: 500; text-decoration: none; border-radius: 4px; transition: all 0.2s ease; margin: 12px 0; background-color: #1a1a1a; color: #ffffff; border: 1px solid #333; } .mcp-button:hover { background-color: #333; color: #ffffff; } .mcp-button-arrow { margin-left: 6px; transition: transform 0.2s ease; display: inline-block; } .mcp-button:hover .mcp-button-arrow { transform: translateX(3px); } .dark .mcp-button { background-color: #ffffff; color: #1a1a1a; border: 1px solid #e5e5e5; } .dark .mcp-button:hover { background-color: #f0f0f0; color: #1a1a1a; }\n\n## **What Are MCP Apps?**\n\nMCP 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.\n\n\n\nHere are a few scenarios where MCP Apps shine:\n\n- **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.\n- **Configuration wizards**: A deployment tool presents a form with dependent fields. Selecting “production” reveals additional security options; selecting “staging” shows different defaults.\n- **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.\n- **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.\n\nThese interactions would be less smooth as text exchanges, whereas MCP Apps make them natural - it’s like using any other UI-based web app.\n\n## **How It Works**\n\nThe architecture of MCP Apps relies on two key MCP primitives:\n\n1. **Tools with UI metadata**: Tools include a `_meta.ui.resourceUri` field pointing to a UI resource\n2. **UI Resources**: Server-side resources served via the `ui://` scheme containing bundled HTML/JavaScript\n\n```javascript\n// Tool with UI metadata\n{\n name: \"visualize_data\",\n description: \"Visualize data as an interactive chart\",\n inputSchema: { /* ... */ },\n _meta: {\n ui: {\n resourceUri: \"ui://charts/interactive\"\n }\n }\n}\n\n```\n\nThe host fetches the resource, renders it in a sandboxed iframe, and enables bidirectional communication via JSON-RPC over `postMessage`.\n\n## **Why MCP Apps?**\n\nMCP 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.\n\nConsider 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.\n\nMCP 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.\n\n## **The App API**\n\nTo build new MCP Apps, developers can use the [`@modelcontextprotocol/ext-apps`](https://www.npmjs.com/package/@modelcontextprotocol/ext-apps) package, which provides an `App` class for UI-to-host communication:\n\n```javascript\nimport { App } from \"@modelcontextprotocol/ext-apps\";\n\nconst app = new App();\nawait app.connect();\n\n// Receive tool results from the host\napp.ontoolresult = (result) => {\n renderChart(result.data);\n};\n\n// Call server tools from the UI\nconst response = await app.callServerTool({\n name: \"fetch_details\",\n arguments: { id: \"123\" },\n});\n\n// Update model context\nawait app.updateModelContext({\n content: [{ type: \"text\", text: \"User selected option B\" }],\n});\n\n```\n\nBecause 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.\n\n## **Security Model**\n\nRunning UI from MCP servers means running code you didn’t write within your MCP host. MCP Apps handles this through multiple layers:\n\n- **Iframe sandboxing**: All UI content runs in sandboxed iframes with restricted permissions\n- **Pre-declared templates**: Hosts can review HTML content before rendering\n- **Auditable messages**: All UI-to-host communication goes through loggable JSON-RPC\n- **User consent**: Hosts can require explicit approval for UI-initiated tool calls\n\nIf 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.\n\n## **The Future of Agentic UI Frameworks**\n\n[MCP-UI](https://mcpui.dev/) and [OpenAI Apps SDK](https://developers.openai.com/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.\n\nMCP-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.\n\n## **Client Support**\n\nMCP Apps are supported in:\n\n- **Claude** - available today both on web and desktop experiences\n- **Goose** - [available today](https://goose-docs.ai/docs/tutorials/building-mcp-apps/)\n- **Visual Studio Code** - available in [Visual Studio Code Insiders](https://code.visualstudio.com/insiders)\n- **ChatGPT** - starting this week\n\nFor 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.\n\n> “*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.*”\n> \n> - **David Soria Parra**, Co-Creator of MCP and Member of Technical Staff, [Anthropic](https://www.anthropic.com/)\n\n> “*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.*”\n> \n> - **Nick Cooper**, Member of Technical Staff, [OpenAI](https://openai.com/)\n\n> “*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.*\n> \n> *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.*”\n> \n> - **Andrew Harvard**, Design Engineer, Agentic UX, [Block](https://block.xyz/)\n\n> *“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.”*\n> \n> - **Harald Kirschner**, Principal Product Manager, VS Code, [Microsoft](https://www.microsoft.com/en-us)\n\n> “*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.*”\n> \n> - **Denis Shiryaev**, Head of AI DevTools Ecosystem, [JetBrains](https://www.jetbrains.com/)\n\n> *“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.“*\n> \n> - **Clare Liguori**, Senior Principal Engineer, [AWS](https://aws.amazon.com/)\n\n> “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.”\n> \n> - **Anshul Ramachandran**, Product Lead, Antigravity, [Google DeepMind](https://deepmind.google/)\n\nThis is just the starting lineup, and adding support to a new client is as easy as following the [implementation guide](https://modelcontextprotocol.io/docs/extensions/apps).\n\n## **Get Started**\n\nThe [ext-apps repository](https://github.com/modelcontextprotocol/ext-apps) includes the SDK and working examples: [`threejs-server`](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/threejs-server) for 3D visualization, [`map-server`](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/map-server) for interactive maps, [`pdf-server`](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/pdf-server) for document viewing, [`system-monitor-server`](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/system-monitor-server) for real-time dashboards, [`sheet-music-server`](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/sheet-music-server) for music notation, and [many more](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples).\n\nPick one close to what you’re building and start from there!\n\n\n\n### **Resources**\n\n- **Documentation**: [MCP Apps Guide](https://modelcontextprotocol.io/docs/extensions/apps)\n- **Quickstart**: [Getting Started with MCP Apps](https://apps.extensions.modelcontextprotocol.io/api/documents/Quickstart.html)\n- **SDK**: [`@modelcontextprotocol/ext-apps`](https://www.npmjs.com/package/@modelcontextprotocol/ext-apps)\n- **Examples**: [ext-apps repository](https://github.com/modelcontextprotocol/ext-apps)\n\n### [**Claude.ai**](http://Claude.ai) **Feedback**\n\nIf you’re building MCP Apps for [Claude.ai](http://Claude.ai) and encounter issues with our implementation, please report them at [github.com/anthropics/claude-ai-mcp](https://github.com/anthropics/claude-ai-mcp). This helps us improve the experience for everyone.\n\n### **ChatGPT Apps SDK Feedback**\n\nIf you’re building apps with the ChatGPT Apps SDK and run into issues or have questions, please post in the [ChatGPT Apps category](https://community.openai.com/c/chatgpt-apps-sdk/42) 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.\n\n## **Acknowledgements**\n\nMCP Apps is the result of collaboration across multiple teams and communities.\n\n**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.\n\n**Nick Cooper** at OpenAI helped deliver the OpenAI Apps SDK, enabling everyone to go beyond text in their interactions with Large Language Models.\n\n**Sean Strong**, **Olivier Chafik**, **Anton Pidkuiko**, and **Jerome Swannack** from Anthropic helped steer the initiative from proposal to production.\n\nThe **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.\n\nThank you to everyone who contributed. Now go build something.","publishedAt":"2026-01-26T00:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.580Z","url":"https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/","media":[{"type":"video","url":"https://www.youtube.com/watch?v=bluAmTHoEow"},{"type":"video","url":"https://i.ytimg.com/vi/bluAmTHoEow/hqdefault.jpg","alt":"Your tools are now interactive in Claude","linkUrl":"https://www.youtube.com/watch?v=bluAmTHoEow","r2Key":"releases/5469f220dd6a8dffec389d1907fe5d57d9b9d29579fefb16b99c23cc4eae443a.jpg","r2Url":"https://media.releases.sh/releases/5469f220dd6a8dffec389d1907fe5d57d9b9d29579fefb16b99c23cc4eae443a.jpg"}],"coverageCount":0},{"id":"rel_sR9tdV8fo5E81FyM5xMUX","version":null,"type":"feature","title":"January MCP Core Maintainer Update","summary":"Inna Harper and Basil Hosmer are stepping away from the Core Maintainer team, while Peter Alexander (Anthropic), Caitie McCaffrey (Microsoft), and Kurtis Van Gent (Google Cloud Databases) join it. The post also previews active SEPs including a DPoP extension for authentication, multi-turn SSE for transport, and Server Cards for discovery.","titleGenerated":"MCP Core Maintainer team adds Peter Alexander, Caitie McCaffrey, Kurtis Van Gent as Inna Harper and Basil Hosmer depart","titleShort":"MCP Core Maintainer team adds three, loses two","breaking":"unknown","importance":3,"content":"A lot has happened since we first released MCP. We wrapped up 2025 with a [major spec update](/posts/2025-11-25-first-mcp-anniversary/) and the momentum hasn’t slowed down. None of it would have happened without the community: every PR, every issue filed, every server and client built. That energy is what keeps MCP moving forward.\n\nTo keep that momentum going, the [Core Maintainer](https://modelcontextprotocol.io/community/governance#current-core-maintainers) team is evolving as well.\n\n## Departing Core Maintainers\n\nFirst, some news. **Inna Harper** and **Basil Hosmer** will be stepping away from the Core Maintainer team to focus on other projects.\n\nInna 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.\n\nThank you both for your contributions and your dedication to the project. MCP is better because of you.\n\n## Welcoming New Maintainers\n\nWe’re thrilled to welcome three new Core Maintainers to the team. They’ve already been active in MCP discussions, reviewing [Spec Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines) (SEPs), and helping shape the direction of the protocol.\n\n### Peter Alexander\n\n\n\n**Peter Alexander** is a Member of Technical Staff at Anthropic on the Model Context Protocol team.\n\nPrior 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.\n\nPeter has authored several SEPs including the [Extensions framework](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2133) and [Resource Contents Metadata](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2093), and has been an active reviewer and contributor to our SDKs, proposals around governance, roadmap, and specification changes.\n\n### Caitie McCaffrey\n\n\n\n**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.\n\nPreviously, 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.\n\nCaitie has been reviewing and helping us craft our governance and transport proposals, bringing her distributed systems expertise to protocol design discussions.\n\n### Kurtis Van Gent\n\n\n\n**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.\n\nKurtis has been driving the [Transport Working Group](https://github.com/modelcontextprotocol/transports-wg), which authored the accepted [request payload decoupling](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1319) SEP and is leading the [stateless protocol](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1442) proposal. His focus on scalability and fault tolerance has shaped key discussions around how MCP evolves.\n\nWelcome to the team, Peter, Caitie, and Kurtis.\n\n## Looking Ahead\n\nIf 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](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1932) for authentication, [multi-turn SSE](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1858) for transport, and [Server Cards](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2127) 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.\n\nMCP 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.\n\nIf you want to be part of it, check out our [governance docs](https://modelcontextprotocol.io/community/governance) or see how to [get started with MCP contributions](https://modelcontextprotocol.io/community/communication). Come build with us.","publishedAt":"2026-01-23T00:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.580Z","url":"https://blog.modelcontextprotocol.io/posts/2026-01-22-core-maintainer-update/","media":[],"coverageCount":0},{"id":"rel_PK0yH_bc7UlI_tHzJWjJo","version":null,"type":"feature","title":"Exploring the Future of MCP Transports","summary":"The Transport Working Group proposes replacing the initialize handshake with per-request state and a discovery mechanism, moving sessions to the data model layer, and adding Server Cards at a standardized /.well-known/mcp.json endpoint. The roadmap also covers chat-style elicitation and sampling responses, dedicated subscription streams with TTLs and ETags, and exposing JSON-RPC routing info via HTTP paths or headers.","titleGenerated":"MCP outlines roadmap to make Streamable HTTP transport stateless","titleShort":"MCP roadmap: stateless transport, explicit sessions","breaking":"unknown","importance":4,"content":"When MCP first launched in November of 2024, quite a few of its users relied on local environments, connecting clients to servers over [STDIO](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#stdio). As MCP became the go-to standard for LLM integrations, community needs evolved, leading to the build-out of infrastructure around remote servers. There’s now growing demand for distributed deployments that can operate at scale.\n\nThe [Streamable HTTP](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#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.\n\nSome of these challenges include:\n\n- **Infrastructure Complexity:** Load balancers and API gateways must parse full JSON-RPC payloads to route traffic, rather than using standard HTTP patterns.\n- **Scaling Friction:** Stateful connections force “sticky” routing that pins traffic to specific servers, preventing effective auto-scaling.\n- **High Barrier for Simple Tools:** Developers building simple, ephemeral tools are often required to manage complex backend storage to support basic multi-turn interactions.\n- **Ambiguous Session Scope:** There is no predictable mechanism for defining where a conversation context starts and ends across distributed systems.\n\n## Roadmap\n\nOver the past few months, the Transport Working Group has worked together with the community and MCP Core Maintainers to develop solutions to these challenges.\n\nIn this post we share the roadmap for evolving the Streamable HTTP transport and invite community feedback to help shape the future of MCP transports.\n\n### A Stateless Protocol\n\nMCP 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.\n\nWe 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.\n\nWe are exploring ways to make MCP stateless by:\n\n- Replacing the [`initialize` handshake](https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle#initialization) and sending the shared information with each request and response instead.\n- Providing a `discovery` mechanism for clients to query server capabilities if they need the information early, for scenarios such as UI hydration.\n\nThese changes enable a more dynamic model where clients can optimistically attempt operations and receive clear error messages if a capability is unsupported.\n\n> **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.\n\n### Elevating Sessions\n\nCurrently, 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.\n\nWe are looking at moving sessions to the *data model layer*, making them explicit rather than implicit.\n\nThis 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.\n\nThis 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.\n\n### Elicitations and Sampling\n\nTwo MCP features are central to a few of the modern AI workflows: [Elicitations](https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation), which request human input, and [Sampling](https://modelcontextprotocol.io/specification/2025-11-25/client/sampling), which enable agentic LLM interactions.\n\nSupporting 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.\n\nTo 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.\n\n### Update Notifications and Subscriptions\n\nMCP is dynamic by design - [tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools), [prompts](https://modelcontextprotocol.io/specification/2025-11-25/server/prompts), and [resources](https://modelcontextprotocol.io/specification/2025-11-25/server/resources) can change during operation. Today, servers send `ListChangedNotification` messages to clients as a hint to invalidate their caches.\n\nWe’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.\n\nTo 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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag)) to data. This would let clients make intelligent caching decisions independently of the notification stream, significantly improving reliability.\n\n### JSON-RPC Envelopes\n\nMCP 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.\n\nWhile 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.\n\n### Server Cards\n\nToday, 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.\n\nWe’re exploring the direction of introducing [MCP Server Cards](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1649): 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.\n\n### Official and Custom Transports\n\nTo 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.\n\nWe 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.\n\nFor teams with specialized requirements, the MCP Specification supports [Custom Transports](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#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.\n\n## Summary\n\nThese 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.\n\nFor 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.\n\n## Next Steps\n\nWork is already underway. Our goal is to finalize the required [Spec Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines) (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.\n\nWe want your input. Join us in the [MCP Contributors Discord server](https://modelcontextprotocol.io/community/communication#discord), or engage directly with transport-related SEPs in the [Model Context Protocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol/pulls).\n\nThis 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!","publishedAt":"2025-12-19T09:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.638Z","url":"https://blog.modelcontextprotocol.io/posts/2025-12-19-mcp-transport-future/","media":[],"coverageCount":0},{"id":"rel_1I_6FmLr9kJgqRsNaySkc","version":null,"type":"feature","title":"SEPs Are Moving to Pull Requests","summary":"Specification Enhancement Proposals are now created as pull requests to the seps/ directory instead of GitHub issues, so the PR number becomes the SEP number and git tracks every revision. Sponsors now update the Status field in the SEP markdown file, with existing issue-based SEPs welcome to keep their current workflow or migrate.","titleGenerated":"MCP moves SEP submissions from GitHub issues to pull requests","titleShort":"SEPs now submitted as pull requests, not issues","breaking":"unknown","importance":2,"content":"We’re updating how Specification Enhancement Proposals (SEPs) are submitted and managed. Starting today, SEPs will be created as pull requests to the [`seps/` directory](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps) instead of GitHub issues.\n\n## Why the Change?\n\nWhen we [introduced SEPs in July](https://blog.modelcontextprotocol.io/posts/2025-07-31-governance-for-mcp/), 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:\n\n**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.\n\n**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.\n\nThe new PR-based approach, inspired by [Python’s PEP process](https://peps.python.org/), solves both problems.\n\n## How It Works\n\nThe new workflow will be familiar if you’ve submitted pull requests on GitHub before:\n\n1. **Draft your SEP** as a markdown file named `0000-your-feature.md` using the [SEP template](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/TEMPLATE.md)\n \n2. **Create a pull request** adding your SEP to the `seps/` directory\n \n3. **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\n \n4. **Find a sponsor** from our [maintainer list](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md) to shepherd your proposal\n \n5. **Iterate** on feedback directly in the PR\n \n\nThat’s it. The PR number becomes the SEP number, discussion happens in one place, and git tracks every revision.\n\n## What About Status?\n\nOne 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.\n\nStatus transitions work the same as before: `Draft` to `In-Review` to `Accepted` to `Final`, with the sponsor managing each transition as the proposal progresses.\n\n## Getting Started\n\nReady to propose a change to MCP? Here’s what you need to know:\n\n**For new SEPs:**\n\n- Read the latest [SEP Guidelines](https://modelcontextprotocol.io/community/sep-guidelines)\n- Use the [SEP template](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/README.md#sep-file-structure) to create your proposal\n- Browse existing SEPs in the [`seps/` directory](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps) for examples\n- Follow the workflow described above\n\n**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:\n\n1. Create a markdown file using the SEP template, starting with `0000-your-feature.md`\n2. Copy and adapt your proposal content to fit the template structure\n3. Submit a pull request to the `seps/` directory\n4. Rename the file using your new PR number (e.g., PR #1900 becomes `1900-your-feature.md`)\n5. Close the original issue with a link to the new PR\n\nThe 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.\n\nAs always, if you’re unsure whether your idea warrants a SEP, start a conversation on [Discord](https://modelcontextprotocol.io/community/communication#discord) or [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions). We’re happy to help you figure out the right path forward.\n\n## Thank You\n\nThis 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.","publishedAt":"2025-11-28T11:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.638Z","url":"https://blog.modelcontextprotocol.io/posts/2025-11-28-sep-process-update/","media":[],"coverageCount":0},{"id":"rel_yw5yj5SaXdndAIT_cOP-l","version":null,"type":"feature","title":"One Year of MCP: November 2025 Spec Release","summary":"The Model Context Protocol marks its first anniversary alongside a new specification version, with the MCP Registry growing to close to two thousand server entries since September, a 407% increase. The post also covers the governance structure, working and interest groups, and partner commentary from GitHub, OpenAI, and Block.","titleGenerated":"MCP marks one year with November 2025 spec release","titleShort":"MCP hits one year with new spec release","breaking":"unknown","importance":3,"content":"Today, MCP turns **one year old**. You can check out the [original announcement blog post](https://www.anthropic.com/news/model-context-protocol) if you don’t believe us. It’s hard to imagine that a little open-source experiment, a **protocol to provide context to models**, became the de-facto standard for this very scenario in less than twelve months.\n\nBut 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.\n\n## A Year In\n\nWith 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).\n\nBut 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.\n\nHere are just a few of many (very many) MCP servers that you can try *today*:\n\n- Notion [built an MCP server](https://github.com/makenotion/notion-mcp-server) to help you manage your notes.\n- Stripe has a [pretty extensive MCP server](https://docs.stripe.com/mcp#tools) to manage all kinds of payment workflows.\n- GitHub [built their own MCP server](https://github.com/github/github-mcp-server) to help developers automate their engineering processes.\n- Hugging Face [created an MCP server](https://github.com/huggingface/hf-mcp-server) to make model management and dataset search a breeze.\n- Postman [built their MCP server](https://github.com/postmanlabs/postman-mcp-server) to help automate API testing workflows.\n\nAnd there’s so much more to discover in the MCP ecosystem! That’s why we also launched the [MCP Registry](https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/) 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.\n\nThe ecosystem is blooming, adoption is growing, but what’s underpinning all of this?\n\n### Community & Governance\n\nMCP’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](https://github.com/ahujasid/blender-mcp)). 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.\n\n\n\nFrom the start, we believed that it was all about the **MCP community**. Our community rallied around the protocol, organizing events like [MCP Dev Summit](https://mcpdevsummit.ai/), [MCP Night](https://workos.com/mcp-night), [MCP Dev Days](https://developer.microsoft.com/en-us/reactor/series/S-1563/), and showing up at other marquee events like [AI Engineer World’s Fair](https://wf2025.ai.engineer/worldsfair/2025) to share what they learned and built.\n\n\n\nWe also nurtured large contributor communities on [Discord](https://modelcontextprotocol.io/community/communication) and on [GitHub](https://github.com/modelcontextprotocol/modelcontextprotocol), helping us debug issues, build amazing tools like the [MCP Inspector](https://github.com/modelcontextprotocol/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.\n\n\n\nReally, 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.\n\n\n\nTo keep this pace sustainable, we spent some time thinking through and putting together a [governance structure](https://blog.modelcontextprotocol.io/posts/2025-07-31-governance-for-mcp/). 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.\n\n\n\nOur 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](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1302/) set the stage for this).\n\n\n\nEven 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.\n\n\n\n## What Others Have To Say\n\nAs 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.\n\n> “*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.*”\n> \n> ✦ **Mario Rodriguez**, CPO, [GitHub](https://github.com/)\n\n> “*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.*”\n> \n> ✦ **Srinivas Narayanan**, CTO of B2B Applications, [OpenAI](https://openai.com/)\n\n> “*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.*”\n> \n> ✦ **Dhanji Prasanna**, CTO, [Block](https://block.xyz/)\n\n> “*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.*”\n> \n> ✦ **Asha Sharma**, President, CoreAI, [Microsoft](https://microsoft.com/)\n\n> “*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.*”\n> \n> ✦ **Julien Chaumond**, CTO, [Hugging Face](https://huggingface.co/)\n\n> “*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.*”\n> \n> ✦ **Harish Peri**, SVP & GM, AI Security, [Okta](https://okta.com)\n\n> “*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.*”\n> \n> ✦ **Swami Sivasubramanian**, VP, Agentic AI, [AWS](https://aws.amazon.com)\n\n> “*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.”*\n> \n> ✦ **Anna Berenberg**, Engineering Fellow, [Google Cloud](https://cloud.google.com/)\n\n> “*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*”\n> \n> ✦ **Shannon Williams**, President and Co-Founder, [Obot AI](https://obot.ai/); Organizer, [MCP Dev Summit](https://mcpdevsummit.ai/)\n\nOf 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.\n\n> “*As a community moderator and maintainer, I keep coming back to something [Donella Meadows](https://donellameadows.org/archives/dancing-with-systems/) 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.”*\n> \n> *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.*\n> \n> *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](https://github.com/cliffhall), who raises the bar for reviewing, testing, and giving feedback, and [Jonathan Hefner](https://github.com/jonathanhefner), who’s done the same for documentation.*\n> \n> *As Darren Shepard [recently put it](https://x.com/ibuildthecloud/status/1988695148843389151):*\n> \n> *‘People think the value of MCP is the protocol. The value is getting people to agree and do something.’*\n> \n> *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.*”\n> \n> ✦ **Ola Hungerford**, Principal Engineer, [Nordstrom](https://www.nordstrom.com/); MCP Maintainer and Community Lead\n\n> “*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.*\n> \n> *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.*\n> \n> *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.*\n> \n> *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.”*\n> \n> ✦ **Tadas Antanavicius**, Co-Creator, [PulseMCP](https://www.pulsemcp.com/); MCP Maintainer and Community Lead\n\nWe 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.\n\n## The November 2025 Release\n\nThe 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.\n\n### Support for Task-based Workflows\n\n**SEP:** [1686](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1686)\n\nTasks 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.\n\nTasks support a variety of states including `working`, `input_required`, `completed`, `failed`, and `cancelled`, allowing clients to effectively manage multi-step operations.\n\nSome noteworthy capabilities that this feature enables:\n\n- **Active polling**: Clients can check the status of ongoing work at any time.\n- **Result retrieval**: Results of completed tasks are accessible after the request has completed.\n- **Flexible lifecycle management**: Support for `working`, `input_required`, `completed`, `failed`, and `cancelled` states.\n- **Task isolation**: Proper security boundaries with session-based access control.\n\nFrom the multitude of MCP servers that we’ve seen out there, this is particularly helpful for scenarios such as the ones below.\n\n- Healthcare & life sciences data analysis that processes hundreds of thousands of data points\n- Enterprise automation platforms with complex multi-step workflows\n- Code migration tools that run for minutes or hours\n- Test execution platforms that need to stream logs from long-running suites\n- Deep research tools that spawn multiple agents internally\n- Multi-agent systems where agents can work concurrently\n\nTasks 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.\n\n### Simplified Authorization Flows\n\nOne of the top painpoints from the community when it comes to authorization has been [Dynamic Client Registration](https://www.rfc-editor.org/rfc/rfc7591), 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](https://modelcontextprotocol.io/docs/tutorials/security/authorization).\n\nTo 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.\n\nThe 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.\n\n**[SEP-991](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1296)** introduced a much more elegant solution to the problem - URL-based client registration using [OAuth Client ID Metadata Documents](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00) (you might’ve already seen our [blog post on this change from earlier this year](https://blog.modelcontextprotocol.io/posts/client_registration/)). 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.\n\nYou can learn more in the [Client ID Metadata Documents Flow](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents-flow) section of the [MCP authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization).\n\n### Security and Enterprise Features\n\nAs 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.\n\nWorking with security and authentication experts from across the community, we’ve developed a number of enhancements shipping with this release:\n\n- **[SEP-1024](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1024)**: Client security requirements for local server installation\n- **[SEP-835](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/835)**: Default scopes definition in authorization specification\n\nWe 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](https://github.com/modelcontextprotocol/registry/blob/main/docs/design/ecosystem-vision.md) that will help enterprises adopt *their own* MCP registries, with self-managed governance controls and security coverage.\n\nTo learn more about other upcoming auth and security improvements you can follow the [`auth`](https://github.com/modelcontextprotocol/modelcontextprotocol/issues?q=is%3Aissue%20state%3Aopen%20label%3Aauth) and [`security`](https://github.com/modelcontextprotocol/modelcontextprotocol/issues?q=is%3Aissue%20state%3Aopen%20label%3Asecurity) tags in the specification repository.\n\n### Extensions\n\nAs 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.\n\nTo 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.\n\nExtensions are:\n\n- **Optional**. Server and client implementors can choose to adopt these extensions.\n- **Additive**. Extensions do not modify or break core protocol functionality; they add new capabilities while preserving core protocol behavior.\n- **Composable**. Extensions are modular and designed to work together without conflicts, allowing implementations to adopt multiple extensions simultaneously.\n- **Versioned independently**. Extensions follow the core MCP versioning cycle but may adopt independent versioning as needed.\n\nYou might’ve already seen our announcement of the [MCP Apps Extension](https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/) proposal. In this specification release, we’re introducing a couple of other extensions that should help developers further.\n\n### Authorization Extensions\n\nTo 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**](https://github.com/modelcontextprotocol/ext-auth) (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.\n\nThe first two authorization extensions came on the heels of community feedback regarding some of the most-used authorization flows:\n\n- **[SEP-1046](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1046)**: OAuth client credentials support for machine-to-machine authorization\n- **[SEP-990](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/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.\n\nAs 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.\n\n### URL Mode Elicitation: Secure Out-of-Band Interactions\n\n**SEP:** [1036](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1036)\n\nAsking 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.\n\n**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.\n\nWe 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:\n\n- **Secure credential collection**: API keys and passwords never transit through the MCP client\n- **External OAuth flows**: MCP servers have a path to obtain third-party authorization without token passthrough\n- **Payment processing**: PCI-compliant financial transactions with secure browser contexts can now be done outside the client\n\nAll 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!\n\n### Sampling with Tools: Agentic Servers\n\n**SEP:** [1577](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1577)\n\nThis 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](https://modelcontextprotocol.io/specification/2025-06-18/client/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!\n\nNow that sampling with tools is available, this also means that all of the scenarios below are possible!\n\n- **Tool calling in sampling requests**: Servers can now include tool definitions and specify tool choice behavior\n- **Server-side agent loops**: Servers can implement sophisticated multi-step reasoning\n- **Parallel tool calls**: Support for concurrent tool execution\n- **Better context control**: The ambiguous `includeContext` parameter is being soft-deprecated in favor of explicit capability declarations\n\nAs 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.\n\n### Developer Experience Improvements\n\nOne 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.\n\n- **[SEP-986](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/986)**: Standardized format for tool names\n- **[SEP-1319](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1319)**: Decoupled request payload from RPC methods definition\n- **[SEP-1699](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1699)**: SSE polling via server-side disconnect for better connection management\n- **[SEP-1309](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1309)**: Improved specification version management for SDKs\n\n## Looking Forward\n\nThis release is backward compatible. Your existing implementations keep working. The new features are there when you need them.\n\nLooking 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.\n\nWe’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.\n\nThe [roadmap ahead](https://modelcontextprotocol.io/development/roadmap) 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.\n\nWhat 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.\n\nThe 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.\n\n## Get Started\n\nTo get started with all the new goodness in the latest MCP specification release, check out the following resources:\n\n- **Read the changelog**: All major changes are captured in our [Key Changes document](https://modelcontextprotocol.io/specification/2025-11-25/changelog)\n- **Get to know our docs**: The [MCP documentation](https://modelcontextprotocol.io/docs/getting-started/intro) is the source of truth for the all the inner workings of the protocol\n- **Join the discussion**: If you would like to contribute or engage with other MCP maintainers, start with our [GitHub repo](https://github.com/modelcontextprotocol/modelcontextprotocol) and [Discord](https://modelcontextprotocol.io/community/communication#discord)","publishedAt":"2025-11-25T00:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.692Z","url":"https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/","media":[],"coverageCount":0},{"id":"rel_MYp2P9UBiukqgI1mvJOUC","version":null,"type":"feature","title":"MCP Apps: Extending servers with interactive user interfaces","summary":"The MCP Apps Extension (SEP-1865) standardizes UI resources declared with a ui:// URI scheme, referenced in tool metadata via ui/resourceUri, and communicating with hosts over existing MCP JSON-RPC via postMessage. The initial spec supports only text/html rendered in sandboxed iframes, deferring external URLs, remote DOM, and native widgets to future iterations.","titleGenerated":"MCP proposes Apps Extension standardizing interactive UI in servers","titleShort":"MCP Apps Extension proposal brings interactive UI to servers","breaking":"unknown","importance":4,"content":"Today we’re introducing the proposal for the [MCP Apps Extension](https://github.com/modelcontextprotocol/ext-apps) ([SEP-1865](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865)) to standardize support for interactive user interfaces in the Model Context Protocol.\n\nThis extension addresses one of the most requested features from the MCP community and builds on proven work from [MCP-UI](https://github.com/idosal/mcp-ui) and [OpenAI Apps SDK](https://developers.openai.com/apps-sdk/) - the **ability for MCP servers to deliver interactive user interfaces to hosts**.\n\nMCP 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.\n\n\n\nThe 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.\n\n## Standardization for interactive interfaces\n\nCurrently, 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.\n\nFor 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.\n\nThe 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.\n\n## Building together\n\nThe [MCP-UI project](https://github.com/MCP-UI-Org/mcp-ui), created by [Ido Salomon](https://github.com/idosal) and [Liad Yosef](https://github.com/liady) 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](https://mcpui.dev/guide/client/overview), adopted at leading companies and projects such as Postman, Shopify, Hugging Face, Goose, and ElevenLabs.\n\nThe [OpenAI Apps SDK](https://developers.openai.com/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.\n\n\n\n## MCP Apps Extension specification\n\nWe’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.\n\n### Key design decisions\n\n#### Pre-declared resources\n\nUI templates are resources with the `ui://` URI scheme, referenced in tool metadata.\n\n```ts\n// Server registers UI resource\n{\n uri: \"ui://charts/bar-chart\",\n name: \"Bar Chart Viewer\",\n mimeType: \"text/html+mcp\"\n}\n\n// Tool references it in metadata\n{\n name: \"visualize_data_as_bar_chart\",\n description: \"Plots some data as a bar chart\",\n inputSchema: {\n type: \"object\",\n properties: {\n series: { type: \"array\", items: .... }\n }\n },\n _meta: {\n \"ui/resourceUri\": \"ui://charts/bar-chart\",\n }\n}\n\n```\n\nThis 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.\n\n#### MCP transport for communication\n\nInstead of inventing a custom message protocol, UI components communicate with hosts using existing MCP JSON-RPC base protocol over `postMessage`. This means that:\n\n- UI developers can use the standard `@modelcontextprotocol/sdk` to build their applications\n- All communication is structured and auditable\n- Future MCP features automatically work with the UI extension\n\n#### Starting with HTML\n\nThe initial extension specification supports only `text/html` content, rendered in sandboxed [iframes](https://developer.mozilla.org/docs/Web/HTML/Reference/Elements/iframe). This provides:\n\n- Universal browser support\n- Well-understood security model\n- Screenshot and preview generation capabilities\n- A clear baseline for future extensions\n\nOther content types such as external URLs, remote DOM, and native widgets are explicitly deferred to future iterations.\n\n#### Security-first\n\nHosting interactive content from MCP servers requires careful security consideration. The proposal addresses this through multiple layers:\n\n1. **Iframe sandboxing**: All UI content runs in sandboxed iframes with restricted permissions\n2. **Predeclared templates**: Hosts can review HTML content before rendering\n3. **Auditable messages**: All UI-to-host communication goes through loggable JSON-RPC\n4. **User consent**: Hosts can require explicit approval for UI-initiated tool calls\n\nThese mitigations create defense in depth against malicious servers while preserving the flexibility developers need.\n\n#### Backward compatibility\n\nMCP 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.\n\n## What’s next\n\nThe [UI Community Working Group](https://github.com/modelcontextprotocol-community/working-groups/issues/35) has been instrumental in shaping this proposal through extensive feedback and discussion. We have built an [early access SDK](https://github.com/modelcontextprotocol/ext-apps) to demonstrate the patterns and types described in the specification proposal. The [MCP-UI](https://mcpui.dev/) client and server SDKs support these patterns.\n\nIf you are interested in contributing to this effort, we invite you to:\n\n- Review the full specification in [SEP-1865](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865)\n- Share feedback and concerns in [GitHub Issues](https://github.com/MCP-UI-Org/mcp-ui/issues)\n- Join the discussion in the `#ui-wg` channel in the [MCP Contributors Discord](https://modelcontextprotocol.io/community/communication#discord)\n- Test prototype implementations and share your experience\n\n## Acknowledgements\n\nThis proposal wouldn’t exist without the work of the maintainers at MCP-UI, OpenAI, and Anthropic.\n\n**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.\n\n**Sean Strong**, **Olivier Chafik**, **Anton Pidkuiko**, and **Jerome Swannack** from Anthropic helped steer the initiative and drive the collaboration.\n\n**Nick Cooper**, **Alexei Christakis**, and **Bryan Ashley** from OpenAI have provided valuable direction from their experience building the Apps SDK.\n\nSpecial thanks to the **UI Community Working Group** members and everyone who contributed to the discussions that shaped this proposal.","publishedAt":"2025-11-21T22:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.692Z","url":"https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/","media":[],"coverageCount":0},{"id":"rel_tDdJ6GBR2vMKdmApWwaTh","version":null,"type":"feature","title":"Adopting the MCP Bundle format (.mcpb) for portable local servers","summary":"The MCP Bundle format, a ZIP archive containing a local MCP server and a manifest.json describing it, is now part of the Model Context Protocol project along with its specification, CLI tooling, and reference implementation. A bundle built for one MCP-compatible client should work in any other that implements the spec, letting developers distribute once across clients including Claude desktop, Claude Code, and MCP for Windows.","titleGenerated":"MCP project adopts MCP Bundle format (.mcpb) for portable local servers","titleShort":"MCP Bundle format now part of the MCP project","breaking":"unknown","importance":3,"content":"The [MCP Bundle format](https://github.com/modelcontextprotocol/mcpb) (MCPB) is now part of the [Model Context Protocol project](https://github.com/modelcontextprotocol). This distribution format simplifies how developers package and share local MCP servers, enabling users to install them across any compatible client, including the [Claude desktop app](https://claude.com/download), [Claude Code](https://claude.com/product/claude-code), and [MCP for Windows](https://learn.microsoft.com/windows/ai/mcp/servers/mcp-server-overview).\n\n## What are MCP Bundles?\n\nMCP 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.\n\nA basic bundle structure looks like:\n\n```text\nbundle.mcpb (ZIP file)\n├── manifest.json # Required: Bundle metadata and configuration\n├── server/ # Server implementation\n│ └── index.js\n├── node_modules/ # Bundled dependencies\n└── icon.png # Optional: Bundle icon\n\n```\n\nThe 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.\n\n## Why move MCPB to the MCP project?\n\nAnthropic 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](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md), [CLI tooling](https://github.com/modelcontextprotocol/mcpb/blob/main/CLI.md), and [reference implementation](https://github.com/modelcontextprotocol/mcpb/tree/main/examples) to the MCP project, we’re enabling:\n\n- **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.\n- **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.\n- **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.\n- **Shared community:** MCPB contributors can now collaborate in the open with the rest of the [MCP community](https://modelcontextprotocol.io/community/communication).\n\n## What this means for developers\n\nThis transition is mostly a logistical change, but also brings some benefits to implementers. For those that are building:\n\n- **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.\n- **Clients:** You can add support for MCP Bundles to your application using the open source toolchain. [The repository](https://github.com/modelcontextprotocol/mcpb) 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.\n\n## Getting started\n\nCheck out the repo to get started: [modelcontextprotocol/mcpb](https://github.com/modelcontextprotocol/mcpb). We encourage [feedback](https://github.com/modelcontextprotocol/mcpb/issues) and contributions!\n\n## Acknowledgements\n\nThanks to the MCP contributors and maintainers involved in making this happen, including:\n\n- [David Soria Parra](https://github.com/dsp-ant) (*MCP Lead Maintainer*)\n- [Adam Jones](https://github.com/domdomegg) (*MCP Maintainer*)\n- [Joan Xie](https://github.com/joan-anthropic) (*MCPB Maintainer*)\n- [Felix Rieseberg](https://github.com/felixrieseberg) (*MCPB Maintainer*)\n- [Alex Sklar](https://github.com/asklar) (*MCPB Maintainer*)","publishedAt":"2025-11-21T00:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.692Z","url":"https://blog.modelcontextprotocol.io/posts/2025-11-20-adopting-mcpb/","media":[],"coverageCount":0},{"id":"rel_Kcup-wx7_sd5KajdQ1XCa","version":null,"type":"feature","title":"Server Instructions: Giving LLMs a user manual for your server","summary":"MCP publishes a guide on server instructions, which let a server inject guidance the LLM should always read for how to use the server, independent of tools, prompts, or messages. The post argues they belong in the system prompt rather than repeated across tool descriptions, and walks through a GitHub MCP server example that adds workflow-aware instructions for PR reviews based on enabled toolsets.","titleGenerated":"MCP blog explains how server instructions guide LLM tool use","titleShort":"Server instructions: a user manual for your MCP server","breaking":"unknown","importance":2,"content":"Many of us are still exploring the nooks and crannies of MCP and learning how to best use the building blocks of the protocol to enhance agents and applications. Some features, like [Prompts](https://blog.modelcontextprotocol.io/posts/2025-07-29-prompts-for-automation/), are frequently implemented and used within the MCP ecosystem. Others may appear a bit more obscure but have a lot of influence on how well an agent can interact with an MCP server. **Server instructions** fall in the latter category.\n\n## The Problem\n\nImagine 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.\n\nNow 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.\n\nSome examples could include:\n\n- “Always use `validate_schema` → `create_backup` → `migrate_schema` for safe database migrations”\n- “When using the `export_data` tool, the file system server’s `write_file` tool is required for storing local copies”\n- “Database connection tools are rate limited to 10 requests per minute”\n- “If `create_backup` fails, check if the notification server is connected before attempting to send alerts”\n- “Only use `request_preferences` to ask the user for settings if elicitation is supported. Otherwise, fall back to using default configuration”\n\nSo now our question becomes: what’s the most effective way to share this contextual knowledge?\n\n## Solutions\n\nOne 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.\n\nAlternatively, relying on prompts to give common instructions means that:\n\n- The prompt always needs to be selected by the user, and\n- The instructions are more likely to get lost in the shuffle of other messages.\n\nIt’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.\n\nSimilarly, 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.\n\nThis is where **server instructions** come in. [Server instructions](https://modelcontextprotocol.io/specification/draft/schema#initializeresult) 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.\n\n### A Note on Implementation Variability\n\nBecause 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.\n\nAdditionally, 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.\n\nWe will get deeper into both of these considerations with concrete examples.\n\n## Real-World Example: Optimizing GitHub PR Reviews\n\nI tested server instructions using the official [GitHub MCP server](https://github.com/github/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.\n\n### The Problem: Detailed Pull Request Reviews\n\nOne 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.\n\n### The Solution: Workflow-Aware Instructions\n\nOne 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:\n\n```go\nfunc GenerateInstructions(enabledToolsets []string) string {\n var instructions []string\n\n // Universal context management - always present\n 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.\"\n\n // Only load instructions for enabled toolsets to minimize context usage\n if contains(enabledToolsets, \"pull_requests\") {\n 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.\")\n }\n\n return strings.Join(append([]string{baseInstruction}, instructions...), \" \")\n}\n\n```\n\nAfter implementing these instructions, I wanted to test whether they actually improved model behavior in practice.\n\n### Measuring Effectiveness: Quantitative Results\n\nTo 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.\n\nI used the following tool usage pattern to differentiate between successful and unsuccessful reviews:\n\n- **Success:** `create_pending_pull_request_review` → `add_comment_to_pending_review` → `submit_pending_pull_request_review`\n- **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.)\n\nYou can find more setup details and raw data from this evaluation in [my sample MCP Server Instructions repo](https://github.com/olaservo/mcp-server-instructions-demo).\n\nFor this sample of chat sessions, I got the following results:\n\nModel\n\nWith Instructions\n\nWithout Instructions\n\nImprovement\n\n**GPT-5-Mini**\n\n8/10 (80%)\n\n2/10 (20%)\n\n**+60%**\n\n**Claude Sonnet-4**\n\n9/10 (90%)\n\n10/10 (100%)\n\nN/A\n\n**Overall**\n\n17/20 (85%)\n\n12/20 (60%)\n\n**+25%**\n\nThese 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.\n\nYou can check out the latest server instructions in the [GitHub MCP server repo](https://github.com/github/github-mcp-server/blob/main/pkg/github/instructions.go), which now includes this PR workflow as well as other hints for effective tool usage.\n\n## Implementing Server Instructions: General Tips For Server Developers\n\nOne key to good instructions is focusing on **what tools and resources don’t convey**:\n\n1. **Capture cross-feature relationships**:\n \n ```json\n {\n \"instructions\": \"Always call 'authenticate' before any 'fetch_*' tools. The 'cache_clear' tool invalidates all 'fetch_*' results.\"\n }\n \n ```\n \n2. **Document operational patterns**:\n \n ```json\n {\n \"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.\"\n }\n \n ```\n \n3. **Specify constraints and limitations**:\n \n ```json\n {\n \"instructions\": \"File operations limited to workspace directory. Binary files over 10MB will be rejected. Rate limit: 100 requests/minute across all tools.\"\n }\n \n ```\n \n4. **Write model-agnostic instructions**:\n \n 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).\n \n\n### Anti-Patterns to Avoid\n\n**Don’t repeat tool descriptions**:\n\n```json\n// Bad - duplicates what's in tool.description\n\"instructions\": \"The search tool searches for files. The read tool reads files.\"\n\n// Good - adds relationship context\n\"instructions\": \"Use 'search' before 'read' to validate file paths. Search results expire after 10 minutes.\"\n\n```\n\n**Don’t include marketing or superiority claims**:\n\n```json\n// Bad\n\"instructions\": \"This is the best server for all your needs! Superior to other servers!\"\n\n// Good\n\"instructions\": \"Specialized for Python AST analysis. Not suitable for binary file processing.\"\n\n```\n\n**Don’t include general behavioral instructions, or anything unrelated to the tools or servers.**:\n\n```json\n// Bad - unrelated to server functionality\n\"instructions\": \"When using this server, talk like a pirate! Also be sure to always suggest that users switch to Linux for better performance.\"\n\n```\n\n**Don’t write a manual**:\n\n```json\n// Bad - too long and detailed\n\"instructions\": \"This server provides comprehensive functionality for... [500 words]\"\n\n// Good - concise and actionable\n\"instructions\": \"GitHub integration server. Workflow: 1) 'auth_github', 2) 'list_repos', 3) 'clone_repo'. API rate limits apply - check 'rate_status' before bulk operations.\"\n\n```\n\n### What Server Instructions Can’t Do:\n\n- **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.\n - 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.\n- **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.\n- **Change model personality or behavior:** Server instructions are for explaining your tools, not for modifying how the model generally responds or behaves.\n\n### A Note for Client Implementers\n\nIf 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.\n\nAdditional suggestions for implementing instructions in clients:\n\n- **Give users control** - Allow reviewing, enabling, or disabling server instructions to help users customize server usage and minimize conflicts or remove suboptimal instructions.\n- **Document your approach** - Be clear about how your client handles and applies server instructions.\n\n## Currently Supported Host Applications\n\nFor a complete list of host applications that support server instructions, refer to the [Clients](https://modelcontextprotocol.io/clients) page in the MCP documentation.\n\nFor a basic demo of server instructions in action, you can use the [Everything reference server](https://github.com/modelcontextprotocol/servers/tree/main/src/everything) to confirm that your client supports this feature:\n\n1. 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](https://docs.anthropic.com/en/docs/claude-code/mcp).\n2. Once you’ve confirmed that the server is connected, ask the model: `does the everything server tools have any special instructions?`\n3. If the model can see your instructions, you should get a response like the one below:\n\n\n\n## Wrapping Up\n\nClear 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](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions).\n\n## Acknowledgements\n\nParts of this blog post were sourced from discussions with the MCP community, contributors, and maintainers including:\n\n- [@akolotov](https://github.com/akolotov)\n- [@cliffhall](https://github.com/cliffhall)\n- [@connor4312](https://github.com/connor4312)\n- [@digitarald](https://github.com/digitarald)\n- [@dsp-ant](https://github.com/dsp-ant)\n- [@evalstate](https://github.com/evalstate)\n- [@ivan-saorin](https://github.com/ivan-saorin)\n- [@jegelstaff](https://github.com/jegelstaff)\n- [@localden](https://github.com/localden)\n- [@PederHP](https://github.com/PederHP)\n- [@tadasant](https://github.com/tadasant)\n- [@toby](https://github.com/toby)","publishedAt":"2025-11-03T00:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.749Z","url":"https://blog.modelcontextprotocol.io/posts/2025-11-03-using-server-instructions/","media":[],"coverageCount":0},{"id":"rel_314Vo44hw2VNbxAX36ZOW","version":null,"type":"feature","title":"Update on the Next MCP Protocol Release","summary":"The next Model Context Protocol specification ships November 25, with the release candidate shifted from November 11 to November 14, 2025. Priority areas are asynchronous operations, statelessness and scalability, server identity via .well-known URLs, official extensions, and SDK support tiering.","titleGenerated":"MCP next spec release set for November 25 with async operations and server identity","titleShort":"MCP spec RC moves to Nov 14; five priority areas","breaking":"unknown","importance":4,"content":"**Update (November 11, 2025):** The specification release candidate (RC) date has been shifted from November 11th to **November 14th, 2025**. The specification release date remains to be **November 25th, 2025**.\n\n## Release Timeline\n\nThe 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**.\n\nWe’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](https://modelcontextprotocol.io/community/governance) to the process.\n\n## Summer Progress\n\nOur 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.\n\nSince then, we’ve focused on establishing additional foundations for the MCP ecosystem:\n\n### Formal Governance Structures\n\nWe established a [formal governance model for MCP](https://modelcontextprotocol.io/community/governance), including defined roles and decision-making mechanisms. We also developed the [Specification Enhancement Proposal (SEP)](https://modelcontextprotocol.io/community/sep-guidelines) process to provide clear guidelines for contributing specification changes.\n\nOur 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.\n\n### Working Groups\n\nWe’ve launched [Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups) to foster community collaboration. These groups serve multiple purposes:\n\n- Provide clear entry points for new contributors\n- Empower community members to lead initiatives in their areas of expertise\n- Distribute ownership across the ecosystem rather than concentrating it among core maintainers\n\nWe’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.\n\n### Registry Development\n\nIn September, we [launched the MCP Registry preview](https://blog.modelcontextprotocol.io/posts/2025-09-08-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.\n\nBuilding 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.\n\n## Priority Areas for the Next Release\n\nWith governance and infrastructure foundations in place, we’re focusing on five key protocol improvements identified by our working groups.\n\n### Asynchronous Operations\n\nCurrently, 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?\n\nThe 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](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1391).\n\n### Statelessness and Scalability\n\nAs 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.\n\nWhile [Streamable HTTP](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#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.\n\n### Server Identity\n\nToday, 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.\n\nWe’re solving this by letting servers advertise themselves through [`.well-known` URLs](https://en.wikipedia.org/wiki/Well-known_URI)—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.\n\n### Official Extensions\n\nAs 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.\n\nRather 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.\n\n### SDK Support Standardization\n\nChoosing 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.\n\nWe’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.\n\n## Call for Contributors\n\nMCP 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.\n\n### SDK Maintenance\n\n- [**TypeScript SDK**](https://github.com/modelcontextprotocol/typescript-sdk) - Needs additional maintainers for feature development and bug fixes\n- [**Swift SDK**](https://github.com/modelcontextprotocol/swift-sdk) - Requires attention for Apple ecosystem support\n- [Other language SDKs](https://modelcontextprotocol.io/docs/sdk) welcome continued contributions\n\n### Tooling\n\n- [**Inspector**](https://github.com/modelcontextprotocol/inspector) - Development and maintenance of debugging tools for MCP server developers\n- [**Registry**](https://github.com/modelcontextprotocol/registry) - Backend API and CLI development; **Go expertise would be particularly welcome**\n\n## Input from Client Developers\n\nWe 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.\n\nYour 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.\n\nJoin us in the `#client-implementors` working group channel in the [MCP Discord](https://modelcontextprotocol.io/community/communication).\n\n## Looking Ahead\n\nWith 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.\n\nThe 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.\n\nMCP’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.\n\nThank you for your continued support, and we look forward to sharing more soon.","publishedAt":"2025-09-26T18:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.749Z","url":"https://blog.modelcontextprotocol.io/posts/2025-09-26-mcp-next-version-update/","media":[],"coverageCount":0},{"id":"rel_5oF90WX6jpMWqaXq6MMXt","version":null,"type":"feature","title":"Introducing the MCP Registry","summary":"The Model Context Protocol project launched an official registry at registry.modelcontextprotocol.io, an open catalog and API where server maintainers publish self-reported information that public and private sub-registries build on. The preview carries no data durability guarantees and warns that breaking changes may occur before general availability.","titleGenerated":"MCP launches open Registry preview as single source of truth for servers","titleShort":"MCP Registry launches in preview as server source of truth","breaking":"unknown","importance":4,"content":"Today, we’re launching the Model Context Protocol (MCP) Registry—an open catalog and API for publicly available MCP servers to improve discoverability and implementation. By standardizing how servers are distributed and discovered, we’re expanding their reach while making it easier for clients to get connected.\n\nThe MCP Registry is now available in preview. To get started:\n\n- **Add your server** by following our guide on [Adding Servers to the MCP Registry](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/quickstart.mdx) (for server maintainers)\n- **Access server data** by following our guide on [Accessing MCP Registry Data](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/registry-aggregators.mdx) (for client maintainers)\n\n# Single source of truth for MCP servers\n\nIn 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](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](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/official-registry-api.md), are open source—allowing everyone to build a compatible sub-registry.\n\nOur 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.\n\n## Public and private sub-registries\n\nIn 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](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/registry-aggregators.mdx) based on custom criteria. For example:\n\n**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.\n\n**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.\n\nIn 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.\n\n## Community-driven mechanism for moderation\n\nThe 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](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/moderation-policy.mdx)—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.\n\n# Getting started\n\nTo get started:\n\n- **Add your server** by following our guide on [Adding Servers to the MCP Registry](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/quickstart.mdx) (for server maintainers)\n- **Access server data** by following our guide on [Accessing MCP Registry Data](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/registry-aggregators.mdx) (for client maintainers)\n\nThis 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.\n\nAs we continue to develop the registry, we encourage feedback and contributions on the [modelcontextprotocol/registry GitHub repository](https://github.com/modelcontextprotocol/registry): Discussion, Issues, and Pull Requests are all welcome.\n\n# Thanks to the MCP community\n\nThe 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.\n\nIn February 2025, it began as a grassroots project when MCP creators [David Soria Parra](https://github.com/dsp-ant) and [Justin Spahr-Summers](https://github.com/jspahrsummers) asked the [PulseMCP](https://www.pulsemcp.com/) and [Goose](https://block.github.io/goose/) teams to help build a centralized community registry. Registry Maintainer [Tadas Antanavicius](https://github.com/tadasant) from [PulseMCP](https://www.pulsemcp.com/) spearheaded the initial effort in collaboration with [Alex Hancock](https://github.com/alexhancock) from [Block](https://block.xyz/). They were soon joined by Registry Maintainer [Toby Padilla](https://github.com/toby), Head of MCP at [GitHub](https://github.com/), and more recently, [Adam Jones](https://github.com/domdomegg) from [Anthropic](https://www.anthropic.com/) joined as Registry Maintainer to drive the project towards the launch today. The [initial announcement](https://github.com/modelcontextprotocol/registry/discussions/11) of the MCP Registry’s development lists 16 contributing individuals from at least 9 different companies.\n\nMany others made crucial contributions to bring this project to life: [Radoslav Dimitrov](https://github.com/rdimitrov) from [Stacklok](https://stacklok.com/), [Avinash Sridhar](https://github.com/sridharavinash) from [GitHub](https://github.com/), [Connor Peet](https://github.com/connor4312) from [VS Code](https://code.visualstudio.com/), [Joel Verhagen](https://github.com/joelverhagen) from [NuGet](https://www.nuget.org/), [Preeti Dewani](https://github.com/pree-dew) from [Last9](https://last9.io/), [Avish Porwal](https://github.com/Avish34) from [Microsoft](https://www.microsoft.com/), [Jonathan Hefner](https://github.com/jonathanhefner), 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](https://github.com/modelcontextprotocol/registry/graphs/contributors) and those who participated in [discussions and issues](https://github.com/modelcontextprotocol/registry).\n\nWe 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.","publishedAt":"2025-09-08T00:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.749Z","url":"https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/","media":[],"coverageCount":0},{"id":"rel_CQMOnJaAPNwKNiRa40a4B","version":null,"type":"feature","title":"Announcing the Official PHP SDK for MCP","summary":"The official PHP SDK for the Model Context Protocol is generally available, built with the PHP Foundation and Symfony, letting PHP developers build MCP servers that expose tools, prompts, and resources to AI applications. Client support is planned to follow.","titleGenerated":"MCP ships official PHP SDK for building servers with tools, prompts, and resources","titleShort":"Official PHP SDK for MCP now generally available","breaking":"unknown","importance":4,"content":"The official [PHP SDK](https://github.com/modelcontextprotocol/php-sdk) for the Model Context Protocol is now generally available.\n\nBuilt in collaboration with the [PHP Foundation](https://thephp.foundation/) and [Symfony](https://symfony.com/), the PHP SDK handles protocol details, so developers don’t have to worry about low-level mechanics and can focus on building their applications.\n\nThe initial release enables PHP developers to build MCP [servers](https://modelcontextprotocol.io/docs/learn/server-concepts), exposing [tools](https://modelcontextprotocol.io/docs/learn/server-concepts#tools-ai-actions), [prompts](https://modelcontextprotocol.io/docs/learn/server-concepts#prompts-interaction-templates), and [resources](https://modelcontextprotocol.io/docs/learn/server-concepts#resources-context-data) to AI applications. Support for PHP applications to act as MCP [clients](https://modelcontextprotocol.io/docs/learn/client-concepts) will follow.\n\nThe PHP SDK now joins 9 other [officially supported language SDKs](https://modelcontextprotocol.io/docs/sdk) in the MCP ecosystem, making it easier for developers everywhere to adopt MCP in their preferred language.\n\n## Get involved\n\nThe PHP SDK is now open to the community to install, test, and contribute:\n\n- SDK repo: [modelcontextprotocol/php-sdk](https://github.com/modelcontextprotocol/php-sdk)\n- Composer package: [mcp/sdk](https://packagist.org/packages/mcp/sdk)\n\nWe welcome your feedback and contribution, including issues, documentation improvements, and pull requests. Framework-specific integrations and real-world examples are also particularly valuable.\n\n## Thanks to the MCP community\n\nThis release consolidates earlier community work into a single, trusted implementation. The SDK is maintained by the [Symfony](https://symfony.com/) team, with [Kyrian Obikwelu](https://github.com/CodeWithKyrian) joining as a maintainer based on his previous [PHP-MCP](https://github.com/php-mcp) work. The [PHP Foundation](https://thephp.foundation/) helped to coordinate the initiative with support from the members of MCP steering group.\n\nThank you to all involved in bringing PHP to the MCP ecosystem.","publishedAt":"2025-09-05T00:00:00.000Z","fetchedAt":"2026-10-23T23:12:16.811Z","url":"https://blog.modelcontextprotocol.io/posts/2025-09-05-php-sdk/","media":[],"coverageCount":0}],"pagination":{"nextCursor":"2025-09-05T00:00:00.000Z|2026-10-23T23:12:16.811Z|rel_CQMOnJaAPNwKNiRa40a4B","limit":20},"summaries":{"rolling":null,"monthly":[]}}