[{"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.\nThe Enterprise-Managed Authorization (EMA) extension is now stable. We\u0026rsquo;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.\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.\nPer-user auth is high friction The standard MCP authorization model was designed to be user-scoped and bound to the traditional interactive auth conventions. While this might work well for more general consumer scenarios where individuals decide what touches their data, this doesn\u0026rsquo;t quite scale for enterprise deployments:\nEvery employee has to authorize every server individually: onboarding means manually connecting service after service. Security teams cannot enforce consistent policy: access is whatever each user authorized, with no central control or audit trail. Work and personal accounts blur together: there\u0026rsquo;s no way to require a corporate identity, so a user can connect a personal account to a work tool. This combination of factors slows MCP adoption and pushes people toward brittle workarounds. With no universal standard for preserving shared auth state, everyone invents their own bespoke solution. The data and tools are available, but the per-user authorization tax keeps most of them switched off.\nAuthorize once, inherit everywhere Enterprise-Managed Authorization makes the organization\u0026rsquo;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.\nUnder the hood, the client obtains an Identity Assertion JWT Authorization Grant (ID-JAG) from the IdP during single sign-on and exchanges it for an access token from the MCP server\u0026rsquo;s authorization server. The user is never redirected through a per-server consent screen. Three properties fall out of that flow:\nAuthorize once, inherit everywhere: admins enable a server for the org. Users get it automatically, scoped to the groups and roles they already have. Centralized policy and audit: access decisions live in the IdP admin console, with one auditable trail across every connector. Removing personal/enterprise mixups: by removing the interactive account selection step, it\u0026rsquo;s much easier to prevent data flowing between personal and enterprise accounts by mistake or compromise. We see this as a brand new baseline for MCP in the enterprise. When users log in, their client should be connected to the tools and data they\u0026rsquo;re authorized to use with no extra steps in between.\nEarly adopters This launch brought together three groups that collaborated closely on making the implementation real:\nIdentity providers: Okta is the first supported identity provider. Organizations using Okta can provision MCP access to supported servers through any supported client, using Okta\u0026rsquo;s Cross App Access (XAA). Clients: Anthropic has implemented the extension in its shared MCP layer for Claude. Admins can authorize MCP servers for users across Claude, Claude Code, and Cowork. Additionally, Visual Studio Code has also added support for EMA right in the IDE. Servers: Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase now support EMA, with Slack and more actively adding support. We\u0026rsquo;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\u0026ldquo;The momentum around MCP is incredible, but as we move toward an interconnected AI workforce, security can\u0026rsquo;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.\u0026rdquo;\n— Aaron Parecki, Director of Identity Standards, Okta\n\u0026ldquo;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.\u0026rdquo;\n— Devdatta Akhawe, VP of Engineering, Figma\n\u0026ldquo;Logging in once and automatically having all your MCP connectors automatically setup is pretty magical.\u0026rdquo;\n— Tom Moor, Head of Engineering, Linear\nGet involved As with all other MCP extensions, features, and enhancements, we welcome your input. We\u0026rsquo;re encouraging clients, servers, and identity platforms to review the extension specification and add support for the new standard into their products:\nRead the requirements: the Enterprise-Managed Authorization page documents the flow for clients, servers, and authorization servers. Source and draft spec: see the ext-auth repository and the draft specification for the latest in EMA evolution as well as any support materials that will help you get started. If you\u0026rsquo;re interested in discussing the extension, sharing compatibility reports, or iterating on the extension, join the EMA Interest Group.\nAcknowledgements Enterprise-Managed Authorization is the work of the MCP community: the authors of SEP-990, the maintainers of the ext-auth repository, and the identity and MCP providers who tested early implementations and pushed the spec forward. Thank you to everyone who contributed.\n","permalink":"https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/","summary":"\u003cp\u003e\u003cem\u003eThe Enterprise-Managed Authorization extension is now stable. Organizations can centrally\nmanage authorization for MCP servers and end-users can access all connected MCP servers\nthrough a single log in. The extension is being adopted by Anthropic, Microsoft, Okta and\na growing number of MCP servers.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization\"\u003eEnterprise-Managed Authorization (EMA) extension\u003c/a\u003e\nis now stable. We\u0026rsquo;ve heard from the community that authorization and repeated consent\nprompts from connected MCP servers is one of the biggest pain points when it comes to\nmanaging connectivity in enterprise environments. This extension helps address this.\u003c/p\u003e","title":"Enterprise-Managed Authorization: Zero-touch OAuth for MCP"},{"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:\na stateless core that scales on ordinary HTTP infrastructure extensions including server-rendered UIs through MCP Apps and long-running work through the Tasks extension authorization that aligns more closely with OAuth and OpenID Connect deployments a formal deprecation policy so the protocol can evolve without breaking what you\u0026rsquo;ve built, and many other changes.\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\u0026rsquo;s ttlMs permits.\nThe 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.\nA Stateless Protocol The headline change is that MCP is now stateless at the protocol layer. Six Specification Enhancement Proposals (SEPs) work together to get there, completing the plan we laid out in The Future of MCP Transports in December.\nBefore and after In 2025-11-25, calling a tool over Streamable HTTP means establishing a session first:\nPOST /mcp HTTP/1.1 Content-Type: application/json {\u0026#34;jsonrpc\u0026#34;:\u0026#34;2.0\u0026#34;,\u0026#34;id\u0026#34;:1,\u0026#34;method\u0026#34;:\u0026#34;initialize\u0026#34;, \u0026#34;params\u0026#34;:{\u0026#34;protocolVersion\u0026#34;:\u0026#34;2025-11-25\u0026#34;,\u0026#34;capabilities\u0026#34;:{}, \u0026#34;clientInfo\u0026#34;:{\u0026#34;name\u0026#34;:\u0026#34;my-app\u0026#34;,\u0026#34;version\u0026#34;:\u0026#34;1.0\u0026#34;}}} The server responds with an Mcp-Session-Id that every subsequent request must carry, pinning the client to whichever instance issued it:\nPOST /mcp HTTP/1.1 Mcp-Session-Id: 1868a90c-3a3f-4f5b Content-Type: application/json {\u0026#34;jsonrpc\u0026#34;:\u0026#34;2.0\u0026#34;,\u0026#34;id\u0026#34;:2,\u0026#34;method\u0026#34;:\u0026#34;tools/call\u0026#34;, \u0026#34;params\u0026#34;:{\u0026#34;name\u0026#34;:\u0026#34;search\u0026#34;,\u0026#34;arguments\u0026#34;:{\u0026#34;q\u0026#34;:\u0026#34;otters\u0026#34;}}} In 2026-07-28, the same call is a single self-contained request that any server instance can handle:\nPOST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search Content-Type: application/json {\u0026#34;jsonrpc\u0026#34;:\u0026#34;2.0\u0026#34;,\u0026#34;id\u0026#34;:1,\u0026#34;method\u0026#34;:\u0026#34;tools/call\u0026#34;, \u0026#34;params\u0026#34;:{\u0026#34;name\u0026#34;:\u0026#34;search\u0026#34;,\u0026#34;arguments\u0026#34;:{\u0026#34;q\u0026#34;:\u0026#34;otters\u0026#34;}, \u0026#34;_meta\u0026#34;:{\u0026#34;io.modelcontextprotocol/clientInfo\u0026#34;:{\u0026#34;name\u0026#34;:\u0026#34;my-app\u0026#34;,\u0026#34;version\u0026#34;:\u0026#34;1.0\u0026#34;}}}} The handshake and session are gone The initialize/initialized handshake is removed (SEP-2575). The protocol version, client info, and client capabilities that used to be exchanged once at connection time now travel in _meta on every request, and a new server/discover method lets clients fetch server capabilities when they need them up front.\nThe Mcp-Session-Id header and the protocol-level session that came with it are also removed (SEP-2567). With both gone, any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer.\nStateless protocol, stateful applications Removing the protocol-level session does not mean your application has to be stateless. Servers that need to carry state across calls can do what HTTP APIs have always done: mint an explicit handle (a basket_id, a browser_id) from a tool and have the model pass it back as an ordinary argument on later calls.\nIn practice, we\u0026rsquo;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\u0026rsquo;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.\nThe protocol no longer manages that state for you, but it doesn\u0026rsquo;t prevent you from managing it yourself. The explicit-handle pattern simply makes the state visible to the model rather than hidden away.\nServer-to-client requests, restructured A stateless protocol still needs a way for servers to ask the client for something mid-call, such as an elicitation prompt. Two SEPs rebuild that flow so it works without a persistent connection.\nServer-initiated requests may now only be issued while the server is actively processing a client request (SEP-2260). Earlier spec versions recommended this; it\u0026rsquo;s now required. A user is never prompted out of nowhere, and every elicitation traces back to something they (or their agent) started.\nMulti Round-Trip Requests (SEP-2322) change how those prompts are delivered. Instead of holding a Server-Sent Events (SSE) stream open, the server returns an InputRequiredResult:\n{ \u0026#34;resultType\u0026#34;: \u0026#34;inputRequired\u0026#34;, \u0026#34;inputRequests\u0026#34;: { \u0026#34;confirm\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;elicitation\u0026#34;, \u0026#34;message\u0026#34;: \u0026#34;Delete 3 files?\u0026#34;, \u0026#34;schema\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; } } }, \u0026#34;requestState\u0026#34;: \u0026#34;eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0=\u0026#34; } The client gathers the answers and re-issues the original call with inputResponses and the echoed requestState. Any server instance can pick that retry up because everything it needs is in the payload.\nRoutable, cacheable, traceable Three smaller changes make the resulting traffic easier to operate.\nThe Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers (SEP-2243) so load balancers, gateways, and rate-limiters can route on the operation without inspecting the body. Servers reject requests where the headers and body disagree.\nList and resource read results now carry ttlMs and cacheScope (SEP-2549), modeled on HTTP Cache-Control. Clients know exactly how long a tools/list response is fresh and whether it\u0026rsquo;s safe to share across users, and a long-lived SSE stream is no longer the only way to learn that a list changed.\nW3C Trace Context propagation in _meta is now documented (SEP-414), locking down the traceparent, tracestate, and baggage key names so distributed traces correlate across SDKs and gateways. Several SDKs and tools were already doing this; with the key names fixed in the spec, a trace that starts in a host application can follow a tool call through the client SDK, the MCP server, and whatever the server calls downstream, and show up as a single span tree in an OpenTelemetry-compatible backend.\nExtensions Become First-Class Extensions existed in the 2025-11-25 release but had no formal process behind them. SEP-2133 adds that: extensions are identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, live in their own ext-* repositories with delegated maintainers, and version independently of the specification. A new Extensions Track in the SEP process gives them a path from experimental to official.\nThis release includes two official extensions.\nMCP Apps: server-rendered user interfaces MCP Apps (SEP-1865) lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs. The rendered UI talks back to the host over the same JSON-RPC base protocol used everywhere else in MCP, so every UI-initiated action goes through the same audit and consent path as a direct tool call.\nTasks graduates to an extension Tasks shipped as an experimental core feature in 2025-11-25. Production use surfaced enough redesign that the right home for it is an extension rather than the specification.\nThe Tasks extension reshapes the lifecycle around the stateless model: a server can answer tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. Task creation is server-directed: the client advertises the extension and the server decides when a call should run as a task. tasks/list is removed because it can\u0026rsquo;t be scoped safely without sessions.\nAnyone who shipped against the 2025-11-25 experimental Tasks API will need to migrate to the new lifecycle.\nAuthorization Hardening Six SEPs harden the authorization specification to align more closely with how OAuth 2.0 and OpenID Connect are deployed in practice.\nClients must now validate the iss parameter on authorization responses per RFC 9207 (SEP-2468). This is a low-cost mitigation for a class of mix-up attack that is more prevalent in MCP\u0026rsquo;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\u0026rsquo;t already.\nClients now declare their OpenID Connect application_type during Dynamic Client Registration (SEP-837), avoiding the common case where an authorization server defaults a desktop or CLI client to \u0026quot;web\u0026quot; and rejects its localhost redirect URI. Clients bind registered credentials to the issuing authorization server\u0026rsquo;s issuer and re-register when a resource migrates between authorization servers (SEP-2352). The spec also documents how to request refresh tokens from OpenID Connect-style authorization servers (SEP-2207), and clarifies scope accumulation during step-up (SEP-2350) and the .well-known discovery suffix (SEP-2351).\nRoots, Sampling, and Logging Are Deprecated Three core features are deprecated under the new feature lifecycle policy (SEP-2577):\nFeature Replacement Roots Tool parameters, resource URIs, or server configuration Sampling Direct integration with LLM provider APIs Logging stderr for stdio transports; OpenTelemetry for structured observability These are annotation-only deprecations. The methods, types, and capability flags continue to work in this release and in every specification version published within a year of it, and removing any of them will require a separate SEP under the lifecycle policy.\nFull JSON Schema 2020-12 for Tools Tool inputSchema and outputSchema are lifted to full JSON Schema 2020-12 (SEP-2106). Input schemas keep the type: \u0026quot;object\u0026quot; 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.\nSeparately, the error code for a missing resource changes from the MCP-custom -32002 to the JSON-RPC standard -32602 Invalid Params (SEP-2164). If your client matches on the literal -32002 value, update it.\nHow the Protocol Evolves From Here This release contains breaking changes. We don\u0026rsquo;t intend for that to be the norm.\nThree governance SEPs in this release are designed so that future revisions can evolve the protocol without breaking core capabilities. The feature lifecycle policy gives every feature an Active, Deprecated, and Removed lifecycle with at least twelve months between deprecation and the earliest possible removal. The Extensions framework means new capabilities can ship as opt-in extensions and stabilize there before, if ever, moving into the specification. And a Standards Track SEP can no longer reach Final status until a matching scenario lands in the conformance suite (SEP-2484), which is the same suite the new SDK tier system scores official SDKs against.\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.\nRelease Timeline and Validation The release candidate is locked as of May 21, 2026. The final specification will be published on July 28, 2026. The ten-week window is for SDK maintainers and client implementers to validate the changes against real workloads; under the SDK tier system, Tier 1 SDKs are expected to ship support within this window.\nThe full release candidate is in the draft specification, and the changelog will list every change against 2025-11-25.\nIf you find a problem, open an issue in the specification repository. For implementation questions, the relevant Working Group channel in the contributor Discord is the fastest path to an answer.\nLooking Ahead This release gives MCP the foundation we expect it to grow on for a long time: a protocol that runs statelessly on commodity HTTP infrastructure, an extensions framework where capabilities like Tasks and MCP Apps can ship on their own timeline, and a lifecycle policy that lets implementers build on 2026-07-28 knowing what they ship will keep working.\nThank you to everyone who shaped these proposals through the Working Groups and a great deal of patient review. We\u0026rsquo;re looking forward to making this final with the community on July 28.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/","summary":"\u003cp\u003eThe release candidate for MCP \u003cstrong\u003e\u003ccode\u003e2026-07-28\u003c/code\u003e\u003c/strong\u003e is now available. It is the largest\nrevision of the protocol since launch and delivers on the\n\u003ca href=\"/posts/2026-mcp-roadmap/\"\u003e2026 roadmap\u003c/a\u003e:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ea stateless core\u003c/strong\u003e that scales on ordinary HTTP infrastructure\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eextensions\u003c/strong\u003e including server-rendered UIs through \u003ca href=\"#mcp-apps-server-rendered-user-interfaces\"\u003eMCP Apps\u003c/a\u003e and long-running work through the \u003ca href=\"#tasks-graduates-to-an-extension\"\u003eTasks extension\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eauthorization\u003c/strong\u003e that aligns more closely with OAuth and OpenID Connect deployments\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ea formal deprecation policy\u003c/strong\u003e so the protocol can evolve without breaking what you\u0026rsquo;ve\nbuilt,\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eand many other changes.\u003c/p\u003e","title":"The 2026-07-28 MCP Specification Release Candidate"},{"content":"I\u0026rsquo;m happy to share two updates to the maintainer team: Clare Liguori is joining the Core Maintainer group, and Den Delimarsky is joining me as a Lead Maintainer.\nWhen we introduced the MCP governance model last summer, the goal was to make sure the protocol could keep growing without any one person becoming a bottleneck. That has held up well through two specification releases, the move to the Agentic AI Foundation (AAIF), and a steady increase in SEP volume, and these changes give the project the leadership capacity it needs for what comes next.\nWelcoming Clare Liguori as Core Maintainer I\u0026rsquo;m pleased to welcome Clare Liguori to the Core Maintainer team.\nClare is a Senior Principal Engineer at Amazon Web Services, where she works on agentic AI developer tooling. Her current focus is Kiro and the Strands Agents SDK, and over more than a decade at AWS she has also worked on AWS Proton, Amazon ECS, the AWS Code Suite, and several open source projects.\nClare has been bringing that depth of developer-tooling and agent-runtime experience directly into MCP\u0026rsquo;s design work, particularly the discussions around unsolicited tasks, the agent execution model, and the Triggers \u0026amp; Events working group. She knows firsthand what the protocol has to look like inside production agent runtimes serving large numbers of developers. As those proposals move through the SEP process over the coming year, that perspective will keep the spec grounded in what client implementers actually need. I\u0026rsquo;m glad to have her at the table.\nWelcome, Clare!\nDen Delimarsky Joins as Lead Maintainer Den Delimarsky is stepping up from Core Maintainer to Lead Maintainer, joining me in that role.\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\u0026rsquo;s CoreAI division, and he brings a wealth of experience across developer tools, SDKs, and security tooling.\nDen\u0026rsquo;s work is most visible in authorization and security. He co-authored the authorization specification, brought RFC 8707 Resource Indicators into the spec, and has continued to build on it through SEP-835, SEP-1024, and the SEP-2350 family of proposals, among others. He also led the 2025-11-25 specification release, co-leads the Security Interest Group, and built a contribution tracker that gives SDK and spec maintainers a birds-eye view of activity across the project\u0026rsquo;s repositories.\nI\u0026rsquo;m glad to have Den as a partner in this role, and I\u0026rsquo;m looking forward to what we can do together for the protocol in the years ahead.\nWhat\u0026rsquo;s Next MCP continues to grow at a pace none of us could have predicted, and that growth wouldn\u0026rsquo;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.\nWith this team in place, I\u0026rsquo;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\u0026rsquo;d like to get involved, the governance docs explain how the project is organized, the Contributor Ladder shows how people grow into these roles, the roadmap shows where we\u0026rsquo;re headed, and our Discord is the best place to talk to the people working on it. Come build with us.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2026-04-08-maintainer-update/","summary":"\u003cp\u003eI\u0026rsquo;m happy to share two updates to the maintainer team: \u003cstrong\u003eClare Liguori\u003c/strong\u003e is joining the \u003ca href=\"https://modelcontextprotocol.io/community/governance#current-core-maintainers\"\u003eCore Maintainer\u003c/a\u003e group, and \u003cstrong\u003eDen Delimarsky\u003c/strong\u003e is joining me as a \u003ca href=\"https://modelcontextprotocol.io/community/governance#current-lead-maintainers\"\u003eLead Maintainer\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eWhen we \u003ca href=\"/posts/2025-07-31-governance-for-mcp/\"\u003eintroduced the MCP governance model\u003c/a\u003e 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 \u003ca href=\"/posts/2025-12-09-mcp-joins-agentic-ai-foundation/\"\u003eAgentic AI Foundation (AAIF)\u003c/a\u003e, and a steady increase in SEP volume, and these changes give the project the leadership capacity it needs for what comes next.\u003c/p\u003e","title":"Expanding the MCP Maintainer Team"},{"content":"MCP tool annotations were introduced nearly a year ago as a way for servers to describe the behavior of their tools — whether they\u0026rsquo;re read-only, destructive, idempotent, or reach outside their local environment. Since then, the community has filed five independent Specification Enhancement Proposals (SEPs) proposing new annotations, driven in part by a sharper collective understanding of where risk actually lives in agentic workflows. This post recaps where tool annotations are today, what they can and can\u0026rsquo;t realistically do, and offers a framework for evaluating new proposals.\nWhat Tool Annotations Are Tool annotations shipped in the 2025-03-26 spec revision. The current ToolAnnotations interface looks like this:\ninterface ToolAnnotations { title?: string; readOnlyHint?: boolean; // default: false destructiveHint?: boolean; // default: true idempotentHint?: boolean; // default: false openWorldHint?: boolean; // default: true } Every property is a hint. The spec is explicit about this: annotations are not guaranteed to faithfully describe tool behavior, and clients must treat them as untrusted unless they come from a trusted server.\nThese four boolean hints give clients a basic risk vocabulary:\nreadOnlyHint: Does the tool modify its environment? destructiveHint: If it does modify things, is the change destructive (as opposed to additive)? idempotentHint: Can you safely call it again with the same arguments? openWorldHint: Does the tool interact with an open world of external entities, or is its domain closed? The first three hints mostly answer a preflight question: should the client ask for confirmation before calling this tool? openWorldHint is different. It\u0026rsquo;s about where the tool reaches and what its output might carry back, which matters after the call as much as before. It\u0026rsquo;s also the hint most sensitive to deployment context. \u0026ldquo;External\u0026rdquo; might mean anything outside a corporate network or anything beyond the local machine, depending on where the server runs. The safest posture is to treat anything a tool considers external as a potential source of untrusted content.\nThe defaults are deliberately cautious: a tool with no annotations is assumed to be non-read-only, potentially destructive, non-idempotent, and open-world. The spec assumes the worst until told otherwise. Making annotations optional kept the barrier to entry low for server authors, but it also means coverage is uneven. Many servers ship without them, and clients vary in how strictly they honor the pessimistic defaults. Closing that gap is part of what the current wave of SEPs is trying to do.\nHow We Got Here The original proposal discussion surfaced a question that still shapes every annotation proposal today: what value do hints provide when they can\u0026rsquo;t be trusted? MCP co-creator Justin Spahr-Summers raised it directly during review:\nI think the information itself, if it could be trusted, would be very useful, but I wonder how a client makes use of this flag knowing that it\u0026rsquo;s not trustable.\nBasil Hosmer pushed the point further, arguing that clients should ignore annotations from untrusted servers entirely:\n\u0026ldquo;Clients should ignore annotations from untrusted servers\u0026rdquo; applies to all annotations, even title — but especially the ones that describe operational properties.\nThe spec landed on a compromise: call everything a hint, require clients to treat hints as untrusted by default, and leave it to each client to decide how much weight to give them based on what it knows about the server.\nThe interface has stayed small since then, and that\u0026rsquo;s been intentional. title went in because it\u0026rsquo;s just a display name with no trust implications. taskHint was proposed as an annotation but landed as Tool.execution instead, on the grounds that execution metadata isn\u0026rsquo;t really a behavioral hint. Earlier takes on stateless, streaming, and async annotations and security annotations are worth knowing about too, since the same concerns show up again in the SEPs open today.\nWhat\u0026rsquo;s Open Now Five SEPs currently propose new annotations or closely related capabilities:\nSEP Proposal Status #1913 Trust and Sensitivity Annotations Draft #1984 Comprehensive Tool Annotations for Governance/UX Draft #1561 unsafeOutputHint Proposal #1560 secretHint Proposal #1487 trustedHint Proposal The trust and sensitivity work is co-authored by GitHub and OpenAI based on gaps they hit running MCP in production. A Tool Annotations Interest Group is forming to work through these alongside related proposals like tool resolution and preflight checks. Reviewing each one in isolation makes it easy to miss how a given annotation interacts with others, and it\u0026rsquo;s those interactions that determine how risky a tool actually is in a given session.\nThe Lethal Trifecta: Why Combinations Matter Simon Willison\u0026rsquo;s lethal trifecta names three capabilities that, when combined, create the conditions for data theft: access to private data, exposure to untrusted content, and the ability to externally communicate. The attack is simple: LLMs follow instructions in content, and they can\u0026rsquo;t reliably tell a user\u0026rsquo;s instructions apart from ones an attacker embedded in a web page, email, or calendar event. If the agent has all three capabilities, an attacker who controls one piece of untrusted content can trick the model into reading private data and sending it out.\nResearchers have demonstrated this using a malicious Google Calendar event description, an MCP calendar server, and a local code execution tool. The code execution tool is the linchpin in that chain — any agent with unrestrained shell access sits one injected instruction away from exfiltration, and that\u0026rsquo;s true whether the tool arrived via MCP or was built into the host. What MCP adds is the ease of assembling the chain: users routinely combine tools from several servers in one session, so the risk profile is a property of the session, not of any single server.\nOne commenter on Willison\u0026rsquo;s newsletter connected this directly to tool annotations:\nIf the current state is tainted, block (or require explicit human approval for) any action with exfiltration potential\u0026hellip; This also makes MCP\u0026rsquo;s mix-and-match story extra risky unless tools carry metadata like: reads_private_data / sees_untrusted_content / can_exfiltrate — and the runtime enforces \u0026rsquo;never allow all three in a single tainted execution path.'\nSeveral of the open SEPs are trying to define that kind of metadata so a client can spot when a session has all three legs of the trifecta available.\nWhat Annotations Can Do Drive confirmation prompts. A tool marked readOnlyHint: true from a trusted server might be auto-approved, while destructiveHint: true gets a confirmation step. A user asks their agent to clean up old files, the agent reaches for delete_file, and the client shows a dialog listing what\u0026rsquo;s about to be deleted before anything happens. This is the most common use of annotations today.\nEnable graduated trust. An enterprise running its own internal MCP servers behind auth has a very different trust relationship than someone installing a random server off the internet. Annotations from the first can drive policy; from the second they\u0026rsquo;re informational at best. In practice most clients still treat installation itself as the trust signal and don\u0026rsquo;t distinguish further, so this is more of a design opportunity than a widely shipped feature.\nImprove UX. title is just a display name. Annotations that help users understand what tools do without running them are useful regardless of trust. This is largely unexploited today: no MCP client lets users filter tools by annotation values, and none surface annotations as context in approval prompts. GitHub\u0026rsquo;s read-only mode is the closest production analog, enabled by about 17% of users.\nFeed policy engines. Annotations can be one input among several into a policy engine enforcing rules like \u0026ldquo;no destructive tools without approval\u0026rdquo; or \u0026ldquo;open-world tools are blocked in sessions that have accessed private data.\u0026rdquo; The hints don\u0026rsquo;t need to be perfectly trustworthy if the engine cross-references other signals.\nAdoption across all of these is uneven, partly because MCP users split into two camps. Developers building autonomous agents treat confirmations as friction and lean on sandboxing instead. Enterprise adopters want more annotations than currently exist. One camp barely notices annotations, the other wants a much richer vocabulary.\nWhat Annotations Can\u0026rsquo;t Do They don\u0026rsquo;t make the model resist prompt injection. Annotations are static metadata on a tool definition; nothing in them tells the model to ignore malicious instructions it reads from a calendar event. What an annotation like seesUntrustedData could do is let the client treat the session as tainted once that tool runs and tighten approvals from then on — a defense at the host layer, not inside the model.\nAn untrusted server can lie. A server can claim readOnlyHint: true and delete your files anyway. This is why the spec says clients must treat annotations from untrusted servers as untrusted.\nThey aren\u0026rsquo;t enforcement. If you need a guarantee that a tool can\u0026rsquo;t exfiltrate data, that\u0026rsquo;s a job for network controls or sandboxing, not a boolean hint. We made the same point about server instructions: don\u0026rsquo;t rely on soft signals for things that need to be hard guarantees.\nA tool\u0026rsquo;s risk depends on what else is in the session. search_emails isn\u0026rsquo;t safe or dangerous on its own; it depends on what other tools the agent has. Annotations on one tool can\u0026rsquo;t tell you that.\nQuestions for Evaluating New Annotations As a starting point for the Interest Group, we\u0026rsquo;re putting forward a tentative set of questions to ask of each annotation proposal. These will likely change as the group works through the open SEPs.\n1. What client behavior does it enable? Maintainer Jonathan Hefner put this directly on an early draft of what became the governance/UX annotations proposal:\nIt\u0026rsquo;s not clear to me exactly how a client would behave differently when presented with these annotations.\nIf there\u0026rsquo;s no concrete client action that changes based on the annotation, it probably doesn\u0026rsquo;t belong in the protocol. Each of the existing hints maps to at least one decision a client can make:\nHint Example client behavior readOnlyHint: true Skip the confirmation dialog destructiveHint: true Show a warning before executing idempotentHint: true Safe to retry on failure openWorldHint: true Scrutinize output for untrusted content; flag a trust-boundary cross 2. Does it need trust to be useful? title is useful even from an untrusted server; worst case you show a bad display name. readOnlyHint from an untrusted server isn\u0026rsquo;t actionable, because the decision it informs — whether to skip a confirmation — only makes sense if you believe the hint. Proposals should say where they fall on that spectrum, since it determines which clients can actually use them.\n3. Could _meta handle it instead? Tools already have _meta, which accepts namespaced keys like com.example/my-field for exactly this kind of metadata. If an annotation only matters to one deployment style where the same organization runs both the server and the client, _meta is a reasonable home for it. It\u0026rsquo;s also a good way to prove out an idea before writing a SEP: ship a namespaced field, see how it holds up in production, and come back with a proposal backed by actual usage instead of a design doc. What _meta can\u0026rsquo;t do is drive behavior in off-the-shelf clients — those won\u0026rsquo;t read a key they\u0026rsquo;ve never heard of, so anything aimed at ecosystem-wide UX still needs a real annotation.\n4. Does it help reason about combinations? Annotations that help a client understand what happens when tools are used together are worth more than ones that only describe a tool in isolation. openWorldHint already hints at this: a client could use it to notice that a session mixes closed-world data access tools with open-world communication tools.\n5. Is it a hint or a contract? Hints inform decisions; contracts enforce them. If a proposal\u0026rsquo;s value depends on the annotation being true, it\u0026rsquo;s asking for a contract, and the right place for that is the authorization layer, the transport, or the runtime rather than ToolAnnotations. Hints work best when they\u0026rsquo;re still useful even if some servers get them wrong.\nWhere This Is Heading The Tool Annotations Interest Group includes participants from Microsoft, OpenAI, AWS, Cloudflare, and Anthropic, among others. These are companies that build both MCP hosts and MCP servers at scale, so they sit on both sides of the annotation contract: they need annotations expressive enough to surface risk to their users, and they need to author annotations that other clients will actually honor. Among the questions on the group\u0026rsquo;s agenda are whether annotations belong on tool responses as well as tool definitions, and whether any annotations should be evaluated at runtime rather than declared statically.\nIn the meantime, the existing annotations are worth using. If you\u0026rsquo;re writing a server, set readOnlyHint: true on read-only tools, destructiveHint: false on additive operations, and openWorldHint: false on closed-domain tools. If you\u0026rsquo;re writing a client, treat annotations from untrusted servers as informational and lean on them for UX, but keep your actual safety guarantees in deterministic controls. And if you\u0026rsquo;re thinking of proposing a new annotation, the questions above are a good place to start shaping it.\nGet Involved The Tool Annotations Interest Group is forming now. If you\u0026rsquo;re interested in contributing:\nReview the open SEPs linked above and leave feedback Join the conversation in #tool-annotations-ig on the MCP Contributors Discord Acknowledgements This post draws on discussions with the MCP community, particularly the contributors involved in the Tool Annotations Interest Group proposal, including Sam Morrow (GitHub), Robert Reichel (OpenAI), Den Delimarsky (Anthropic), Nick Cooper (OpenAI), Connor Peet (Microsoft), and Luca Chang (AWS).\n","permalink":"https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/","summary":"\u003cp\u003eMCP tool annotations were introduced nearly a year ago as a way for servers to describe the behavior of their tools — whether they\u0026rsquo;re read-only, destructive, idempotent, or reach outside their local environment. Since then, the community has filed five independent \u003ca href=\"https://modelcontextprotocol.io/community/sep-guidelines\"\u003eSpecification Enhancement Proposals\u003c/a\u003e (SEPs) proposing new annotations, driven in part by a sharper collective understanding of where risk actually lives in agentic workflows. This post recaps where tool annotations are today, what they can and can\u0026rsquo;t realistically do, and offers a framework for evaluating new proposals.\u003c/p\u003e","title":"Tool Annotations as Risk Vocabulary: What Hints Can and Can't Do"},{"content":"You\u0026rsquo;ve built an MCP server that works quite well, but now you\u0026rsquo;re wondering: How do I add richer UI elements? Custom auth flows? What about domain-specific conventions, like those for finance or healthcare?\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\u0026rsquo;s needs in mind.\nIn this post, we\u0026rsquo;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.\nHow MCP is structured It helps to think of MCP in three layers:\nMCP core specification: The protocol itself. This is how clients and servers talk to each other. It also represents the absolute minimum bar for client and server interoperability. MCP projects: Supporting infrastructure like the Registry, that helps developers discover MCP servers, or Inspector, that makes MCP server testing and debugging easier. MCP extensions: Optional patterns that developers can adopt for specialized use cases, built on top of the MCP core specification. Extensions let the ecosystem grow and give us an avenue to test changes and emerging spec components without destabilizing the core protocol that lots of production clients and servers already depend on.\nThe Extensions documentation covers the full details — including extension identifiers, capability negotiation during the initialization handshake, and the SEP (Specification Enhancement Proposal) process for proposing new ones.\nHere\u0026rsquo;s where it gets interesting. Extensions are patterns built on existing MCP mechanisms, and they\u0026rsquo;re strictly additive: a client or server that doesn\u0026rsquo;t recognize an extension simply skips it during negotiation, and the baseline protocol keeps working. Nothing breaks when one side hasn\u0026rsquo;t opted in.\nIn practice, a few of these patterns have already emerged — some now formalized as official extensions, others still exploratory:\nUI 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\u0026rsquo;s what MCP Apps enables. It\u0026rsquo;s the first official MCP extension and went GA in January 2026, with support already live in ChatGPT, Claude, VS Code, Goose, and more. Authorization extensions: Need machine-to-machine auth without a user in the loop, or centralized enterprise IdP control? The auth extensions layer these on top of MCP\u0026rsquo;s core OAuth framework — OAuth Client Credentials and Enterprise-Managed Authorization are both live today. Domain-specific extensions: Community groups are already exploring conventions for verticals like financial services, where developers might want standardized ways to handle compliance metadata. Another important side-effect to this approach is that MCP client and server developers get richer functionality without having to wait for protocol changes, which might need more extensive validation before being merged into the core.\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.\nHow extensions are governed Extensions are community-driven, and all of them are optional. Developers adopt what makes sense for their use case.\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 where they\u0026rsquo;re maintained collaboratively, following the Extensions Track SEP process.\nBeyond officially-supported extensions, community members and working groups are also free to define their own extensions for any custom needs.\nA note on proprietary integrations Some MCP clients ship their own proprietary features, like custom UI systems, that happen to use MCP under the hood. These are not necessarily considered MCP extensions. They integrate with MCP servers but they don\u0026rsquo;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.\nGet started If you\u0026rsquo;re building on MCP and want to explore extensions:\nRead the docs: The Extensions overview covers identifiers, negotiation, governance, and the full list of official extensions. Build an MCP App: Follow the MCP Apps quickstart to ship an interactive UI that works across supporting clients today. Check client support: See the Extension Support Matrix for which clients already implement which extensions. Propose your own: If you have an idea for a new extension, the SEP guidelines walk you through opening an Extensions Track SEP. Thank you This post wouldn\u0026rsquo;t exist without the MCP community. The ideas here grew out of countless conversations - working group calls, GitHub threads, extension proposals, and plenty of back-and-forth in Discord.\nTo everyone who\u0026rsquo;s contributed ideas, challenged our initial assumptions, and helped shape where this is all going: thank you.\nWe\u0026rsquo;ll keep sharing updates here on the blog and in the public repos. See you there.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2026-03-11-understanding-mcp-extensions/","summary":"\u003cp\u003eYou\u0026rsquo;ve built an MCP server that works quite well, but now you\u0026rsquo;re wondering: \u003cem\u003eHow do I add richer UI elements? Custom auth flows? What about domain-specific conventions, like those for finance or healthcare?\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThis is where \u003cem\u003eextensions\u003c/em\u003e 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\u0026rsquo;s needs in mind.\u003c/p\u003e","title":"Understanding MCP Extensions"},{"content":"MCP\u0026rsquo;s current spec release came out in November 2025. We haven\u0026rsquo;t cut a new version since, but the project hasn\u0026rsquo;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 (SEPs), and a formal governance process. None of that is news, but it\u0026rsquo;s the foundation we\u0026rsquo;re building on.\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 that lays out where we\u0026rsquo;re headed.\nIf you read the January update, you\u0026rsquo;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\u0026rsquo;s what changed and what it means for you.\nFrom Releases to Working Groups Previous versions of the roadmap were organized around release milestones: what\u0026rsquo;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.\nWorking and Interest Groups are now the primary vehicle for protocol development, and the roadmap needed to reflect that. The new document is organized around priority areas, rather than around dates. Working Groups drive the timeline for their deliverables. The roadmap tells you which problems we consider most important and points you to the groups working on them.\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.\nThe Priority Areas Core maintainers ranked candidate areas, and the result was a clear top four. These are the areas where SEPs will receive expedited review and where most of our maintainer capacity is concentrated.\nTransport Evolution and Scalability Streamable HTTP is the transport that lets MCP servers run as remote services rather than local processes. It unlocked a wave of production deployments. But running it at scale has surfaced a consistent set of gaps: stateful sessions fight with load balancers, horizontal scaling requires workarounds, and there\u0026rsquo;s no standard way for a registry or crawler to learn what a server does without connecting to it.\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.\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.\nAgent Communication The Tasks primitive (SEP-1686) shipped as an experimental feature and works well for what it was designed to do. Early production use has surfaced a concrete list of lifecycle gaps to close: retry semantics when a task fails transiently, and expiry policies for how long results are retained after completion.\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.\nGovernance Maturation Right now, every SEP requires full Core Maintainer review, regardless of domain. That\u0026rsquo;s a bottleneck. It slows down Working Groups that already have the expertise to evaluate proposals in their own area.\nThe goal is to remove that bottleneck without sacrificing quality. Concretely, that means a documented contributor ladder so there\u0026rsquo;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.\nEnterprise Readiness Enterprises are deploying MCP and running into a predictable set of problems: audit trails, SSO-integrated auth, gateway behavior, and configuration portability.\nThis is also the least defined of the four priorities, and that\u0026rsquo;s intentional. We want the people experiencing these challenges to help us define the work.\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 explains how to get started. We also recommend joining the contributor Discord to make sure you\u0026rsquo;re not duplicating work or going solo on new proposals.\nWe expect most of the enterprise readiness work to land as extensions rather than core spec changes. Enterprise needs are real, but they shouldn\u0026rsquo;t make the base protocol heavier for everyone else.\nSEP Prioritization: What It Means for Contributors One of the most practical additions to the roadmap is explicit guidance on how SEP review capacity gets allocated.\nThe short version: SEPs aligned with the priority areas above will move the fastest. SEPs outside those areas aren\u0026rsquo;t automatically rejected, but they face longer review timelines and a higher bar for justification. Maintainer bandwidth is finite, and we\u0026rsquo;d rather be transparent about where it\u0026rsquo;s going.\nIf you\u0026rsquo;re considering writing a SEP, start with the SEP Guidelines. Once you\u0026rsquo;re familiar with those:\nCheck whether your proposed change maps to one of the priority areas. If it does not, be prepared for delays in reviews. Bring it to the relevant Working Group. SEPs that arrive with WG backing and a clear connection to the roadmap are the ones that move. On the Horizon Not everything we care about made the top four, and we didn\u0026rsquo;t want those areas to disappear from view. We\u0026rsquo;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.\nThese aren\u0026rsquo;t deprioritized in the sense of \u0026ldquo;We don\u0026rsquo;t want them.\u0026rdquo; They\u0026rsquo;re areas where we\u0026rsquo;ll happily support a community-formed WG and review SEPs as time permits, but where Core Maintainers aren\u0026rsquo;t actively standing things up this cycle.\nSome of these already have active proposals in review, such as SEP-1932 (DPoP) and SEP-1933 (Workload Identity Federation). Others, like triggers and event-driven updates, would benefit from a new Working Group.\nGet Involved Every deliverable on the roadmap runs through a Working Group, and every Working Group is open to contributors. Here are a few ways to get involved:\nJoin a Working Group: Working Groups are the small teams doing the actual protocol design. They meet regularly and welcome new participants. The Working Groups \u0026amp; Interest Groups page lists what\u0026rsquo;s active and how to connect. Propose a SEP: SEPs are how changes to the protocol get proposed and reviewed. The SEP guidelines walk through the process. Start an extension: Extensions let us experiment with new capabilities outside the core spec. You can learn more in our official Extensions documentation. If you\u0026rsquo;re not sure where to start, the easiest first step is to join a Working Group meeting and introduce yourself.\nWe\u0026rsquo;re excited to build the protocol together!\n","permalink":"https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/","summary":"\u003cp\u003eMCP\u0026rsquo;s \u003ca href=\"https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/\"\u003ecurrent spec release\u003c/a\u003e came out in November 2025. We haven\u0026rsquo;t cut a new version since, but the project hasn\u0026rsquo;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, \u003ca href=\"https://modelcontextprotocol.io/community/sep-guidelines\"\u003eSpec Enhancement Proposals\u003c/a\u003e (SEPs), and a formal governance process. None of that is news, but it\u0026rsquo;s the foundation we\u0026rsquo;re building on.\u003c/p\u003e","title":"The 2026 MCP Roadmap"},{"content":"Today, we\u0026rsquo;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\u0026rsquo;s ready for production.\nWe proposed MCP Apps last November, building on the amazing work of MCP-UI and the OpenAI Apps SDK. We were excited to partner with both OpenAI and MCP-UI to create a shared open standard for providing affordances for developers to include UI components in their MCP clients.\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.\nGet Started with MCP Apps → What Are MCP Apps? MCP Apps let tools return rich, interactive interfaces instead of plain text. When a tool declares a UI resource, the host renders it in a sandboxed iframe, and users interact with it directly in the conversation.\nHere are a few scenarios where MCP Apps shine:\nData exploration: A sales analytics tool returns an interactive dashboard. Users filter by region, drill down into specific accounts, and export reports without leaving the conversation. Configuration wizards: A deployment tool presents a form with dependent fields. Selecting \u0026ldquo;production\u0026rdquo; reveals additional security options; selecting \u0026ldquo;staging\u0026rdquo; shows different defaults. Document review: A contract analysis tool displays the PDF inline with highlighted clauses. Users click to approve or flag sections, and the model sees their decisions in real time. Real-time monitoring: A server health tool shows live metrics that update as systems change. No need to re-run the tool to see current status. These interactions would be less smooth as text exchanges, whereas MCP Apps make them natural - it\u0026rsquo;s like using any other UI-based web app.\nHow It Works The architecture of MCP Apps relies on two key MCP primitives:\nTools with UI metadata: Tools include a _meta.ui.resourceUri field pointing to a UI resource UI Resources: Server-side resources served via the ui:// scheme containing bundled HTML/JavaScript // Tool with UI metadata { name: \u0026#34;visualize_data\u0026#34;, description: \u0026#34;Visualize data as an interactive chart\u0026#34;, inputSchema: { /* ... */ }, _meta: { ui: { resourceUri: \u0026#34;ui://charts/interactive\u0026#34; } } } The host fetches the resource, renders it in a sandboxed iframe, and enables bidirectional communication via JSON-RPC over postMessage.\nWhy MCP Apps? MCP is great for connecting models to data and giving them the ability to take actions. But there\u0026rsquo;s still a context gap between what tools can do and what users can see.\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. \u0026ldquo;Show me just the ones from last week.\u0026rdquo; \u0026ldquo;Sort by revenue.\u0026rdquo; \u0026ldquo;What\u0026rsquo;s the detail on row 47?\u0026rdquo; It works, but it\u0026rsquo;s slow.\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\u0026rsquo;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.\nThe App API To build new MCP Apps, developers can use the @modelcontextprotocol/ext-apps package, which provides an App class for UI-to-host communication:\nimport { App } from \u0026#34;@modelcontextprotocol/ext-apps\u0026#34;; const app = new App(); await app.connect(); // Receive tool results from the host app.ontoolresult = (result) =\u0026gt; { renderChart(result.data); }; // Call server tools from the UI const response = await app.callServerTool({ name: \u0026#34;fetch_details\u0026#34;, arguments: { id: \u0026#34;123\u0026#34; }, }); // Update model context await app.updateModelContext({ content: [{ type: \u0026#34;text\u0026#34;, text: \u0026#34;User selected option B\u0026#34; }], }); Because apps run inside the client, they can do things a plain iframe can\u0026rsquo;t. They can log events for debugging, open links in the user\u0026rsquo;s browser, send follow-up messages to drive the conversation forward, or quietly update the model\u0026rsquo;s context for later. All of this happens over standard postMessage, so you\u0026rsquo;re not locked into any framework.\nSecurity Model Running UI from MCP servers means running code you didn\u0026rsquo;t write within your MCP host. MCP Apps handles this through multiple layers:\nIframe sandboxing: All UI content runs in sandboxed iframes with restricted permissions Pre-declared templates: Hosts can review HTML content before rendering Auditable messages: All UI-to-host communication goes through loggable JSON-RPC User consent: Hosts can require explicit approval for UI-initiated tool calls If something looks suspicious, hosts can block it before it ever renders. Of course, users should continue to proactively and thoroughly vet MCP servers before connecting them.\nThe Future of Agentic UI Frameworks MCP-UI and OpenAI Apps SDK pioneered the patterns that MCP Apps now standardizes. The projects proved that UI resources can and do fit naturally within the MCP ecosystem, with enterprises of all sizes adopting both the OpenAI and MCP-UI SDKs for production applications.\nMCP-UI isn\u0026rsquo;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\u0026rsquo;re already using MCP-UI, keep using it. Migration to the official extension is straightforward when you\u0026rsquo;re ready.\nClient Support MCP Apps are supported in:\nClaude - available today both on web and desktop experiences Goose - available today Visual Studio Code - available in Visual Studio Code Insiders ChatGPT - starting this week For the first time, an MCP tool developer can ship an interactive experience that works across a broad range of widely-adopted clients without writing a single line of client-specific code.\n\u0026ldquo;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.\u0026rdquo;\nDavid Soria Parra, Co-Creator of MCP and Member of Technical Staff, Anthropic “MCP Apps builds upon the foundations of MCP-UI and the ChatGPT Apps SDK to give people a rich visually interactive experience. We\u0026rsquo;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.”\nNick Cooper, Member of Technical Staff, OpenAI “MCP Apps extends the Model Context Protocol in a way that puts humans at the center. The industry has embedded assistants into individual apps, creating fragmented, siloed experiences. MCP inverts this by making apps pluggable components within agents. MCP Apps extends this further by bringing user interfaces into the agent experience itself.\ngoose, 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\u0026rsquo;re excited to support this standard and see where developers take it.”\nAndrew Harvard, Design Engineer, Agentic UX, Block “As MCP evolves from ‘tools’ into a real platform for agentic work, VS Code has been treating the protocol like a contract: implement the full spec, track the latest transports and capabilities, and make sure server authors can rely on what they build actually behaving the same way for real developers. With MCP Apps, that contract finally includes the missing human step: when the workflow needs a decision, a selection, or exploration, the client can give you the right interaction without turning the conversation into a choose-your-own-adventure prompt.”\nHarald Kirschner, Principal Product Manager, VS Code, Microsoft “The MCP Apps extension addresses a gap we have experienced first-hand: text and structured data only gets you so far when developers want rich, interactive tooling. The ability to render dynamic UIs directly from MCP servers, with security built in from day one, is exactly what we need to build better agentic experiences. JetBrains is excited to explore bringing this extension to our IDEs and continue working with the MCP Community.”\nDenis Shiryaev, Head of AI DevTools Ecosystem, JetBrains “MCP Apps address a real gap between what agentic tools can provide and how users naturally want to interact with them. The ability to render dynamic interfaces directly in conversation makes it easier to leverage MCP server capabilities in practical ways. We\u0026rsquo;re excited to see this extension deliver richer interactions for users while enabling MCP server developers to craft experiences tailored to what they\u0026rsquo;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.“\nClare Liguori, Senior Principal Engineer, AWS \u0026ldquo;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.\u0026rdquo;\nAnshul Ramachandran, Product Lead, Antigravity, Google DeepMind This is just the starting lineup, and adding support to a new client is as easy as following the implementation guide.\nGet Started The ext-apps repository includes the SDK and working examples: threejs-server for 3D visualization, map-server for interactive maps, pdf-server for document viewing, system-monitor-server for real-time dashboards, sheet-music-server for music notation, and many more.\nPick one close to what you\u0026rsquo;re building and start from there!\nResources Documentation: MCP Apps Guide Quickstart: Getting Started with MCP Apps SDK: @modelcontextprotocol/ext-apps Examples: ext-apps repository Claude.ai Feedback If you\u0026rsquo;re building MCP Apps for Claude.ai and encounter issues with our implementation, please report them at github.com/anthropics/claude-ai-mcp. This helps us improve the experience for everyone.\nChatGPT Apps SDK Feedback If you\u0026rsquo;re building apps with the ChatGPT Apps SDK and run into issues or have questions, please post in the ChatGPT Apps category on the OpenAI Community forum. This is where app developers, community moderators, and the OpenAI team actively engage to discuss builds, troubleshoot problems, and improve the overall developer experience.\nAcknowledgements MCP Apps is the result of collaboration across multiple teams and communities.\nIdo 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.\nNick Cooper at OpenAI helped deliver the OpenAI Apps SDK, enabling everyone to go beyond text in their interactions with Large Language Models.\nSean Strong, Olivier Chafik, Anton Pidkuiko, and Jerome Swannack from Anthropic helped steer the initiative from proposal to production.\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.\nThank you to everyone who contributed. Now go build something.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/","summary":"\u003cp\u003eToday, we\u0026rsquo;re announcing that \u003cstrong\u003eMCP Apps are now live as an official MCP extension\u003c/strong\u003e.\nTools can now return interactive UI components that render directly in the\nconversation: dashboards, forms, visualizations, multi-step workflows, and more.\nThis is the first official MCP extension, and it\u0026rsquo;s ready for production.\u003c/p\u003e\n\u003cdiv class=\"youtube-container\"\u003e\n  \u003ciframe\n    src=\"https://www.youtube.com/embed/bluAmTHoEow\"\n    title=\"YouTube video\"\n    frameborder=\"0\"\n    allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\"\n    allowfullscreen\u003e\n  \u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003cstyle\u003e\n.youtube-container {\n  position: relative;\n  width: 100%;\n  padding-bottom: 56.25%;  \n  margin: 24px 0;\n}\n\n.youtube-container iframe {\n  position: absolute;\n  top: 0;\n  left: 0;\n  width: 100%;\n  height: 100%;\n  border-radius: 8px;\n}\n\u003c/style\u003e\n\n\u003cp\u003eWe proposed MCP Apps\n\u003ca href=\"https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/\"\u003elast November\u003c/a\u003e, building on\nthe amazing work of \u003ca href=\"https://mcpui.dev\"\u003eMCP-UI\u003c/a\u003e and the\n\u003ca href=\"https://developers.openai.com/apps-sdk/\"\u003eOpenAI Apps SDK\u003c/a\u003e. We were excited to partner with\nboth OpenAI and MCP-UI to create a shared open standard for providing affordances for\ndevelopers to include UI components in their MCP clients.\u003c/p\u003e","title":"MCP Apps - Bringing UI Capabilities To MCP Clients"},{"content":"A lot has happened since we first released MCP. We wrapped up 2025 with a major spec update and the momentum hasn\u0026rsquo;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.\nTo keep that momentum going, the Core Maintainer team is evolving as well.\nDeparting Core Maintainers First, some news. Inna Harper and Basil Hosmer will be stepping away from the Core Maintainer team to focus on other projects.\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.\nThank you both for your contributions and your dedication to the project. MCP is better because of you.\nWelcoming New Maintainers We\u0026rsquo;re thrilled to welcome three new Core Maintainers to the team. They\u0026rsquo;ve already been active in MCP discussions, reviewing Spec Enhancement Proposals (SEPs), and helping shape the direction of the protocol.\nPeter Alexander Peter Alexander is a Member of Technical Staff at Anthropic on the Model Context Protocol team.\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.\nPeter has authored several SEPs including the Extensions framework and Resource Contents Metadata, and has been an active reviewer and contributor to our SDKs, proposals around governance, roadmap, and specification changes.\nCaitie McCaffrey Caitie McCaffrey is a Software Engineer and Tech Lead at Microsoft. Caitie has built large-scale distributed systems and services across multiple domains, including AI platforms, gaming, social media, and IoT.\nPreviously, Caitie served as Technical Advisor to Microsoft\u0026rsquo;s CEO Satya Nadella and CTO Kevin Scott, driving strategic efforts in AI transformation, developer experience \u0026amp; 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 \u0026amp; 3. She holds a Computer Science degree from Cornell University.\nCaitie has been reviewing and helping us craft our governance and transport proposals, bringing her distributed systems expertise to protocol design discussions.\nKurtis Van Gent Kurtis Van Gent is a Senior Staff Software Engineer leading AI Ecosystems at Google Cloud Databases. He drives ecosystems and integrations across the portfolio, leading efforts like MCP for Data Cloud and MCP Toolbox for Databases.\nKurtis has been driving the Transport Working Group, which authored the accepted request payload decoupling SEP and is leading the stateless protocol proposal. His focus on scalability and fault tolerance has shaped key discussions around how MCP evolves.\nWelcome to the team, Peter, Caitie, and Kurtis.\nLooking Ahead If there is one thing I can guarantee it\u0026rsquo;s that 2026 will be a busy year for MCP. There are multiple active SEPs working through the process right now, including ones like the DPoP extension for authentication, multi-turn SSE for transport, and Server Cards for discovery. This is just a sneak peek of the many improvements we\u0026rsquo;re currently iterating on. The ecosystem keeps expanding, with more clients, servers, and SDK releases shipping every week.\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\u0026rsquo;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\u0026rsquo;re keeping the contributor experience welcoming and the protocol responsive to what developers actually need.\nIf you want to be part of it, check out our governance docs or see how to get started with MCP contributions. Come build with us.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2026-01-22-core-maintainer-update/","summary":"\u003cp\u003eA lot has happened since we first released MCP. We wrapped up 2025 with a \u003ca href=\"/posts/2025-11-25-first-mcp-anniversary/\"\u003emajor spec update\u003c/a\u003e and the momentum hasn\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eTo keep that momentum going, the \u003ca href=\"https://modelcontextprotocol.io/community/governance#current-core-maintainers\"\u003eCore Maintainer\u003c/a\u003e team is evolving as well.\u003c/p\u003e\n\u003ch2 id=\"departing-core-maintainers\"\u003eDeparting Core Maintainers\u003c/h2\u003e\n\u003cp\u003eFirst, some news. \u003cstrong\u003eInna Harper\u003c/strong\u003e and \u003cstrong\u003eBasil Hosmer\u003c/strong\u003e will be stepping away from the Core Maintainer team to focus on other projects.\u003c/p\u003e","title":"January MCP Core Maintainer Update"},{"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. As MCP became the go-to standard for LLM integrations, community needs evolved, leading to the build-out of infrastructure around remote servers. There\u0026rsquo;s now growing demand for distributed deployments that can operate at scale.\nThe 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.\nSome of these challenges include:\nInfrastructure Complexity: Load balancers and API gateways must parse full JSON-RPC payloads to route traffic, rather than using standard HTTP patterns. Scaling Friction: Stateful connections force \u0026ldquo;sticky\u0026rdquo; routing that pins traffic to specific servers, preventing effective auto-scaling. High Barrier for Simple Tools: Developers building simple, ephemeral tools are often required to manage complex backend storage to support basic multi-turn interactions. Ambiguous Session Scope: There is no predictable mechanism for defining where a conversation context starts and ends across distributed systems. Roadmap Over the past few months, the Transport Working Group has worked together with the community and MCP Core Maintainers to develop solutions to these challenges.\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.\nA Stateless Protocol MCP was originally designed as a stateful protocol. Clients and servers maintain mutual awareness through a persistent, bidirectional channel that begins with a handshake to exchange capabilities and protocol version information. Because this state remains fixed throughout the connection, scaling requires techniques like sticky sessions or distributed session storage.\nWe envision a future where agentic applications are stateful, but the protocol itself doesn\u0026rsquo;t need to be. A stateless protocol enables scale, while still providing features to support stateful application sessions when needed.\nWe are exploring ways to make MCP stateless by:\nReplacing the initialize handshake and sending the shared information with each request and response instead. Providing a discovery mechanism for clients to query server capabilities if they need the information early, for scenarios such as UI hydration. These changes enable a more dynamic model where clients can optimistically attempt operations and receive clear error messages if a capability is unsupported.\nNOTE: Many SDKs already offer a stateless option in their server transport configuration, though the behavior varies across implementations. As part of this roadmap, we\u0026rsquo;ll be working to standardize what \u0026ldquo;stateless\u0026rdquo; means across all official SDKs to ensure consistent behavior.\nElevating Sessions Currently, sessions are a side effect of the transport connection. With STDIO, sessions are implicit in the process lifecycle; with Streamable HTTP, sessions are created when a server assigns an Mcp-Session-Id during initialization. This can lead to confusion between transport and application layer concerns.\nWe are looking at moving sessions to the data model layer, making them explicit rather than implicit.\nThis would allow MCP applications to handle sessions as part of their domain logic. We\u0026rsquo;re exploring several approaches, with a cookie-like mechanism being one potential candidate to decouple session state from the transport layer.\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.\nElicitations and Sampling Two MCP features are central to a few of the modern AI workflows: Elicitations, which request human input, and Sampling, which enable agentic LLM interactions.\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.\nTo address this, we\u0026rsquo;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.\nUpdate Notifications and Subscriptions MCP is dynamic by design - tools, prompts, and resources can change during operation. Today, servers send ListChangedNotification messages to clients as a hint to invalidate their caches.\nWe\u0026rsquo;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.\nTo make notifications truly optional - an optimization rather than a requirement - we\u0026rsquo;re considering adding Time-To-Live (TTL) values and version identifiers (such as ETags) to data. This would let clients make intelligent caching decisions independently of the notification stream, significantly improving reliability.\nJSON-RPC Envelopes MCP uses JSON-RPC for all message envelopes, including method names and parameters. As we optimize for HTTP deployments, a common question is whether routing information should be more accessible to the underlying MCP server infrastructure.\nWhile we\u0026rsquo;re keeping JSON-RPC as the message format, we\u0026rsquo;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.\nServer Cards Today, clients must complete a full initialization handshake just to learn basic information about an MCP server, like its capabilities or available tools. This creates friction for discovery, integration, and optimization scenarios.\nWe\u0026rsquo;re exploring the direction of introducing MCP Server Cards: structured metadata documents that servers expose through a standardized /.well-known/mcp.json endpoint. Server Cards enable clients to discover server capabilities, authentication requirements, and available primitives before establishing a connection. This unlocks use cases like autoconfiguration, automated discovery, static security validation, and reduced latency for UI hydration — all without requiring the full initialization sequence.\nOfficial and Custom Transports To ensure a minimum compatibility baseline across the ecosystem, MCP will continue to support only two official transports: STDIO for local deployments and Streamable HTTP for remote deployments. This keeps the core ecosystem unified, where every MCP client and server can interoperate out of the box.\nWe also recognize that transport and protocol changes can be disruptive. Backwards compatibility is a priority, and we\u0026rsquo;ll only introduce breaking changes when strictly necessary for critical use cases.\nFor teams with specialized requirements, the MCP Specification supports Custom Transports, giving developers the flexibility to build alternatives that fit their needs. Our focus is on making Custom Transports easier to implement by improving SDK integration—so the community can experiment freely without fragmenting the standard.\nSummary These changes reorient MCP around stateless, independent requests - without sacrificing the rich features that make it powerful. Server developers get simpler horizontal scaling with no sticky sessions or distributed stores. Clients get a more predictable architecture.\nFor most SDK users, both on the client and server sides, the impact will be minimal - we\u0026rsquo;re focused on reducing breaking changes to the absolute minimum. The shift we\u0026rsquo;re outlining is architectural: simpler deployments, serverless viability for advanced MCP features, and better alignment with modern infrastructure patterns.\nNext Steps Work is already underway. Our goal is to finalize the required Spec Enhancement Proposals (SEPs) in the first quarter of 2026 for inclusion in the next specification release, which is tentatively slated for June of 2026. With these changes, MCP can easily scale while keeping the ergonomics that made it successful.\nWe want your input. Join us in the MCP Contributors Discord server, or engage directly with transport-related SEPs in the Model Context Protocol repository.\nThis roadmap is shaped by real-world feedback from developers and companies building with MCP. We\u0026rsquo;re excited to collaborate with the MCP community to continuously improve the protocol and its capabilities!\n","permalink":"https://blog.modelcontextprotocol.io/posts/2025-12-19-mcp-transport-future/","summary":"\u003cp\u003eWhen MCP first launched in November of 2024, quite a few of its users relied on local environments, connecting clients to servers over \u003ca href=\"https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#stdio\"\u003eSTDIO\u003c/a\u003e. As MCP became the go-to standard for LLM integrations, community needs evolved, leading to the build-out of infrastructure around remote servers. There\u0026rsquo;s now growing demand for distributed deployments that can operate at scale.\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#streamable-http\"\u003eStreamable HTTP\u003c/a\u003e 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.\u003c/p\u003e","title":"Exploring the Future of MCP Transports"},{"content":"Today marks a major milestone for the Model Context Protocol. Anthropic is donating MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. MCP will become a founding project of the newly created foundation.\nIn one year, MCP has become one of the fastest-growing and widely-adopted open-source projects in AI: Over 97 million monthly SDK downloads, 10,000 active servers and first-class client support across major AI platforms like ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code and many more.\nSince its inception, we\u0026rsquo;ve remained committed to ensuring MCP remains open and community-driven. This move formalizes that commitment—ensuring MCP\u0026rsquo;s vendor-neutrality and long-term independence under the same neutral stewardship that supports Kubernetes, PyTorch, and Node.js. Anthropic\u0026rsquo;s commitment to MCP is unchanged: we will continue to invest in its development, maintain core infrastructure, and actively participate in the community.\nThe Agentic AI Foundation MCP will be a founding project of the newly created Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg to advance open-source innovation in agentic AI.\nMCP joins two other founding projects: goose by Block and AGENTS.md by OpenAI as founding projects.\nThe AAIF Governing Board will make decisions regarding strategic investments, budget allocation, member recruitment, and approval of new projects, while individual projects, such as MCP, maintain full autonomy over their technical direction and day-to-day operations.\nMCP\u0026rsquo;s maintainer structure stays the same For MCP little changes. The governance model we introduced earlier this year continues as is. The people making decisions about the protocol are still the maintainers who have been stewarding it, guided by community input through our SEP process.\nThe Linux Foundation provides a neutral home and infrastructure that allows maintainers to operate independently, and will not dictate the technical direction of MCP.\nThank you To all who\u0026rsquo;ve adopted and contributed to MCP so far, thank you. None of this would\u0026rsquo;ve been possible without your contribution. From building servers to maintaining SDKs to filing issues to improving documentation to welcoming new visitors and everything in between, you\u0026rsquo;ve made MCP what it is today.\nHere\u0026rsquo;s to MCP\u0026rsquo;s next chapter under the Linux Foundation\u0026rsquo;s stewardship.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/","summary":"\u003cp\u003eToday marks a major milestone for the Model Context Protocol. Anthropic is donating MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. MCP will become a founding project of the newly created foundation.\u003c/p\u003e\n\u003cp\u003eIn one year, MCP has become one of the fastest-growing and widely-adopted open-source projects in AI: Over 97 million monthly SDK downloads, 10,000 active servers and first-class client support across major AI platforms like ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code and many more.\u003c/p\u003e","title":"MCP joins the Agentic AI Foundation"},{"content":"We\u0026rsquo;re updating how Specification Enhancement Proposals (SEPs) are submitted and managed. Starting today, SEPs will be created as pull requests to the seps/ directory instead of GitHub issues.\nWhy the Change? When we introduced SEPs in July, we chose GitHub Issues as our starting point. Issues are familiar to developers, low-friction, and got us up and running quickly. But as more proposals have come through the process, we\u0026rsquo;ve identified some key pain points:\nScattered 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.\nNo version history. Issues don\u0026rsquo;t have the same revision tracking that files in a repository do. When a SEP evolves through review, it\u0026rsquo;s difficult to see what changed and when.\nThe new PR-based approach, inspired by Python\u0026rsquo;s PEP process, solves both problems.\nHow It Works The new workflow will be familiar if you\u0026rsquo;ve submitted pull requests on GitHub before:\nDraft your SEP as a markdown file named 0000-your-feature.md using the SEP template\nCreate a pull request adding your SEP to the seps/ directory\nUpdate 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\nFind a sponsor from our maintainer list to shepherd your proposal\nIterate on feedback directly in the PR\nThat\u0026rsquo;s it. The PR number becomes the SEP number, discussion happens in one place, and git tracks every revision.\nWhat About Status? One notable change: sponsors are now responsible for updating SEP status. In addition to applying labels to the pull request, the sponsor is responsible for ensuring that the Status field is updated in the SEP markdown file. This keeps the canonical state of the proposal in the file itself, versioned alongside the content, while PR labels make it easy to filter and find SEPs by status.\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.\nGetting Started Ready to propose a change to MCP? Here\u0026rsquo;s what you need to know:\nFor new SEPs:\nRead the latest SEP Guidelines Use the SEP template to create your proposal Browse existing SEPs in the seps/ directory for examples Follow the workflow described above For existing SEPs: If you have a SEP submitted as a GitHub issue, you can continue with your current workflow. We strongly encourage migrating to the new process for better version control and centralized discussion. To migrate:\nCreate a markdown file using the SEP template, starting with 0000-your-feature.md Copy and adapt your proposal content to fit the template structure Submit a pull request to the seps/ directory Rename the file using your new PR number (e.g., PR #1900 becomes 1900-your-feature.md) Close the original issue with a link to the new PR The new PR gets a fresh SEP number and gives your proposal proper version control and centralized discussion. Any valuable context from the original issue discussion should be summarized in the new SEP or referenced via links.\nAs always, if you\u0026rsquo;re unsure whether your idea warrants a SEP, start a conversation on Discord or GitHub Discussions. We\u0026rsquo;re happy to help you figure out the right path forward.\nThank You This change is a direct result of feedback from contributors who\u0026rsquo;ve been through the SEP process. Your input helps us continuously improve how we build MCP together. Keep it coming.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2025-11-28-sep-process-update/","summary":"\u003cp\u003eWe\u0026rsquo;re updating how Specification Enhancement Proposals (SEPs) are submitted and managed. Starting today, SEPs will be created as pull requests to the \u003ca href=\"https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps\"\u003e\u003ccode\u003eseps/\u003c/code\u003e directory\u003c/a\u003e instead of GitHub issues.\u003c/p\u003e\n\u003ch2 id=\"why-the-change\"\u003eWhy the Change?\u003c/h2\u003e\n\u003cp\u003eWhen we \u003ca href=\"https://blog.modelcontextprotocol.io/posts/2025-07-31-governance-for-mcp/\"\u003eintroduced SEPs in July\u003c/a\u003e, 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\u0026rsquo;ve identified some key pain points:\u003c/p\u003e","title":"SEPs Are Moving to Pull Requests"},{"content":"Today, MCP turns one year old. You can check out the original announcement blog post if you don\u0026rsquo;t believe us. It\u0026rsquo;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.\nBut not only do we hit the first anniversary milestone today - we\u0026rsquo;re also releasing a brand-new MCP specification version. Before we get to the details of what\u0026rsquo;s new, let\u0026rsquo;s do a bit of a retrospective.\nA Year In With all the changes that we\u0026rsquo;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).\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\u0026rsquo;s likely there\u0026rsquo;s an MCP server for it.\nHere are just a few of many (very many) MCP servers that you can try today:\nNotion built an MCP server to help you manage your notes. Stripe has a pretty extensive MCP server to manage all kinds of payment workflows. GitHub built their own MCP server to help developers automate their engineering processes. Hugging Face created an MCP server to make model management and dataset search a breeze. Postman built their MCP server to help automate API testing workflows. And there\u0026rsquo;s so much more to discover in the MCP ecosystem! That\u0026rsquo;s why we also launched the MCP Registry earlier this year. It\u0026rsquo;s the central index for all available MCP servers that now has close to two thousand entries since its announcement in September. That\u0026rsquo;s a 407% growth from the initial batch of servers we onboarded that same month.\nThe ecosystem is blooming, adoption is growing, but what\u0026rsquo;s underpinning all of this?\nCommunity \u0026amp; Governance MCP\u0026rsquo;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\u0026rsquo;s even a Blender MCP server). That kind of organic adoption isn\u0026rsquo;t something you can just come up with, no matter how ambitious your aspirations are with an open source project.\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, MCP Night, MCP Dev Days, and showing up at other marquee events like AI Engineer World\u0026rsquo;s Fair to share what they learned and built.\nWe also nurtured large contributor communities on Discord and on GitHub, helping us debug issues, build amazing tools like the MCP Inspector, propose changes, and assist each other in shipping great MCP experiences. That kind of daily collaboration got us further than any single individual or company ever could.\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.\nTo keep this pace sustainable, we spent some time thinking through and putting together a governance structure. Through it, community leaders and Anthropic maintainers were and continue to work together to figure out what needs fixing and how to get the right changes into the spec. Our maintainer team isn\u0026rsquo;t there to gatekeep; they help surface problems, align on solutions, and turn rough ideas into actual protocol updates.\nOur approach to governance, while still evolving, proved itself to be extremely valuable. We\u0026rsquo;ve been able to move faster on critical improvements without breaking existing implementations. Potential contributors now also know how to jump in through formal Working and Interest Groups (SEP-1302 set the stage for this).\nEven though this is a significant improvement, we know that we\u0026rsquo;re not done. There\u0026rsquo;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\u0026rsquo;s been part of this journey and helped us navigate so many changes in such a short time span.\nWhat Others Have To Say As we called out above, the success of MCP would not be possible without the broader community of adopters. We\u0026rsquo;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\u0026ldquo;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.\u0026rdquo;\n✦ Mario Rodriguez, CPO, GitHub\n\u0026ldquo;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.\u0026rdquo;\n✦ Srinivas Narayanan, CTO of B2B Applications, OpenAI\n\u0026ldquo;In the year since its launch, MCP has become an incredibly impactful open standard in the industry,\u0026rdquo; said Dhanji R. Prasanna, CTO of Block. \u0026ldquo;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.\u0026rdquo;\n✦ Dhanji Prasanna, CTO, Block\n\u0026ldquo;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.\u0026rdquo;\n✦ Asha Sharma, President, CoreAI, Microsoft\n\u0026ldquo;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.\u0026rdquo;\n✦ Julien Chaumond, CTO, Hugging Face\n\u0026ldquo;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.\u0026rdquo;\n✦ Harish Peri, SVP \u0026amp; GM, AI Security, Okta\n\u0026ldquo;We\u0026rsquo;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\u0026rsquo;re excited to continue to collaborate with this community to make agent interoperability seamless for developers.\u0026rdquo;\n✦ Swami Sivasubramanian, VP, Agentic AI, AWS\n\u0026ldquo;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.\u0026rdquo;\n✦ Anna Berenberg, Engineering Fellow, Google Cloud\n\u0026ldquo;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\u0026rdquo;\n✦ Shannon Williams, President and Co-Founder, Obot AI; Organizer, MCP Dev Summit\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\u0026ldquo;As a community moderator and maintainer, I keep coming back to something Donella Meadows wrote: \u0026ldquo;Systems can\u0026rsquo;t be controlled, but they can be designed and redesigned\u0026hellip; 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.\u0026rdquo;\nWhat made this year\u0026rsquo;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.\nAs someone who\u0026rsquo;s merged hundreds of pull requests across MCP repos, I still feel like I\u0026rsquo;m barely keeping up with this velocity. I mean that in the most positive way. Better patterns and practices are emerging from the sheer volume of contributions and breadth of experience and expertise represented in the contributor community. As a random person from the Internet, I appreciate that pretty much anyone can bring something to the table. This includes standout maintainers like Cliff Hall, who raises the bar for reviewing, testing, and giving feedback, and Jonathan Hefner, who\u0026rsquo;s done the same for documentation.\nAs Darren Shepard recently put it:\n\u0026lsquo;People think the value of MCP is the protocol. The value is getting people to agree and do something.\u0026rsquo;\nMCP 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.\u0026rdquo;\n✦ Ola Hungerford, Principal Engineer, Nordstrom; MCP Maintainer and Community Lead\n\u0026ldquo;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.\nI 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\u0026rsquo;s the ethos driving decision-making, everyone\u0026rsquo;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.\nThat ethos has translated to community governance, too. There\u0026rsquo;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\u0026rsquo;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\u0026rsquo;s worth of time.\nThat doesn\u0026rsquo;t even begin to touch on the thousands of MCP implementors or millions of MCP end-users. It\u0026rsquo;s inspiring to see the often-competitive AI community rally around a foundational piece of infrastructure; I\u0026rsquo;m thankful for that willingness to collaborate and look forward to seeing where our second year takes us.\u0026rdquo;\n✦ Tadas Antanavicius, Co-Creator, PulseMCP; MCP Maintainer and Community Lead\nWe are immensely grateful for our partners and community for helping us bring the protocol to where it is today. Let\u0026rsquo;s now jump into the latest big release - the 2025-11-25 version of the MCP specification.\nThe November 2025 Release The latest release of the MCP specification ships with a number of highly-anticipated features that came directly from our community deploying and using MCP for production scenarios. People told us what wasn\u0026rsquo;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.\nSupport for Task-based Workflows SEP: 1686\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.\nTasks support a variety of states including working, input_required, completed, failed, and cancelled, allowing clients to effectively manage multi-step operations.\nSome noteworthy capabilities that this feature enables:\nActive polling: Clients can check the status of ongoing work at any time. Result retrieval: Results of completed tasks are accessible after the request has completed. Flexible lifecycle management: Support for working, input_required, completed, failed, and cancelled states. Task isolation: Proper security boundaries with session-based access control. From the multitude of MCP servers that we\u0026rsquo;ve seen out there, this is particularly helpful for scenarios such as the ones below.\nHealthcare \u0026amp; life sciences data analysis that processes hundreds of thousands of data points Enterprise automation platforms with complex multi-step workflows Code migration tools that run for minutes or hours Test execution platforms that need to stream logs from long-running suites Deep research tools that spawn multiple agents internally Multi-agent systems where agents can work concurrently Tasks are launching as an experimental capability, meaning that it\u0026rsquo;s part of the core protocol but it\u0026rsquo;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\u0026rsquo;ll work closely with the community, SDK developers, as well as client and server implementers to get this right.\nSimplified Authorization Flows One of the top painpoints from the community when it comes to authorization has been Dynamic Client Registration, or DCR. This capability is needed because in the MCP world there is an unbounded number of clients and servers, so doing standard client pre-registration is not always feasible. You wouldn\u0026rsquo;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.\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\u0026rsquo;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\u0026rsquo;t actually solve the fundamental problems with Dynamic Client Registration.\nThe alternative would be for every customer or end user to provide their own client registration, but that\u0026rsquo;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.\nSEP-991 introduced a much more elegant solution to the problem - URL-based client registration using OAuth Client ID Metadata Documents (you might\u0026rsquo;ve already seen our blog post on this change from earlier this year). Clients can now provide their own client ID that is a URL pointing to a JSON document the client manages that describes properties of the client.\nYou can learn more in the Client ID Metadata Documents Flow section of the MCP authorization specification.\nSecurity and Enterprise Features As the protocol matures, we also can\u0026rsquo;t ignore the myriad of security and authentication/authorization needs. MCP is not just a hobby protocol - we\u0026rsquo;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.\nWorking with security and authentication experts from across the community, we\u0026rsquo;ve developed a number of enhancements shipping with this release:\nSEP-1024: Client security requirements for local server installation SEP-835: Default scopes definition in authorization specification We also hear loud and clear from the industry that discovery and management of internal registries is an important component to the MCP story. With the help of the MCP Registry team, we\u0026rsquo;ve also established a vision for the ecosystem that will help enterprises adopt their own MCP registries, with self-managed governance controls and security coverage.\nTo learn more about other upcoming auth and security improvements you can follow the auth and security tags in the specification repository.\nExtensions As MCP continues to evolve, we constantly hear from developers who want to extend the protocol with specialized capabilities, whether for UI interactions, custom authentication flows, or other environment-specific logic. While these additions could be valuable, incorporating them directly into the core specification isn\u0026rsquo;t always practical from the get-go, especially when a feature hasn\u0026rsquo;t yet achieved broad adoption or proven its universal applicability.\nTo address this, we\u0026rsquo;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.\nExtensions are:\nOptional. Server and client implementors can choose to adopt these extensions. Additive. Extensions do not modify or break core protocol functionality; they add new capabilities while preserving core protocol behavior. Composable. Extensions are modular and designed to work together without conflicts, allowing implementations to adopt multiple extensions simultaneously. Versioned independently. Extensions follow the core MCP versioning cycle but may adopt independent versioning as needed. You might\u0026rsquo;ve already seen our announcement of the MCP Apps Extension proposal. In this specification release, we\u0026rsquo;re introducing a couple of other extensions that should help developers further.\nAuthorization Extensions To make MCP better suited for environments that require specific levels of control over the authorization process, we\u0026rsquo;ve officially introduced the concept of authorization extensions (building on the broader MCP Extensions). As with all other extensions, authorization extensions build on the core protocol and define additional authorization mechanisms that can be implemented by both server and client developers.\nThe first two authorization extensions came on the heels of community feedback regarding some of the most-used authorization flows:\nSEP-1046: OAuth client credentials support for machine-to-machine authorization SEP-990: Enterprise IdP policy controls for MCP OAuth flows (Cross App Access). This enables users within an enterprise to sign in to the MCP client once, and immediately get access to every authorized MCP server without additional authorization prompts. As we engage closer with the community, we expect the number of authorization extensions to grow as well - after all, there are more than just a few ways for a system to acquire and manage credentials.\nURL Mode Elicitation: Secure Out-of-Band Interactions SEP: 1036\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\u0026rsquo;t quite work. Until now, there wasn\u0026rsquo;t a good alternative - you either had to trust the client to handle the user\u0026rsquo;s credentials directly, or implement a bunch of custom authorization logic to be used from the start.\nURL 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.\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:\nSecure credential collection: API keys and passwords never transit through the MCP client External OAuth flows: MCP servers have a path to obtain third-party authorization without token passthrough Payment processing: PCI-compliant financial transactions with secure browser contexts can now be done outside the client All the server does is send a URL that the client will provide an affordance for. When the user completes the flow in their browser, the server will get the necessary tokens directly, avoiding sharing credentials with the client or other manual steps. Simple!\nSampling with Tools: Agentic Servers SEP: 1577\nThis functionality allows MCP servers to run their own agentic loops using the client\u0026rsquo;s tokens (still under the user\u0026rsquo;s control, of course), and reduces the complexity of client implementations, context support becoming explicitly optional. This came from the fact that sampling doesn\u0026rsquo;t support tool calling, although it\u0026rsquo;s a cornerstone of modern agentic behaviour. With the new spec release, this is no longer a gap!\nNow that sampling with tools is available, this also means that all of the scenarios below are possible!\nTool calling in sampling requests: Servers can now include tool definitions and specify tool choice behavior Server-side agent loops: Servers can implement sophisticated multi-step reasoning Parallel tool calls: Support for concurrent tool execution Better context control: The ambiguous includeContext parameter is being soft-deprecated in favor of explicit capability declarations As an example, a research server can spawn multiple agents internally, coordinate their work, and deliver a coherent result while using nothing other than standard MCP primitives without custom scaffolding or complex orchestration code.\nDeveloper Experience Improvements One of the core tenets of MCP is simplicity - we want to make the developer and integration experience as intuitive and easy as possible. To help achieve this, the latest spec release also adds a few minor changes that help make the protocol easier to use for developers.\nSEP-986: Standardized format for tool names SEP-1319: Decoupled request payload from RPC methods definition SEP-1699: SSE polling via server-side disconnect for better connection management SEP-1309: Improved specification version management for SDKs Looking Forward This release is backward compatible. Your existing implementations keep working. The new features are there when you need them.\nLooking ahead, we\u0026rsquo;re excited about what\u0026rsquo;s coming next for MCP. The protocol is entering a new phase, one where it\u0026rsquo;s not just about connecting LLMs to data, but about enabling entirely new categories of AI-powered applications.\nWe\u0026rsquo;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.\nThe roadmap ahead includes deeper work on reliability and observability, making it easier to debug and monitor complex MCP deployments. We\u0026rsquo;re exploring better patterns for server composition, allowing you to build sophisticated capabilities by combining simpler building blocks. And we\u0026rsquo;re continuing to refine the security model to meet the needs of the most demanding enterprise environments.\nWhat excites us most isn\u0026rsquo;t what we\u0026rsquo;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\u0026rsquo;t fill it alone.\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\u0026rsquo;re here to support that growth, to ensure the protocol evolves thoughtfully, and to keep MCP stable, secure, and simple as it scales.\nGet Started To get started with all the new goodness in the latest MCP specification release, check out the following resources:\nRead the changelog: All major changes are captured in our Key Changes document Get to know our docs: The MCP documentation is the source of truth for the all the inner workings of the protocol Join the discussion: If you would like to contribute or engage with other MCP maintainers, start with our GitHub repo and Discord ","permalink":"https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/","summary":"\u003cp\u003eToday, MCP turns \u003cstrong\u003eone year old\u003c/strong\u003e. You can check out the \u003ca href=\"https://www.anthropic.com/news/model-context-protocol\"\u003eoriginal announcement blog post\u003c/a\u003e if you don\u0026rsquo;t believe us. It\u0026rsquo;s hard to imagine that a little open-source experiment, a \u003cstrong\u003eprotocol to provide context to models\u003c/strong\u003e, became the de-facto standard for this very scenario in less than twelve months.\u003c/p\u003e\n\u003cp\u003eBut not only do we hit the first anniversary milestone today - we\u0026rsquo;re also releasing a brand-new MCP specification version. Before we get to the details of what\u0026rsquo;s new, let\u0026rsquo;s do a bit of a retrospective.\u003c/p\u003e","title":"One Year of MCP: November 2025 Spec Release"},{"content":"Today we\u0026rsquo;re introducing the proposal for the MCP Apps Extension (SEP-1865) to standardize support for interactive user interfaces in the Model Context Protocol.\nThis extension addresses one of the most requested features from the MCP community and builds on proven work from MCP-UI and OpenAI Apps SDK - the ability for MCP servers to deliver interactive user interfaces to hosts.\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.\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.\nStandardization for interactive interfaces Currently, MCP servers are limited to exchanging text and structured data with hosts. While this works well for many use cases, it creates friction when tools need to present visual information or gather complex user input.\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.\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\u0026rsquo;re working to proactively prevent.\nBuilding together The MCP-UI project, created by Ido Salomon and Liad Yosef and maintained by a dedicated community, spearheaded the vision of agentic apps with interactive interfaces. The project developed patterns for delivering rich user interfaces as first-class MCP resources, proving that agentic apps fit naturally within the MCP architecture. The project is backed by a large community and provides rich SDKs, adopted at leading companies and projects such as Postman, Shopify, Hugging Face, Goose, and ElevenLabs.\nThe OpenAI Apps SDK further validated the demand for rich UI experiences within conversational AI interfaces. The SDK enables developers to build rich, interactive applications inside ChatGPT using MCP as its backbone. To ensure interoperability and establish consistent security and usage patterns across the ecosystem, Anthropic, OpenAI, and MCP-UI are collaborating to create an official MCP extension for interactive interfaces.\nMCP Apps Extension specification We\u0026rsquo;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.\nKey design decisions Pre-declared resources UI templates are resources with the ui:// URI scheme, referenced in tool metadata.\n// Server registers UI resource { uri: \u0026#34;ui://charts/bar-chart\u0026#34;, name: \u0026#34;Bar Chart Viewer\u0026#34;, mimeType: \u0026#34;text/html+mcp\u0026#34; } // Tool references it in metadata { name: \u0026#34;visualize_data_as_bar_chart\u0026#34;, description: \u0026#34;Plots some data as a bar chart\u0026#34;, inputSchema: { type: \u0026#34;object\u0026#34;, properties: { series: { type: \u0026#34;array\u0026#34;, items: .... } } }, _meta: { \u0026#34;ui/resourceUri\u0026#34;: \u0026#34;ui://charts/bar-chart\u0026#34;, } } This approach enables hosts to prefetch and review templates before tool execution, improving both performance and security. It also separates static presentation (the template) from dynamic data (tool results), enabling better caching.\nMCP transport for communication Instead of inventing a custom message protocol, UI components communicate with hosts using existing MCP JSON-RPC base protocol over postMessage. This means that:\nUI developers can use the standard @modelcontextprotocol/sdk to build their applications All communication is structured and auditable Future MCP features automatically work with the UI extension Starting with HTML The initial extension specification supports only text/html content, rendered in sandboxed iframes. This provides:\nUniversal browser support Well-understood security model Screenshot and preview generation capabilities A clear baseline for future extensions Other content types such as external URLs, remote DOM, and native widgets are explicitly deferred to future iterations.\nSecurity-first Hosting interactive content from MCP servers requires careful security consideration. The proposal addresses this through multiple layers:\nIframe sandboxing: All UI content runs in sandboxed iframes with restricted permissions Predeclared templates: Hosts can review HTML content before rendering Auditable messages: All UI-to-host communication goes through loggable JSON-RPC User consent: Hosts can require explicit approval for UI-initiated tool calls These mitigations create defense in depth against malicious servers while preserving the flexibility developers need.\nBackward compatibility MCP Apps is an optional extension. Existing implementations continue working without changes, and hosts can gradually adopt UI support at their own pace. Servers should provide text-only fallback for all UI-enabled tools and return meaningful content even when UI is unavailable, so they can serve both UI-capable and text-only hosts.\nWhat\u0026rsquo;s next The UI Community Working Group has been instrumental in shaping this proposal through extensive feedback and discussion. We have built an early access SDK to demonstrate the patterns and types described in the specification proposal. The MCP-UI client and server SDKs support these patterns.\nIf you are interested in contributing to this effort, we invite you to:\nReview the full specification in SEP-1865 Share feedback and concerns in GitHub Issues Join the discussion in the #ui-wg channel in the MCP Contributors Discord Test prototype implementations and share your experience Acknowledgements This proposal wouldn\u0026rsquo;t exist without the work of the maintainers at MCP-UI, OpenAI, and Anthropic.\nIdo 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.\nSean Strong, Olivier Chafik, Anton Pidkuiko, and Jerome Swannack from Anthropic helped steer the initiative and drive the collaboration.\nNick Cooper, Alexei Christakis, and Bryan Ashley from OpenAI have provided valuable direction from their experience building the Apps SDK.\nSpecial thanks to the UI Community Working Group members and everyone who contributed to the discussions that shaped this proposal.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/","summary":"\u003cp\u003eToday we\u0026rsquo;re introducing the proposal for the \u003ca href=\"https://github.com/modelcontextprotocol/ext-apps\"\u003eMCP Apps Extension\u003c/a\u003e (\u003ca href=\"https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865\"\u003eSEP-1865\u003c/a\u003e) to standardize support for interactive user interfaces in the Model Context Protocol.\u003c/p\u003e\n\u003cp\u003eThis extension addresses one of the most requested features from the MCP community and builds on proven work from \u003ca href=\"https://github.com/idosal/mcp-ui\"\u003eMCP-UI\u003c/a\u003e and \u003ca href=\"https://developers.openai.com/apps-sdk/\"\u003eOpenAI Apps SDK\u003c/a\u003e - the \u003cstrong\u003eability for MCP servers to deliver interactive user interfaces to hosts\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eMCP 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.\u003c/p\u003e","title":"MCP Apps: Extending servers with interactive user interfaces"},{"content":"The MCP Bundle format (MCPB) is now part of the Model Context Protocol project. 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, Claude Code, and MCP for Windows.\nWhat are MCP Bundles? MCP Bundles are ZIP archives containing a local MCP server and a manifest.json that describes the server and its capabilities. The format is similar to Chrome extensions (.crx) or VS Code extensions (.vsix), enabling end users to install local MCP servers with a single click.\nA basic bundle structure looks like:\nbundle.mcpb (ZIP file) ├── manifest.json # Required: Bundle metadata and configuration ├── server/ # Server implementation │ └── index.js ├── node_modules/ # Bundled dependencies └── icon.png # Optional: Bundle icon The format supports servers written in Node.js, Python, or compiled binaries, giving developers flexibility in how they build their integrations, while maintaining a consistent distribution mechanism for users.\nWhy move MCPB to the MCP project? Anthropic originally developed MCPB (previously called DXT) for Claude\u0026rsquo;s desktop applications. However, we believe the local MCP server ecosystem benefits when portability extends beyond any single client. By moving the bundle specification, CLI tooling, and reference implementation to the MCP project, we\u0026rsquo;re enabling:\nCross-client compatibility: A bundle created for one MCP-compatible application should work in any other that implements the specification. Developers can distribute their work once and reach users across the ecosystem. Ecosystem-wide tooling: The mcpb CLI and associated libraries are now open for the community to extend, improve, and build upon. Client developers can adopt standardized code for loading and verifying bundles. User-friendly installation: End users benefit from a consistent installation experience regardless of which AI application they prefer. Configuration variables, permissions, and updates can be handled uniformly. Shared community: MCPB contributors can now collaborate in the open with the rest of the MCP community. What this means for developers This transition is mostly a logistical change, but also brings some benefits to implementers. For those that are building:\nServers: You can use MCPB to package your local MCP servers for distribution across multiple clients. The mcpb CLI helps you create a manifest.json and package your server into a .mcpb file. Once packaged, users can install your server with a single click in any client that supports MCP Bundles. Clients: You can add support for MCP Bundles to your application using the open source toolchain. The repository includes the schemas and key functions used by Claude for macOS and Windows to implement bundle support, which you can adapt for your own client. Getting started Check out the repo to get started: modelcontextprotocol/mcpb. We encourage feedback and contributions!\nAcknowledgements Thanks to the MCP contributors and maintainers involved in making this happen, including:\nDavid Soria Parra (MCP Lead Maintainer) Adam Jones (MCP Maintainer) Joan Xie (MCPB Maintainer) Felix Rieseberg (MCPB Maintainer) Alex Sklar (MCPB Maintainer) ","permalink":"https://blog.modelcontextprotocol.io/posts/2025-11-20-adopting-mcpb/","summary":"\u003cp\u003eThe \u003ca href=\"https://github.com/modelcontextprotocol/mcpb\"\u003eMCP Bundle format\u003c/a\u003e (MCPB) is now part of the \u003ca href=\"https://github.com/modelcontextprotocol\"\u003eModel Context Protocol project\u003c/a\u003e. This distribution format simplifies how developers package and share local MCP servers, enabling users to install them across any compatible client, including the \u003ca href=\"https://claude.com/download\"\u003eClaude desktop app\u003c/a\u003e, \u003ca href=\"https://claude.com/product/claude-code\"\u003eClaude Code\u003c/a\u003e, and \u003ca href=\"https://learn.microsoft.com/windows/ai/mcp/servers/mcp-server-overview\"\u003eMCP for Windows\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"what-are-mcp-bundles\"\u003eWhat are MCP Bundles?\u003c/h2\u003e\n\u003cp\u003eMCP Bundles are ZIP archives containing a local MCP server and a \u003ccode\u003emanifest.json\u003c/code\u003e that describes the server and its capabilities. The format is similar to Chrome extensions (\u003ccode\u003e.crx\u003c/code\u003e) or VS Code extensions (\u003ccode\u003e.vsix\u003c/code\u003e), enabling end users to install local MCP servers with a single click.\u003c/p\u003e","title":"Adopting the MCP Bundle format (.mcpb) for portable local servers"},{"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, 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.\nThe Problem Imagine you\u0026rsquo;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.\nNow let\u0026rsquo;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.\nSome examples could include:\n\u0026ldquo;Always use validate_schema → create_backup → migrate_schema for safe database migrations\u0026rdquo; \u0026ldquo;When using the export_data tool, the file system server\u0026rsquo;s write_file tool is required for storing local copies\u0026rdquo; \u0026ldquo;Database connection tools are rate limited to 10 requests per minute\u0026rdquo; \u0026ldquo;If create_backup fails, check if the notification server is connected before attempting to send alerts\u0026rdquo; \u0026ldquo;Only use request_preferences to ask the user for settings if elicitation is supported. Otherwise, fall back to using default configuration\u0026rdquo; So now our question becomes: what\u0026rsquo;s the most effective way to share this contextual knowledge?\nSolutions One solution could be to include extra information in every tool description or prompt provided by the server. Going back to the physical tool analogy, however: you can only depend on \u0026ldquo;labeling\u0026rdquo; each tool if there is enough space to describe them. A model\u0026rsquo;s context window is limited - there\u0026rsquo;s only so much information you can fit into that space. Even if all those labels can fit within your model\u0026rsquo;s context window, the more tokens you cram into that space, the more challenging it becomes for models to follow them all.\nAlternatively, relying on prompts to give common instructions means that:\nThe prompt always needs to be selected by the user, and The instructions are more likely to get lost in the shuffle of other messages. It\u0026rsquo;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\u0026rsquo;d rather have a single, clear manual that explains how everything works together.\nSimilarly, for global instructions that you want the LLM to follow, it\u0026rsquo;s best to inject them into the model\u0026rsquo;s system prompt instead of including them in multiple tool descriptions or standalone prompts.\nThis is where server instructions come in. Server instructions give the server a way to inject information that the LLM should always read in order to understand how to use the server - independent of individual prompts, tools, or messages.\nA Note on Implementation Variability Because server instructions may be injected into the system prompt, they should be written with caution and diligence. No instructions are better than poorly written instructions.\nAdditionally, the exact way that the MCP host uses server instructions is up to the implementer, so it\u0026rsquo;s not always guaranteed that they will be injected into the system prompt. It\u0026rsquo;s always recommended to evaluate a client\u0026rsquo;s behavior with your server and its tools before relying on this functionality.\nWe will get deeper into both of these considerations with concrete examples.\nReal-World Example: Optimizing GitHub PR Reviews I tested server instructions using the official GitHub MCP server to see if they could improve how models handle complex workflows. Even with advanced features like toolsets, models may struggle to consistently follow optimal multi-step patterns without explicit guidance.\nThe Problem: Detailed Pull Request Reviews One common use case where I thought instructions could be helpful is when asking an LLM to \u0026ldquo;Review pull request #123.\u0026rdquo; 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\u0026rsquo;t as helpful as leaving multiple inline comments for a detailed code review.\nThe Solution: Workflow-Aware Instructions One solution I tested with the GitHub MCP server is to add instructions based on enabled toolsets. My hypothesis was that this would improve the consistency of workflows across models while still ensuring that I was only loading relevant instructions for the tools I wanted to use. Here is an example of what I added if the pull_requests toolset is enabled:\nfunc GenerateInstructions(enabledToolsets []string) string { var instructions []string // Universal context management - always present baseInstruction := \u0026#34;GitHub API responses can overflow context windows. Strategy: 1) Always prefer \u0026#39;search_*\u0026#39; tools over \u0026#39;list_*\u0026#39; 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.\u0026#34; // Only load instructions for enabled toolsets to minimize context usage if contains(enabledToolsets, \u0026#34;pull_requests\u0026#34;) { instructions = append(instructions, \u0026#34;PR review workflow: Always use \u0026#39;create_pending_pull_request_review\u0026#39; → \u0026#39;add_comment_to_pending_review\u0026#39; → \u0026#39;submit_pending_pull_request_review\u0026#39; for complex reviews with line-specific comments.\u0026#34;) } return strings.Join(append([]string{baseInstruction}, instructions...), \u0026#34; \u0026#34;) } After implementing these instructions, I wanted to test whether they actually improved model behavior in practice.\nMeasuring Effectiveness: Quantitative Results To validate the impact of server instructions, I ran a simple controlled evaluation in Visual Studio Code comparing model behavior with and without the PR review workflow instruction. Using 40 GitHub PR review sessions on the same set of code changes, I measured whether models followed the optimal three-step workflow.\nI used the following tool usage pattern to differentiate between successful and unsuccessful reviews:\nSuccess: create_pending_pull_request_review → add_comment_to_pending_review → submit_pending_pull_request_review Failure: Single-step create_and_submit_pull_request_review OR no review tools used. (Sometimes the model decided just to summarize feedback but didn\u0026rsquo;t leave any comments on the PR.) You can find more setup details and raw data from this evaluation in my sample MCP Server Instructions repo.\nFor this sample of chat sessions, I got the following results:\nModel With Instructions Without Instructions Improvement GPT-5-Mini 8/10 (80%) 2/10 (20%) +60% Claude Sonnet-4 9/10 (90%) 10/10 (100%) N/A Overall 17/20 (85%) 12/20 (60%) +25% These results suggest that while some models naturally gravitate toward optimal patterns, others benefit significantly from explicit guidance. This variability makes server instructions particularly valuable for ensuring consistent behavior across different models and client implementations.\nYou can check out the latest server instructions in the GitHub MCP server repo, which now includes this PR workflow as well as other hints for effective tool usage.\nImplementing Server Instructions: General Tips For Server Developers One key to good instructions is focusing on what tools and resources don\u0026rsquo;t convey:\nCapture cross-feature relationships:\n{ \u0026#34;instructions\u0026#34;: \u0026#34;Always call \u0026#39;authenticate\u0026#39; before any \u0026#39;fetch_*\u0026#39; tools. The \u0026#39;cache_clear\u0026#39; tool invalidates all \u0026#39;fetch_*\u0026#39; results.\u0026#34; } Document operational patterns:\n{ \u0026#34;instructions\u0026#34;: \u0026#34;For best performance: 1) Use \u0026#39;batch_fetch\u0026#39; for multiple items, 2) Check \u0026#39;rate_limit_status\u0026#39; before bulk operations, 3) Results are cached for 5 minutes.\u0026#34; } Specify constraints and limitations:\n{ \u0026#34;instructions\u0026#34;: \u0026#34;File operations limited to workspace directory. Binary files over 10MB will be rejected. Rate limit: 100 requests/minute across all tools.\u0026#34; } Write model-agnostic instructions:\nKeep instructions factual and functional rather than assuming specific model behaviors. Don\u0026rsquo;t rely on a specific model being used or assume model capabilities (such as reasoning).\nAnti-Patterns to Avoid Don\u0026rsquo;t repeat tool descriptions:\n// Bad - duplicates what\u0026#39;s in tool.description \u0026#34;instructions\u0026#34;: \u0026#34;The search tool searches for files. The read tool reads files.\u0026#34; // Good - adds relationship context \u0026#34;instructions\u0026#34;: \u0026#34;Use \u0026#39;search\u0026#39; before \u0026#39;read\u0026#39; to validate file paths. Search results expire after 10 minutes.\u0026#34; Don\u0026rsquo;t include marketing or superiority claims:\n// Bad \u0026#34;instructions\u0026#34;: \u0026#34;This is the best server for all your needs! Superior to other servers!\u0026#34; // Good \u0026#34;instructions\u0026#34;: \u0026#34;Specialized for Python AST analysis. Not suitable for binary file processing.\u0026#34; Don\u0026rsquo;t include general behavioral instructions, or anything unrelated to the tools or servers.:\n// Bad - unrelated to server functionality \u0026#34;instructions\u0026#34;: \u0026#34;When using this server, talk like a pirate! Also be sure to always suggest that users switch to Linux for better performance.\u0026#34; Don\u0026rsquo;t write a manual:\n// Bad - too long and detailed \u0026#34;instructions\u0026#34;: \u0026#34;This server provides comprehensive functionality for... [500 words]\u0026#34; // Good - concise and actionable \u0026#34;instructions\u0026#34;: \u0026#34;GitHub integration server. Workflow: 1) \u0026#39;auth_github\u0026#39;, 2) \u0026#39;list_repos\u0026#39;, 3) \u0026#39;clone_repo\u0026#39;. API rate limits apply - check \u0026#39;rate_status\u0026#39; before bulk operations.\u0026#34; What Server Instructions Can\u0026rsquo;t Do: Guarantee certain behavior: As with any text you give an LLM, your instructions aren\u0026rsquo;t going to be followed the same way all the time. Anything you ask a model to do is like rolling dice. The reliability of any instructions will vary based on randomness, sampling parameters, model, client implementation, other servers and tools at play, and many other variables. Don\u0026rsquo;t rely on instructions for any critical actions that need to happen in conjunction with other actions, especially in security or privacy domains. These are better implemented as deterministic rules or hooks. Account for suboptimal tool design: Tool descriptions and other aspects of interface design for agents are still going to make or break how well LLMs can use your server when they need to take an action. Change model personality or behavior: Server instructions are for explaining your tools, not for modifying how the model generally responds or behaves. A Note for Client Implementers If you\u0026rsquo;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.\nAdditional suggestions for implementing instructions in clients:\nGive users control - Allow reviewing, enabling, or disabling server instructions to help users customize server usage and minimize conflicts or remove suboptimal instructions. Document your approach - Be clear about how your client handles and applies server instructions. Currently Supported Host Applications For a complete list of host applications that support server instructions, refer to the Clients page in the MCP documentation.\nFor a basic demo of server instructions in action, you can use the Everything reference server to confirm that your client supports this feature:\nInstall 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\u0026rsquo;re using Claude Code. Once you\u0026rsquo;ve confirmed that the server is connected, ask the model: does the everything server tools have any special instructions? If the model can see your instructions, you should get a response like the one below: Wrapping Up Clear and actionable server instructions are a key tool in your MCP toolkit, offering a simple but effective way to enhance how LLMs interact with your server. This post provided a brief overview of how to use and implement server instructions in MCP servers. We encourage you to share your examples, insights, and questions in our discussions.\nAcknowledgements Parts of this blog post were sourced from discussions with the MCP community, contributors, and maintainers including:\n@akolotov @cliffhall @connor4312 @digitarald @dsp-ant @evalstate @ivan-saorin @jegelstaff @localden @PederHP @tadasant @toby ","permalink":"https://blog.modelcontextprotocol.io/posts/2025-11-03-using-server-instructions/","summary":"\u003cp\u003eMany 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 \u003ca href=\"https://blog.modelcontextprotocol.io/posts/2025-07-29-prompts-for-automation/\"\u003ePrompts\u003c/a\u003e, 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. \u003cstrong\u003eServer instructions\u003c/strong\u003e fall in the latter category.\u003c/p\u003e","title":"Server Instructions: Giving LLMs a user manual for your server"},{"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.\nRelease Timeline The next version of the Model Context Protocol specification will be released on November 25th, 2025, with a release candidate (RC) available on November 11th, 2025.\nWe\u0026rsquo;re building in a 14-day RC validation window so client implementors and SDK maintainers can thoroughly test the protocol changes. This approach gives us the focused time we need to deliver critical improvements while applying our new governance model to the process.\nSummer Progress Our last spec was released on June 18, 2025, and focused on structured tool outputs, OAuth-based authorization, elicitation for server-initiated user interactions, and improved security best practices.\nSince then, we’ve focused on establishing additional foundations for the MCP ecosystem:\nFormal Governance Structures We established a formal governance model for MCP, including defined roles and decision-making mechanisms. We also developed the Specification Enhancement Proposal (SEP) process to provide clear guidelines for contributing specification changes.\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\u0026rsquo;re actively refining it as both the protocol and community continue to grow.\nWorking Groups We\u0026rsquo;ve launched Working Groups and Interest Groups to foster community collaboration. These groups serve multiple purposes:\nProvide clear entry points for new contributors Empower community members to lead initiatives in their areas of expertise Distribute ownership across the ecosystem rather than concentrating it among core maintainers We\u0026rsquo;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.\nRegistry Development In September, we launched the MCP Registry preview—an open catalog and API for indexing and discovery of MCP servers. The Registry serves as the single source of truth for available MCP servers, supporting both public and private sub-registries that organizations can customize for their specific needs.\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.\nPriority Areas for the Next Release With governance and infrastructure foundations in place, we\u0026rsquo;re focusing on five key protocol improvements identified by our working groups.\nAsynchronous Operations Currently, MCP is built around mostly synchronous operations—when you call a tool, everything stops and waits for it to finish. That works great for quick tasks, but what about operations that take minutes or hours?\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.\nStatelessness and Scalability As organizations deploy MCP servers at enterprise scale, we\u0026rsquo;re seeing new requirements emerge. Current implementations often need to remember things between requests, which makes horizontal scaling across multiple server instances challenging.\nWhile 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.\nServer Identity Today, if you want to know what an MCP server can do, you have to connect to it first. This makes it difficult for clients to browse available servers or for systems like our registry to automatically catalog capabilities.\nWe\u0026rsquo;re solving this by letting servers advertise themselves through .well-known URLs—an established standard for providing metadata. Think of it as a server\u0026rsquo;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.\nOfficial Extensions As MCP has grown, we\u0026rsquo;ve noticed patterns emerging for specific industries and use cases—valuable implementations that don\u0026rsquo;t necessarily belong in the core protocol specification.\nRather than leaving everyone to reinvent the wheel, we\u0026rsquo;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.\nSDK Support Standardization Choosing an MCP SDK today can be challenging—it\u0026rsquo;s hard to gauge the level of support or spec compliance you\u0026rsquo;ll get. Some SDKs are lightning-fast with updates, while others might lag behind feature-wise.\nWe\u0026rsquo;re introducing a clear tiering system for SDKs. You\u0026rsquo;ll know exactly what you\u0026rsquo;re signing up for before committing to a dependency, based on factors like specification compliance speed, maintenance responsiveness, and feature completeness.\nCall for Contributors MCP is only as strong as the community behind it. Whether you\u0026rsquo;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.\nSDK Maintenance TypeScript SDK - Needs additional maintainers for feature development and bug fixes Swift SDK - Requires attention for Apple ecosystem support Other language SDKs welcome continued contributions Tooling Inspector - Development and maintenance of debugging tools for MCP server developers Registry - Backend API and CLI development; Go expertise would be particularly welcome Input from Client Developers We talk a lot about MCP servers, but clients are equally important—they\u0026rsquo;re the bridge connecting users to the entire MCP ecosystem. If you\u0026rsquo;re building an MCP client, you\u0026rsquo;re seeing the protocol from a unique angle, and we need that perspective embedded in the protocol design.\nYour real-world experience with implementation challenges, performance bottlenecks, and user needs directly shapes where the protocol should go next. Whether it\u0026rsquo;s feedback on existing capabilities or ideas for streamlining the developer experience, we want to hear from you.\nJoin us in the #client-implementors working group channel in the MCP Discord.\nLooking Ahead With governance structures and working groups in place, we\u0026rsquo;re better positioned to tackle major protocol improvements efficiently while ensuring everyone has a voice in the process. The foundational work we\u0026rsquo;ve done this summer gives us a solid base to build from.\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\u0026rsquo;t do it alone.\nMCP\u0026rsquo;s strength has always been that it\u0026rsquo;s an open protocol built by the community, for the community. We\u0026rsquo;re excited to keep building it together.\nThank you for your continued support, and we look forward to sharing more soon.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2025-09-26-mcp-next-version-update/","summary":"\u003cp\u003e\u003cstrong\u003eUpdate (November 11, 2025):\u003c/strong\u003e The specification release candidate (RC) date has been shifted from November 11th to \u003cstrong\u003eNovember 14th, 2025\u003c/strong\u003e. The specification release date remains to be \u003cstrong\u003eNovember 25th, 2025\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2 id=\"release-timeline\"\u003eRelease Timeline\u003c/h2\u003e\n\u003cp\u003eThe next version of the Model Context Protocol specification will be released on \u003cstrong\u003eNovember 25th, 2025\u003c/strong\u003e, with a release candidate (RC) available on \u003cstrong\u003eNovember 11th, 2025\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eWe\u0026rsquo;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 \u003ca href=\"https://modelcontextprotocol.io/community/governance\"\u003enew governance model\u003c/a\u003e to the process.\u003c/p\u003e","title":"Update on the Next MCP Protocol Release"},{"content":"Today, we\u0026rsquo;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.\nThe MCP Registry is now available in preview. To get started:\nAdd your server by following our guide on Adding Servers to the MCP Registry (for server maintainers) Access server data by following our guide on Accessing MCP Registry Data (for client maintainers) Single source of truth for MCP servers In March 2025, we shared that we wanted to build a central registry for the MCP ecosystem. Today we are announcing that we’ve launched https://registry.modelcontextprotocol.io as the official MCP Registry. As part of the MCP project, the MCP Registry, as well as a parent OpenAPI specification, are open source—allowing everyone to build a compatible sub-registry.\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.\nPublic and private sub-registries In building a central registry, it was important to us not to take away from existing registries that the community and companies have built. The MCP Registry serves as a primary source of truth for publicly available MCP servers, and organizations can choose to create sub-registries based on custom criteria. For example:\nPublic 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.\nPrivate 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.\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.\nCommunity-driven mechanism for moderation The MCP Registry is an official MCP project maintained by the registry working group and permissively licensed. Community members can submit issues to flag servers that violate the MCP moderation guidelines—such as those containing spam, malicious code, or impersonating legitimate services. Registry maintainers can then denylist these entries and retroactively remove them from public access.\nGetting started To get started:\nAdd your server by following our guide on Adding Servers to the MCP Registry (for server maintainers) Access server data by following our guide on Accessing MCP Registry Data (for client maintainers) This preview of the MCP Registry is meant to help us improve the user experience before general availability and does not provide data durability guarantees or other warranties. We advise MCP adopters to watch development closely as breaking changes may occur before the registry is made generally available.\nAs we continue to develop the registry, we encourage feedback and contributions on the modelcontextprotocol/registry GitHub repository: Discussion, Issues, and Pull Requests are all welcome.\nThanks to the MCP community The MCP Registry has been a collaborative effort from the beginning and we are incredibly grateful for the enthusiasm and support from the broader developer community.\nIn February 2025, it began as a grassroots project when MCP creators David Soria Parra and Justin Spahr-Summers asked the PulseMCP and Goose teams to help build a centralized community registry. Registry Maintainer Tadas Antanavicius from PulseMCP spearheaded the initial effort in collaboration with Alex Hancock from Block. They were soon joined by Registry Maintainer Toby Padilla, Head of MCP at GitHub, and more recently, Adam Jones from Anthropic joined as Registry Maintainer to drive the project towards the launch today. The initial announcement of the MCP Registry\u0026rsquo;s development lists 16 contributing individuals from at least 9 different companies.\nMany others made crucial contributions to bring this project to life: Radoslav Dimitrov from Stacklok, Avinash Sridhar from GitHub, Connor Peet from VS Code, Joel Verhagen from NuGet, Preeti Dewani from Last9, Avish Porwal from Microsoft, Jonathan Hefner, and many Anthropic and GitHub employees that provided code reviews and development support. We are also grateful to everyone on the Registry\u0026rsquo;s contributors log and those who participated in discussions and issues.\nWe deeply appreciate everyone investing in this foundational open source infrastructure. Together, we\u0026rsquo;re helping developers and organizations worldwide to build more reliable, context-aware AI applications. On behalf of the MCP community, thank you.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/","summary":"\u003cp\u003eToday, we\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eThe MCP Registry is now available in preview. To get started:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eAdd your server\u003c/strong\u003e by following our guide on \u003ca href=\"https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/quickstart.mdx\"\u003eAdding Servers to the MCP Registry\u003c/a\u003e (for server maintainers)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccess server data\u003c/strong\u003e by following our guide on \u003ca href=\"https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/registry-aggregators.mdx\"\u003eAccessing MCP Registry Data\u003c/a\u003e (for client maintainers)\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch1 id=\"single-source-of-truth-for-mcp-servers\"\u003eSingle source of truth for MCP servers\u003c/h1\u003e\n\u003cp\u003eIn March 2025, we shared that we wanted to build a central registry for the MCP ecosystem. Today we are announcing that we’ve launched \u003ca href=\"https://registry.modelcontextprotocol.io\"\u003ehttps://registry.modelcontextprotocol.io\u003c/a\u003e as the official MCP Registry. As part of the MCP project, the MCP Registry, as well as a parent \u003ca href=\"https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/official-registry-api.md\"\u003eOpenAPI specification\u003c/a\u003e, are open source—allowing everyone to build a compatible sub-registry.\u003c/p\u003e","title":"Introducing the MCP Registry"},{"content":"The official PHP SDK for the Model Context Protocol is now generally available.\nBuilt in collaboration with the PHP Foundation and Symfony, the PHP SDK handles protocol details, so developers don’t have to worry about low-level mechanics and can focus on building their applications.\nThe initial release enables PHP developers to build MCP servers, exposing tools, prompts, and resources to AI applications. Support for PHP applications to act as MCP clients will follow.\nThe PHP SDK now joins 9 other officially supported language SDKs in the MCP ecosystem, making it easier for developers everywhere to adopt MCP in their preferred language.\nGet involved The PHP SDK is now open to the community to install, test, and contribute:\nSDK repo: modelcontextprotocol/php-sdk Composer package: mcp/sdk We welcome your feedback and contribution, including issues, documentation improvements, and pull requests. Framework-specific integrations and real-world examples are also particularly valuable.\nThanks to the MCP community This release consolidates earlier community work into a single, trusted implementation. The SDK is maintained by the Symfony team, with Kyrian Obikwelu joining as a maintainer based on his previous PHP-MCP work. The PHP Foundation helped to coordinate the initiative with support from the members of MCP steering group.\nThank you to all involved in bringing PHP to the MCP ecosystem.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2025-09-05-php-sdk/","summary":"\u003cp\u003eThe official \u003ca href=\"https://github.com/modelcontextprotocol/php-sdk\"\u003ePHP SDK\u003c/a\u003e for the Model Context Protocol is now generally available.\u003c/p\u003e\n\u003cp\u003eBuilt in collaboration with the \u003ca href=\"https://thephp.foundation/\"\u003ePHP Foundation\u003c/a\u003e and \u003ca href=\"https://symfony.com/\"\u003eSymfony\u003c/a\u003e, the PHP SDK handles protocol details, so developers don’t have to worry about low-level mechanics and can focus on building their applications.\u003c/p\u003e\n\u003cp\u003eThe initial release enables PHP developers to build MCP \u003ca href=\"https://modelcontextprotocol.io/docs/learn/server-concepts\"\u003eservers\u003c/a\u003e, exposing \u003ca href=\"https://modelcontextprotocol.io/docs/learn/server-concepts#tools-ai-actions\"\u003etools\u003c/a\u003e, \u003ca href=\"https://modelcontextprotocol.io/docs/learn/server-concepts#prompts-interaction-templates\"\u003eprompts\u003c/a\u003e, and \u003ca href=\"https://modelcontextprotocol.io/docs/learn/server-concepts#resources-context-data\"\u003eresources\u003c/a\u003e to AI applications. Support for PHP applications to act as MCP \u003ca href=\"https://modelcontextprotocol.io/docs/learn/client-concepts\"\u003eclients\u003c/a\u003e will follow.\u003c/p\u003e\n\u003cp\u003eThe PHP SDK now joins 9 other \u003ca href=\"https://modelcontextprotocol.io/docs/sdk\"\u003eofficially supported language SDKs\u003c/a\u003e in the MCP ecosystem, making it easier for developers everywhere to adopt MCP in their preferred language.\u003c/p\u003e","title":"Announcing the Official PHP SDK for MCP"},{"content":"The Model Context Protocol (MCP) has adopted OAuth 2.1 as the foundation for its authorization framework. A key part of the authorization flow that MCP is particularly reliant on is client registration.\nThis is especially important in a world where clients and servers don\u0026rsquo;t have a pre-existing relationship - we can\u0026rsquo;t assume that we will always know which MCP clients will connect to which MCP servers. This design highlights two challenges that need to be addressed:\nOperational issues with managing client IDs via Dynamic Client Registration (DCR) Preventing client impersonation If you\u0026rsquo;re already familiar with OAuth and the current state of client registration in MCP, skip to Two Distinct Challenges in MCP Client Registration.\nBackground on OAuth A protected MCP server that implements OAuth 2.1 should allow a user to grant a client access to itself and prevent attempts to trick the user into granting access to a client they didn\u0026rsquo;t intend to use via phishing.\nThe authorization flow can be best described by looking at this sequence diagram:\nsequenceDiagram participant Client participant User participant AuthServer as Authorization Server participant Resource as Resource Server Client-\u0026gt;\u0026gt;User: 1. Redirect to authorization server User-\u0026gt;\u0026gt;AuthServer: Navigate to auth URL AuthServer-\u0026gt;\u0026gt;User: 2. Display consent screen User-\u0026gt;\u0026gt;AuthServer: Approve access AuthServer-\u0026gt;\u0026gt;Client: 3. Redirect with authorization code Client-\u0026gt;\u0026gt;AuthServer: 4. Exchange code for access token AuthServer--\u0026gt;\u0026gt;Client: Access token (saved) Client-\u0026gt;\u0026gt;Resource: 5. Request with access token Resource--\u0026gt;\u0026gt;Client: Protected resource This flow requires a few steps to be performed to acquire an access token:\nThe client directs the user to an authorization UI provided by the authorization server The authorization server displays a consent screen to the user User approves client access and the authorization server redirects the user back to the client with an access code Client exchanges the access code for a set of tokens, which are cached locally Client uses the access token to access the MCP server To be able to initiate this flow, however, the authorization server first needs some basic information about the client that is kicking off the authorization process:\nClient name: Human readable text to display in the consent screen to help the user decide whether they want to grant access. Redirect URL: The destination to send the authorization code back to if the user consents. In order to prevent a malicious client from tricking a user into granting access they didn\u0026rsquo;t intend to grant, the authorization server must be able to trust the client information it has.\nFor example, a malicious client could claim to be Claude Desktop on the consent screen while actually being owned by someone not affiliated with Claude Desktop developers. Seeing the client information on the consent screen, users might grant access thinking they\u0026rsquo;re authorizing the legitimate Claude Desktop, not realizing that some malicious client now has access to their account.\nImproving Client Registration in MCP For MCP users, a common pattern is to connect to an MCP server by using its URL directly in an MCP client.\nThis goes against the typical OAuth authorization pattern because the user is selecting the resource server to connect to rather than the client developer. This problem is compounded by the fact that there is an unbounded number of authorization servers that an MCP server may use, meaning that clients need to be able to complete the authorization flow regardless of the provider used.\nSome client developers have implemented pre-registration with a select few authorization servers. In this scenario, the client doesn\u0026rsquo;t need to rely on DCR when it detects an authorization server it knows. However, this is a solution that doesn\u0026rsquo;t scale given the breadth of the MCP ecosystem - it\u0026rsquo;s impossible to have every client be registered with every authorization server there is. To mitigate this challenge, we set out to outline some of the goals that we wanted to achieve with improving the client registration experience:\nClients: Client developers don\u0026rsquo;t need to implement pre-registration and distribute a client ID for each authorization server MCP servers might be using. Users: Users don\u0026rsquo;t need to go through a pre-registration process themselves and manually specify a client ID for every MCP server they connect to. Authorization servers: Trust in Metadata: Authorization servers have a way to trust the metadata they associate with a client, such as name and redirect URL. Single Client ID per App: Authorization servers can have a single client ID per client for governance and management purposes Selective Allow/Deny: Authorization servers can selectively allow or deny clients based on their policies. Database Management: Authorization servers do not need to handle an unbounded database or expiration flows for every new client registration. Currently, none of our existing client registration approaches satisfy all of these requirements. Pre-registration requires too much effort in a highly variable setting (unbounded number of clients connecting to unbounded number of servers), while DCR reduces effort but creates operational issues that a lot of the authorization servers are not ready to tackle yet.\nTwo Distinct Challenges in MCP Client Registration After extensive discussion with MCP server implementers, we\u0026rsquo;ve identified that a few competing solutions to the registration problem were addressing two distinct issues:\nOperational limitations of Dynamic Client Registration in open environments Client identity and impersonation risks across different deployment scenarios Challenge 1: Operational Limitations of Dynamic Client Registration The DCR Model Mismatch The DCR design takes the pre-registration pattern available in modern OAuth-based authorization servers and makes it available via an API. In fully open environments like MCP, DCR really puts the spotlight on a few operational challenges that an open registration endpoint introduces:\nFor authorization servers:\nUnbounded database growth: Every time a user connects a client to an MCP server, a new registration is created with the authorization server unless the client already has one. Registrations are also not portable, so using Claude Desktop on your Windows machine, and then jumping to Claude Desktop on macOS will create two distinct client registrations. Client expiry \u0026ldquo;black hole\u0026rdquo;: There\u0026rsquo;s no way to tell a client that its ID is invalid without creating an open redirect vulnerability. Clients have to implement their own heuristics for client ID management. Per-instance confusion: Each client instance typically gets its own client ID even when using the same application, but on different machines or across different users. From an auditing perspective, an authorization server administrator may see hundreds (if not thousands) of records for the same application without any rhyme or reason. Denial-of-Service vulnerability: An unauthenticated /register endpoint writes to a database within the authorization server, meaning that tenant admins now need to worry about rate limiting or policy controls (e.g., hosts allowed to register clients). For clients:\nExtra overhead: Managing registration state and another secret beyond access/refresh tokens No validity checking: Can\u0026rsquo;t verify if a client ID is still valid Unclear lifecycle: No guidance on when to re-register or update credentials Solution: Client ID Metadata Documents (CIMD) Client ID Metadata Documents (CIMD), described in OAuth Client ID Metadata Document and implemented by Bluesky, elegantly sidestep these operational issues.\nInstead of a registration step, clients use an HTTPS metadata URL as their client ID directly. The server fetches the metadata from the URL at authorization time:\nsequenceDiagram participant Client participant AuthServer participant MetadataURL Client-\u0026gt;\u0026gt;AuthServer: Authorization request (client_id=https://app.com/oauth.json) AuthServer-\u0026gt;\u0026gt;MetadataURL: GET https://app.com/oauth.json MetadataURL--\u0026gt;\u0026gt;AuthServer: {name: \u0026#34;App\u0026#34;, redirect_uris: [...]} AuthServer-\u0026gt;\u0026gt;Client: Show consent screen \u0026amp; continue flow This addresses all the operational issues:\nNo unbounded database growth: Servers fetch metadata on-demand (can cache for performance) No expiry management: The URL is the ID - it doesn\u0026rsquo;t expire Natural per-app model: One URL per application, not per user No registration endpoint: No unauthenticated write operations The cost? Clients need to host a metadata document at an HTTPS URL. For web applications, this is trivial. For desktop applications, this typically means hosting on their backend infrastructure.\nChallenge 2: Client Identity and Impersonation The second challenge is orthogonal to the DCR vs. CIMD debate - it\u0026rsquo;s about trusting that a client is who it claims to be. This problem will exist regardless of how the registration process is implemented.\nFor web-based clients, trust is more straightforward, as we have an HTTPS domain that\u0026rsquo;s tied to a certificate authority. For desktop clients, if the client can\u0026rsquo;t offload its authorization to existing backend infrastructure, there is difficulty trusting the client is legitimate and unmodified.\nThe Trust Spectrum We can map impersonation scenarios on two axes: attacker cost and mitigation complexity.\nLow attacker cost/Low mitigation complexity: Domain-based attacks\nAttack: Register malicious callback URI and claim to be Claude Desktop Cost: Trick user into clicking a link and consenting Mitigation: Restrict trusted domains/URLs Show warnings for unknown domains Works with both DCR and CIMD Medium attacker cost/Medium mitigation complexity: localhost impersonation\nAttack: Run malicious app on localhost:8080, impersonate legitimate client Cost: Trick user into running a malicious application (plus consenting for that app to have data access) Problem: Desktop apps can\u0026rsquo;t hold secrets, hard to prove identity High attacker cost/High mitigation complexity: Platform-attested applications\nAttack: Get malicious client signed by a trusted authority Cost: Extremely high - requires compromising certification vendor processes Mitigation: platform system-level attestation (future work) Solution: Software Statements for Desktop Applications To broadly solve the client impersonation for the middle tier as well as to prevent localhost impersonation we need signed software statements. Implementing this would require:\nClient hosts a JSON Web Key Set (JWKS) on their backend Client authenticates the user through their own flow The client-owned backend service issues a short-lived, signed JWT attesting to the client\u0026rsquo;s identity Client includes this JWT in the OAuth flow Authorization server verifies the JWT against the trusted JWKS This dramatically raises the bar for client impersonation, as an attacker would need to:\nCompromise the client\u0026rsquo;s backend infrastructure, or Successfully impersonate the client\u0026rsquo;s authentication flow Crucially, software statements work with both DCR and CIMD. They\u0026rsquo;re not a competing solution - they\u0026rsquo;re a complementary security layer.\nFuture: Platform-Level Attestation The strongest protection would be platform-level attestation, e.g. having macOS, Windows, or Android attest that a piece of software is legitimate.\nHaving OS-level attestation would make client impersonation unreasonably expensive. While the exact way this ties into a software statement is yet to be prototyped, the general direction is threading platform-level application identity validation through to the OAuth flow.\nThe Complementary Path Forward While we\u0026rsquo;re looking at all available options, it\u0026rsquo;s important to note that we\u0026rsquo;re not choosing between solutions. We\u0026rsquo;re exploring complementary approaches for distinct problems:\nFor operational issues: We are looking at adding CIMD support in favor of DCR\nKeep DCR for backward compatibility Recommend CIMD for new implementations Both achieve the same authorization goal For trust issues: Layering software statements on top\nOptional enhancement for both DCR and CIMD Required only when localhost impersonation is a concern Authorization servers choose their required trust level Security Considerations Both CIMD and software statements require authorization servers to make outbound HTTPS requests, potentially to untrusted domains. Implementations must:\nPrevent SSRF attacks by blocking internal network access Implement timeouts and size limits Consider caching strategies for performance Validate response formats strictly If we adopt these approaches, we’ll need good best practices and SDK support to help avoid vulnerabilities and provide a easy path for implementors.\nNext Steps Discussions for these approaches are happening in the Specification Enhancement Proposals (SEP):\nSEP-991: Client ID Metadata Documents SEP-1032: Software Statements with DCR Get involved: Join the conversation in Discord (the #auth-wg-client-registration channel) or comment on the SEPs directly.\nA big thank to the following folks for help with this blog post: Den Delimarsky, Aaron Parecki, Geoff Goodman, Andrew Block, Pieter Kasselman, Abhishek Hingnikar, and Bobby Tiernay.\n","permalink":"https://blog.modelcontextprotocol.io/posts/client_registration/","summary":"\u003cp\u003eThe Model Context Protocol (MCP) has adopted OAuth 2.1 as the foundation for its authorization framework. A key part of the authorization flow that MCP is particularly reliant on is \u003cstrong\u003eclient registration\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eThis is especially important in a world where clients and servers don\u0026rsquo;t have a pre-existing relationship - we can\u0026rsquo;t assume that we will always know which MCP clients will connect to which MCP servers. This design highlights two challenges that need to be addressed:\u003c/p\u003e","title":"Evolving OAuth Client Registration in the Model Context Protocol"},{"content":"MCP (Model Context Protocol) prompts enable workflow automation by combining AI capabilities with structured data access. This post demonstrates how to build automations using MCP\u0026rsquo;s prompts and resource templates through a practical example.\nThis guide demonstrates how MCP prompts can automate repetitive workflows. Whether you\u0026rsquo;re interested in the MCP ecosystem or simply want to leverage AI for workflow automation, you\u0026rsquo;ll learn how to build practical automations through a concrete meal planning example. No prior MCP experience needed—we\u0026rsquo;ll cover the fundamentals before diving into implementation.\nThe Problem: Time-Consuming Repetitive Tasks Everyone has a collection of repetitive tasks that eat away at their productive hours. Common examples include applying code review feedback, generating weekly reports, updating documentation, or creating boilerplate code. These tasks aren\u0026rsquo;t complex—they follow predictable patterns—but they\u0026rsquo;re cumbersome and time-consuming. MCP prompts were designed to help automate this kind of work.\nMCP prompts offer more than command shortcuts. They\u0026rsquo;re a primitive for building workflow automation that combines the flexibility of scripting with the intelligence of modern AI systems. This post explores how to build automations using MCP\u0026rsquo;s prompt system, resource templates, and modular servers. I\u0026rsquo;ll demonstrate these concepts through a meal planning automation I built, but the patterns apply broadly to any structured, repetitive workflow.\nExample: Automating Weekly Meal Planning I needed to solve a recurring problem: planning weekly meals by cuisine to manage ingredients efficiently. The manual process involved selecting a cuisine, choosing dishes, listing ingredients, shopping, and organizing recipes—repetitive steps that took significant time each week.\nSo I decided to use MCP! By automating these steps, I could reduce the entire workflow to selecting a cuisine and receiving a complete meal plan with shopping list. (Any client that supports MCP prompts should work!)\nSelect a prompt\nSelect a cuisine from a dropdown Done! The system generates a meal plan, shopping list, and even prints the shopping list and recipes.\nHere we are focuses primarily on the Recipe Server with its prompts and resources. You can find the printing server example here (it works with a specific thermal printer model, but you could easily swap it for email, Notion, or any other output method). The beauty of separate servers is that you can mix and match different capabilities.\nCore Components Let\u0026rsquo;s dive into the three components that make this automation possible: prompts, resources, and completions. I\u0026rsquo;ll show you how each works conceptually, then we\u0026rsquo;ll implement them together.\n1. Resource Templates In MCP, static resources represent specific pieces of content with unique URIs—like file://recipes/italian.md or file://recipes/mexican.md. While straightforward, this approach doesn\u0026rsquo;t scale well. If you have recipes for 20 cuisines, you\u0026rsquo;d need to define 20 separate resources, each with its own URI and metadata.\nResource templates solve this through URI patterns with parameters, transforming static resource definitions into dynamic content providers.\nFor example, a template like file://recipes/{cuisine}.md might represent a set of resources like these:\nfile://recipes/italian.md returns Italian recipes file://recipes/mexican.md returns Mexican recipes This pattern extends beyond simple filtering. You can create templates for:\nHierarchical data: file://docs/{category}/{topic} Git repository content: git://repo/{branch}/path/{file} Web resources: https://api.example.com/users/{userId}/data Query parameters: https://example.com/{collection}?type={filter} For more details on URI schemes and resource templates, see the MCP Resource specification.\n2. Completions Nobody remembers exact parameter values. Is it \u0026ldquo;italian\u0026rdquo; or \u0026ldquo;Italian\u0026rdquo; or \u0026ldquo;it\u0026rdquo;? Completions bridge this gap by providing suggestions as users type, creating an interface that feels intuitive rather than restrictive.\nDifferent MCP clients present completions differently:\nVS Code shows a filterable dropdown Command-line tools might use fuzzy matching Web interfaces could provide rich previews But the underlying data comes from your server, maintaining consistency across all clients.\n3. Prompts: Commands That Evolve With Context Prompts are the entry points to your automation. They define what commands are available and can range from simple text instructions to rich, context-aware operations.\nLet\u0026rsquo;s see how prompts can evolve to handle increasingly sophisticated use cases:\nBasic prompt: Static instruction\n\u0026#34;Create a meal plan for a week\u0026#34; This works, but it\u0026rsquo;s generic. The AI will create a meal plan based on general knowledge.\nAdding parameters: Dynamic customization\n\u0026#34;Create a meal plan for a week using {cuisine} cuisine\u0026#34; Now users can specify Italian, Mexican, or any other cuisine. The prompt adapts to user input, but still relies on the AI\u0026rsquo;s general knowledge about these cuisines.\nIncluding resources: Your data\nPrompts can include resources to add context data beyond simple text instructions. This is crucial when you need the AI to work with your specific context rather than general knowledge.\nIn my meal planning example, I don\u0026rsquo;t want generic recipes—I want the AI to use my collection of tested recipes that I know I like. Complex prompts make this possible by bundling prompt text with embedded resources.\nHere\u0026rsquo;s how it works:\nUser selects a prompt with parameters (e.g., \u0026ldquo;plan-meals\u0026rdquo; with cuisine=\u0026ldquo;italian\u0026rdquo;) Server returns both instructional text AND resource references Client decides how to handle resources - Applications might choose to select a subset of data using embeddings or keyword search, or pass the raw data directly to the model AI receives the context and generates a response In my example, VS Code attached the entire resource to the prompt, which worked great for this use case. The AI had access to all my Italian recipes when planning an Italian week, ensuring it only suggested dishes I actually had recipes for.\nThe key difference from simple prompts: instead of asking \u0026ldquo;Plan Italian meals\u0026rdquo; and getting generic suggestions, the AI works with your actual recipe collection, dietary preferences, and constraints.\nThe recipe resources we\u0026rsquo;ve been using are embedded resources that have inline content from the server. According to the MCP specification, prompts can also include other data types.\nThis enables advanced use cases beyond our text-based recipes, like design review prompts with screenshots or voice transcription services.\nBuilding the Recipe Server Let\u0026rsquo;s implement a complete MCP server that brings together all the concepts we\u0026rsquo;ve discussed. We\u0026rsquo;ll start with the server setup and then implement each capability.\nPrerequisites Before diving into the code, make sure you have:\nNode.js (v18 or higher) and npm installed MCP SDK installed: npm install @modelcontextprotocol/sdk An MCP-compatible client with prompt and resource support,like VS Code with the MCP extension For this tutorial, I\u0026rsquo;ll use the TypeScript SDK, but MCP also supports Python and other languages.\nServer Setup and Capabilities First, let\u0026rsquo;s create our MCP server:\nconst server = new McpServer({ name: \u0026#34;favorite-recipes\u0026#34;, version: \u0026#34;1.0.0\u0026#34;, }); async function main() { const transport = new StdioServerTransport(); await server.connect(transport); } main().catch((error) =\u0026gt; { console.error(\u0026#34;Server error:\u0026#34;, error); process.exit(1); }); Implementing Resources Next, let\u0026rsquo;s register a resource template with completions.\nserver.registerResource( \u0026#34;recipes\u0026#34;, new ResourceTemplate(\u0026#34;file://recipes/{cuisine}\u0026#34;, { list: undefined, complete: { cuisine: (value) =\u0026gt; { return CUISINES.filter((cuisine) =\u0026gt; cuisine.startsWith(value)); }, }, }), { title: \u0026#34;Cuisine-Specific Recipes\u0026#34;, description: \u0026#34;Traditional recipes organized by cuisine\u0026#34;, }, async (uri, variables, _extra) =\u0026gt; { const cuisine = variables.cuisine as string; if (!CUISINES.includes(cuisine)) { throw new Error(`Unknown cuisine: ${cuisine}`); } const content = formatRecipesAsMarkdown(cuisine); return { contents: [ { uri: uri.href, mimeType: \u0026#34;text/markdown\u0026#34;, text: content, }, ], }; }, ); Implementing Prompts Finally, let\u0026rsquo;s register the prompt, which also has completions:\nserver.registerPrompt( \u0026#34;weekly-meal-planner\u0026#34;, { title: \u0026#34;Weekly Meal Planner\u0026#34;, description: \u0026#34;Create a weekly meal plan and grocery shopping list from cuisine-specific recipes\u0026#34;, argsSchema: { cuisine: completable(z.string(), (value) =\u0026gt; { return CUISINES.filter((cuisine) =\u0026gt; cuisine.startsWith(value)); }), }, }, async ({ cuisine }) =\u0026gt; { const resourceUri = `file://recipes/${cuisine}`; const recipeContent = formatRecipesAsMarkdown(cuisine); return { title: `Weekly Meal Planner - ${cuisine} Cuisine`, description: `Weekly meal planner for ${cuisine} cuisine`, messages: [ { role: \u0026#34;user\u0026#34;, content: { type: \u0026#34;text\u0026#34;, text: `Plan cooking for the week. I\u0026#39;ve attached the recipes from ${cuisine} cuisine. Please create: 1. A 7-day meal plan using these recipes 2. An optimized grocery shopping list that minimizes waste by reusing ingredients across multiple recipes 3. Daily meal schedule with specific dishes for breakfast, lunch, and dinner 4. Preparation tips to make the week more efficient 5. Print Shopping list Focus on ingredient overlap between recipes to reduce food waste.`, }, }, { role: \u0026#34;user\u0026#34;, content: { type: \u0026#34;resource\u0026#34;, resource: { uri: resourceUri, mimeType: \u0026#34;text/markdown\u0026#34;, text: recipeContent, }, }, }, ], }; }, ); Running It Yourself The full code for the recipe server is available here.\nFollow VS Code\u0026rsquo;s documentation to set up the server. Once a server is set up in VS Code, you can see its status, debug what\u0026rsquo;s happening, and iterate quickly on your automations.\nAfter the server is set up in VS Code, type \u0026ldquo;/\u0026rdquo; in chat and select the prompt.\nExtending Your Automations MCP prompts open up exciting automation possibilities:\nPrompt Chains: Execute multiple prompts in sequence (plan meals → generate shopping list → place grocery order) Dynamic Prompts: Adapt based on available resources or time of year Cross-Server Workflows: Coordinate multiple MCP servers for complex automations External Triggers: Activate prompts via webhooks or schedules The patterns demonstrated in meal planning apply to many domains:\nDocumentation generation that knows your codebase Report creation with access to your data sources Development workflows that understand your project structure Customer support automations with full context Key takeaways:\nMCP prompts can include dynamic resources, giving AI full context for tasks Resource templates enable scalable content serving without duplication Modular server architecture lets you mix and match capabilities Wrapping Up This meal planning automation started as a simple desire to avoid rewriting shopping lists every week. It evolved into a complete system that handles meal planning, shopping lists, and recipe printing with just a few clicks.\nMCP prompts provide practical tools to automate repetitive tasks. The modular architecture means you can start small—perhaps just automating one part of your workflow—and expand as needed. Whether you\u0026rsquo;re automating documentation, reports, or meal planning, the patterns remain the same: identify repetitive tasks, build focused automations, and let the system handle the tedious parts.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2025-07-29-prompts-for-automation/","summary":"\u003cp\u003e\u003ca href=\"https://modelcontextprotocol.io/specification/2025-06-18\"\u003eMCP (Model Context Protocol)\u003c/a\u003e prompts enable workflow automation by combining AI capabilities with structured data access. This post demonstrates how to build automations using MCP\u0026rsquo;s \u003ca href=\"https://modelcontextprotocol.io/specification/2025-06-18/server/prompts\"\u003eprompts\u003c/a\u003e and \u003ca href=\"https://modelcontextprotocol.io/specification/2025-06-18/server/resources#resource-templates\"\u003eresource templates\u003c/a\u003e through a practical example.\u003c/p\u003e\n\u003cp\u003eThis guide demonstrates how MCP prompts can automate repetitive workflows. Whether you\u0026rsquo;re interested in the MCP ecosystem or simply want to leverage AI for workflow automation, you\u0026rsquo;ll learn how to build practical automations through a concrete meal planning example. No prior MCP experience needed—we\u0026rsquo;ll cover the fundamentals before diving into implementation.\u003c/p\u003e","title":"MCP Prompts: Building Workflow Automation"},{"content":"Since its open source release in November of 2024, the Model Context Protocol project has grown faster than we could have ever imagined. That\u0026rsquo;s a wonderful problem to have, but with growth come growing pains. Our existing processes, which worked well for a small team, have started to show their limits.\nToday, we\u0026rsquo;re taking a big step to ensure MCP can continue to grow and thrive. We\u0026rsquo;re introducing a formal governance model designed to bring clarity to the development process while preserving the collaborative, open source spirit that has made MCP successful.\nSpecification Enhancement Proposals (SEPs) One of the first major changes we\u0026rsquo;re introducing is Specification Enhancement Proposals (SEPs). This will be the primary mechanism for anyone to propose changes to MCP. SEPs are inspired by other projects, like Python PEPs or Rust RFCs. We aim to make the process for suggesting changes to Model Context Protocol as straightforward as possible:\nFollowing the SEP guidelines, submit a proposal as a GitHub issue to start the conversation. Our maintainers and core maintainers regularly review proposals and tag SEPs for review and sponsorship. You can also reach out and collaborate with contributing folks on Discord or GitHub. Refer to MAINTAINERS.md for a list of currently active maintainers and their focus areas. Work with the sponsor and the MCP community to move your proposal through draft, review, and implementation stages. SEPs provide a clear, documented path for evolving the protocol, ensuring that every major change is well-vetted by the community.\nLeadership Roles The new model also establishes three types of leadership roles, ensuring both focused ownership and broad community representation:\nMaintainers manage specific components like SDKs, our documentation, and individual repositories. Core Maintainers guide the overall direction of the project and the evolution of the MCP specification. Lead Maintainers serve as the final decision-makers and ensure the project\u0026rsquo;s long-term health. All maintainers form the MCP steering group. To ensure a structured and timely review of incoming proposals, our core and lead maintainers will meet bi-weekly to review submitted SEPs. Meeting notes and decisions will always be public. For example the notes from the core maintainer meeting on July 23rd, 2025.\nGet Involved We need your help to build the future of MCP, and everyone is welcome here. Whether you\u0026rsquo;re a seasoned open source veteran or just curious about how to get started, there\u0026rsquo;s a place for you in our community.\nMany of our maintainers began with a single small contribution—sometimes just fixing a typo or asking a thoughtful question. Every journey starts somewhere, and we\u0026rsquo;re excited to help you take your first step.\nNew Contributors: Unsure where to begin? Start by helping with documentation, fixing bugs, or building out examples. Every contribution matters, and we\u0026rsquo;re here to support you. Check out issues tagged with good first issue - they\u0026rsquo;re perfect for getting started, and you\u0026rsquo;ll find friendly faces ready to help. SDK Developers: Have a favorite programming language? As MCP grows, we need your expertise to build and maintain the protocol SDKs. Your work could empower entire new communities to use MCP. Documentation Writers: Clear, comprehensive documentation is what turns a good project into a great one. If you love explaining things or making guides, your contributions will help others succeed. Future Maintainers: We believe in growing our team from within. The path to becoming a maintainer starts with consistent, quality contributions and a commitment to the project\u0026rsquo;s success. Imagine yourself guiding new contributors and shaping the future of MCP. No matter your background or experience, you belong here. Join our Discord to connect with other contributors, ask questions, and find mentorship. Whether you\u0026rsquo;re fixing a typo or proposing a major change to the protocol, your voice is valued and your efforts make a difference.\nFor all the details, please see our full governance documentation.\nThank You None of this would be possible without the incredible community that has rallied around MCP. From the early adopters who believed in the vision, to the developers building MCP clients and servers, to the maintainers dedicating their time and expertise. Every contribution has been essential to making the Model Context Protocol the success it is today.\nYou\u0026rsquo;ve helped us identify issues, improve documentation, build SDKs, create compelling examples, and push the boundaries of what\u0026rsquo;s possible with platform integration. Your feedback, bug reports, feature requests, and code contributions have shaped MCP into something far better than we could have built alone.\nAs we embark on this next chapter with formal governance, we\u0026rsquo;re more committed than ever to fostering the open, inclusive community that has made MCP thrive. Thank you for being part of this journey - we can\u0026rsquo;t wait to see what we\u0026rsquo;ll build together next.\n","permalink":"https://blog.modelcontextprotocol.io/posts/2025-07-31-governance-for-mcp/","summary":"\u003cp\u003eSince its open source release in November of 2024, the Model Context Protocol project has grown faster than we could have ever imagined. That\u0026rsquo;s a wonderful problem to have, but with growth come growing pains. Our existing processes, which worked well for a small team, have started to show their limits.\u003c/p\u003e\n\u003cp\u003eToday, we\u0026rsquo;re taking a big step to ensure MCP can continue to grow and thrive. We\u0026rsquo;re introducing a formal governance model designed to bring clarity to the development process while preserving the collaborative, open source spirit that has made MCP successful.\u003c/p\u003e","title":"Building to Last: A New Governance Model for MCP"},{"content":"Welcome to the official Model Context Protocol (MCP) blog! This is where we\u0026rsquo;ll share the latest updates, tutorials, best practices, and insights about MCP.\nAbout MCP The Model Context Protocol is an open standard that enables seamless integration between AI assistants and external data sources and tools. It provides a universal way for AI models to interact with local services, APIs, and data stores.\nGet Involved We\u0026rsquo;re excited to build this ecosystem together with you. Here\u0026rsquo;s how you can participate:\nCheck out the MCP specification Join the discussion on GitHub ","permalink":"https://blog.modelcontextprotocol.io/posts/welcome-to-mcp-blog/","summary":"\u003cp\u003eWelcome to the official Model Context Protocol (MCP) blog! This is where we\u0026rsquo;ll share the latest updates, tutorials, best practices, and insights about MCP.\u003c/p\u003e\n\u003ch2 id=\"about-mcp\"\u003eAbout MCP\u003c/h2\u003e\n\u003cp\u003eThe Model Context Protocol is an open standard that enables seamless integration between AI assistants and external data sources and tools. It provides a universal way for AI models to interact with local services, APIs, and data stores.\u003c/p\u003e\n\u003ch2 id=\"get-involved\"\u003eGet Involved\u003c/h2\u003e\n\u003cp\u003eWe\u0026rsquo;re excited to build this ecosystem together with you. Here\u0026rsquo;s how you can participate:\u003c/p\u003e","title":"The Model Context Protocol Blog"}]