MCP Official Extensions Catalog - Identifiers, Stages, Destinations, and Client Support

First Published: 2026-11-10
Last Updated: 2026-11-10

Model Context Protocol (MCP) extensions are optional features that exist outside the core protocol. Extensions are identified by an identifier, are disabled by default, and become active only when both the client and server declare support for them. As of November 10, 2026, there are six official extensions. The stages of these extensions, and the destinations for Beta extensions, are defined in a table on the official MCP website's extensions page.

This article provides a comprehensive list of these six official extensions, detailing their identifiers, stages, destinations, repositories, specification locations, SEPs, and client support. Each row in the table includes a verification date. The stage table first appeared on the official page between October 26 and November 5, 2026, and the table on that page may keep changing.

There are some discrepancies between the official website and the GitHub repositories. This article does not definitively state which source is correct; instead, it presents information from both sources, along with their respective retrieval dates. This article aims to distinguish between information explicitly stated in the documentation, information that is not found in the documentation, and instances where the documentation itself contains conflicting information. This article does not include any testing results from real-world environments, nor does it describe how to use each extension.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. How an Extension Is Identified
4. Stages and Destinations
5. The Official Extensions
6. How Extensions Are Negotiated
7. Client Support
8. The Experimental Layer and SDKs
9. Where the Sources Disagree and What They Do Not Say
10. Failure Modes
11. Frequently Asked Questions About MCP Official Extensions
12. Summary
13. References

1. Scope and Assumptions

This chapter first defines the intended audience, the scope of this article, the consulted materials, and the terminology used. The following ten points outline the key conclusions.

As of November 10, 2026, there are six official extensions. These are categorized into stages: three (OAuth Client Credentials, Enterprise-Managed Authorization, and MCP Apps) are Stable, while three (MCP Tasks, Skills over MCP, and Server Cards) are in Beta (Chapter 5).
Extension identifiers follow the format {vendor-prefix}/{extension-name}. Official extensions use the prefix io.modelcontextprotocol. The overview page recommends that third-party extensions use a prefix that is the reverse of their own domain name (Chapter 3).
Extensions are disabled by default, regardless of their stage. If only one side supports an extension, the supporting side will either fall back to the core protocol's behavior or, if the extension is mandatory, reject the request (Sections 3.3 and 3.4).
The stages are Experimental, Beta, and Stable. From Beta, an extension may become Stable or be incorporated into the core specification through a Standards Track SEP. The extension identifier does not change when the stage changes (Chapter 4).
Beta extensions have a destination in the table. The destination for MCP Tasks is Core. The destinations for Skills over MCP and Server Cards are not specified in the table (Section 5.1).
From version 2026-07-28 onwards, clients declare extensions in the _meta section of each request, and servers declare them in the response to server/discover. In versions 2025-11-25 and earlier, extensions are declared in the initialize request and response, in the capabilities.extensions field, although this field is not included in the published schema (Chapter 6).
The client matrix on the official page is a community-maintained table and does not include a column for Server Cards. Blank cells are not statements that a client lacks support (Chapter 7).
Whether an SDK implements an extension is at the SDK's discretion. Implementing an extension is not required for protocol conformance (Section 8.2).
The overview page states that the directory structure of the specifications indicates the extension's stage. As of November 10, 2026, the actual directories match this principle in two out of five repositories (Section 9.1).
The term "Stable" has at least two other meanings besides the extension's stage. This article uses "Stable" exclusively to refer to the extension's stage (Section 1.4).

1.1 Intended Audience

This article is intended for the following readers:

Developers who are creating MCP servers or clients and need to determine which extensions to support.
Operations personnel who are evaluating different MCP clients and want to compare their extension compatibility.
Individuals reviewing the GitHub repositories to judge the stage of extensions.
Writers who are copying lists of official extensions from existing articles or internal documentation.

This article assumes that readers may be considering the following points, and each point will be verified with references from the documentation.

The stage of an extension can be determined by examining the directory names and README files in the repository.
If a breaking change occurs, the extension identifier changes.
Empty cells in the client matrix indicate that the client does not support that extension.
If the SEP is marked as "Final," the extension is Stable.
Extensions cannot be used on versions before 2026-07-28.

1.2 What This Article Covers and What It Does Not

This article covers the identifiers, stages, destinations, repositories, specification locations, and SEPs of the six official extensions, along with the stage rules, the identifier rules, being disabled by default, the forms of negotiation, the client matrix, the Experimental layer, SDK tiers, and discrepancies between sources.

This article does not cover:

A timeline of version changes and the date when MCP Apps was released as the first official extension. This is covered on this site's Model Context Protocol Specification Version Timeline.
Procedures for migrating from a server with sessions to version 2026-07-28, and the implications of Tasks being moved out of the core. This is covered on this site's Migrating to the Stateless Model Context Protocol.
Methods for client registration and authorization. This includes Client ID Metadata Documents, Dynamic Client Registration, and pre-registration, all covered on this site's Which MCP Clients a Remote MCP Server Lets In.
Specific details of MCP Tasks contracts, including polling rules, cancellation handling, and task status values.
Usage and implementation details for each extension.
The contents of each experimental extension.
Comparisons of clients or products, and pricing information.

The existing Migrating to the Stateless Model Context Protocol recommends not creating your own list of extensions and checking the official page instead. This article provides a copy of that official page, with a verification date included, presenting a list for reference. Before using this list, it is necessary to re-check the official pages.

1.3 Date of Review and Materials Reviewed

This article reviewed the following materials on November 10, 2026 (Japan Standard Time). Throughout the text, the English names in parentheses are used.

The Extensions Overview page on modelcontextprotocol.io (overview page)
The Extension Support Matrix page on the same site (client matrix)
Seven individual extension pages on the same site: the Authorization Extensions page (authorization extensions page), the OAuth Client Credentials page (OAuth Client Credentials page), the Enterprise-Managed Authorization page (Enterprise-Managed Authorization page), two MCP Apps pages (MCP Apps pages), the Tasks page (Tasks page), and the Skills page (Skills page).
Eight SEP pages on the same site: SEP-2133, SEP-3392, SEP-2127, SEP-2640, SEP-2663, SEP-1865, SEP-1046, and SEP-990.
The Key Changes page (changelog page) and the Versioning and Compatibility page (versioning page) from the specification, version 2026-07-28.
The SDKs page (SDK page) and the SDK Tiers page (SDK tiers page) on the same site.
README files and specification/ directories of the five ext- repositories in the modelcontextprotocol organization on GitHub (repository READMEs).
Six archived versions of the overview page from the Internet Archive's Wayback Machine (Wayback copies).
The charter page for the Server Card Working Group, and the README file for the Ruby SDK on GitHub (read to search for statements).

All materials were reviewed using the original content obtained via curl. The client matrix, which presents a table of supported features, was reviewed in its HTML format. This was necessary because the Markdown version of this page displayed empty cells for the checkmark symbols.

1.4 Terms, and Different Things with the Same Spelling

This article will consistently use the following terms:

Extension: Any functionality placed outside the core protocol and identified by an identifier. In this article, it refers only to MCP extensions.
Official Extension: An extension that the overview page says lives in an ext- repository in the MCP GitHub organization.
Stage: One of Experimental, Beta, or Stable. This term is used in the Extension Lifecycle section of the overview page.
Destination: The target state for a Beta extension. This can be either Stable or Core.
Core: The core MCP specification. When referring to "Core" as a destination for an extension, it means the extension is being incorporated into the core specification.
Settings Object: A value associated with an identifier in an extension's declaration. This term is used on the overview page.
Advertise: The process by which a client or server indicates to the other which extensions it supports.

The term "Stable" also has different meanings. The documentation reviewed for this article uses it in three ways:

Stable (as a stage of an extension): Refers to the stage listed in the table on the overview page. This article will only use "Stable" in this context.
Stable (as the state of a version in a repository README): The README files for ext-tasks and ext-apps describe the state of schema and specification versions with "Stable" and "Development." For example, the ext-tasks README lists version 2026-07-28 as "Stable," but the MCP Tasks extension itself is currently in the Beta stage.
Stable (as a published version): SEP-3392 refers to ext-skills placing files in the specification/stable/ directory, and in that context, "stable" refers to a published version.

The term "Final" when referring to the status of an SEP is also distinct from an extension's stage. "Final" indicates that the SEP proposal document has been accepted. SEP-2640 is "Final," but the Skills over MCP defined within it is currently in the Beta stage.

The word extension also has different things with the same spelling. Extensions for AWS Lambda, the extension layers of Claude Code, and browser extensions are not MCP extensions. This article will not address these.

2. How to Read the Tables

This chapter defines the terminology used in the tables in this article, specifically the terms for the state of the sources, and how this article writes verification dates and dates.

2.1 Terms for the State of the Sources

This article uses six terms to describe the state of the documentation. These terms, including their English spellings, will also be used in the tables.

Stated: The documentation contains a statement regarding the matter.
Stated as not supported: The documentation explicitly states that the matter is not supported or cannot be used.
Documentation does not list: While a list or table exists, the specific item is not included. This does not necessarily indicate that the matter is unsupported or unavailable.
No statement found: Despite searching using different search terms and examining different categories of documentation (as described in Section 1.3), no relevant statement could be found. This does not necessarily indicate that the matter is absent or does not occur.
Sources disagree: The documentation from two different sources provides conflicting statements regarding the same matter. This includes cases where the statements directly contradict each other, as well as cases where the scope, strength, or subject matter differs, and the text alone does not settle which one applies. This article presents both statements and their sources without designating either as incorrect.
Inference: This represents an inference made by this article, and is not a statement found in any of the documentation. This article says in the same sentence that it is an inference.

This article distinguishes between "Stated as not supported" and "No statement found." The former refers to a statement in the documentation, while the latter indicates that this article was unable to find a relevant statement.

2.2 How This Article Writes Verification Dates and Dates

The "Verification Date" column in the table in this article refers to the date on which the values in that row were verified against the source material. Dates are recorded in Japan Standard Time. The values in the table may change over time. In particular, the stages, destinations, specification locations, and client matrix are subject to change.

The dates and times for Wayback copies represent the times at which the Internet Archive captured those versions, and are recorded in UTC. This article uses the Wayback copy dates and times as evidence that the official page contained that specific content at that particular moment. Wayback copies do not indicate when the content changed between copies.

Versions of the MCP specifications are named using date-like formats, such as 2026-07-28. This article writes these specification versions as "version 2026-07-28" to distinguish them from calendar dates.

3. How an Extension Is Identified

This chapter describes the format for extension identifiers, explains that they are disabled by default, and outlines the behavior when only one side supports an extension.

3.1 Identifier Format

The overview page specifies that extensions are identified by identifiers. The format is {vendor-prefix}/{extension-name}, for example, io.modelcontextprotocol/oauth-client-credentials. The overview page also states that identifiers follow the same rules as the _meta key and that the prefix is mandatory.

Identifiers serve as keys when declaring extensions. Both clients and servers use these identifiers as keys to associate settings objects (see Chapter 6).

3.2 The Official Prefix and Third-Party Prefixes

Regarding official extension prefixes, the overview page states:

Official extensions use the io.modelcontextprotocol vendor prefix.

When third parties create extensions, the overview page recommends using a prefix that is the reverse of their domain name. For example, for a company that owns example.com, the prefix might be com.example/my-extension. The purpose of this is to avoid naming conflicts.

This article lists extensions only with the io.modelcontextprotocol prefix. Information on third-party extensions was not included in the materials consulted for this article.

3.3 Disabled by Default

The overview page, as noted in the SDK implementation section, states:

Extensions are always disabled by default and require explicit opt-in from the developer, at every stage.

The client matrix also states that extensions are always opt-in; a client will only use an extension if both the client and server have declared support for it in the extensions field. The Enterprise-Managed Authorization page similarly states that extensions are opt-in and are not enabled by default.

Being at the Stable stage does not mean that extensions are enabled by default. This point was verified across three pages.

3.4 When Only One Side Supports an Extension

The section on Graceful Degradation on the overview page describes the behavior when only one side supports an extension, as follows:

If one side supports an extension but the other doesn't, the supporting side needs to either fall back to core protocol behavior or reject the request with an appropriate error if the extension is mandatory.

The overview page provides two examples. Servers with tools that include a user interface should provide meaningful text even to clients that do not support UI extensions. Conversely, servers that require specific authentication extensions may choose to reject connections from clients that do not support them.

The overview page recommends documenting the expected fallback behavior in the extension.

4. Stages and Destinations

This chapter outlines the rules governing the stages of extensions, how these stages progress, how identifiers are handled when a stage changes, and the principles for storing specifications. Detailed information regarding these rules can be found in SEP-3392 (Extension Lifecycle), which is categorized as "Final" status, "Process" type, and was created on September 25, 2026.

4.1 Three Stages

The overview page states that all extensions exist within one of three stages, and may later be incorporated into the core specification. Each stage determines the permissible changes, the individuals responsible for approving those changes, and what implementers can expect. The table on the overview page is summarized below, using the terminology in this article.

Stage	Protocol Changes	Approving Authority	Entry Point	What Implementers Can Expect
Experimental	Any changes, at any time, without prior notice.	Extension Maintainer	Added by the Extension Maintainer	Nothing guaranteed. The design may change or be abandoned.
Beta	Any changes, although breaking changes are expected to be rare.	Extension Maintainer	Extensions Track SEP	Encourages real-world usage. Breaking changes will be documented.
Stable	Only in conjunction with a new version of the core protocol.	Extension Maintainer	Second Extensions Track SEP	Behavior is fixed within a specific protocol version.

The SEP-3392 table adds a row for "Core" to these three rows. In the "Core" row, the Core Maintainers approve changes, and the entry point is the Standards Track SEP.

4.2 How Stages Progress, and Destinations

The overview page states that extensions begin in the Experimental stage and must proceed through Beta. From Beta, extensions may become Stable or be incorporated into the core specification through a Standards Track SEP. Extensions that reach Stable may also be considered for inclusion in the core at a later date.

SEP-3392 details the potential outcomes for each stage as follows:

A Beta extension advances to Stable or Core, or is archived.

A Stable extension may be promoted to Core or deprecated.

According to SEP-3392, extensions in the Experimental or Beta stages move to specification/archived/ when the Extension Maintainer withdraws them. Core Maintainers can archive an Experimental or Beta extension that has had no merged change and no activity from Working Groups or Interest Groups for six months. Extensions that reach Stable may be deprecated through an Extensions Track SEP. While deprecated, they remain in specification/stable/ and are moved to specification/archived/ once they are removed.

Regarding the destination of Beta extensions, the overview page indicates that each Beta extension specifies either a Stable or Core destination. This destination may change during the Beta stage. SEP-3392 clarifies that the destination is a signal to implementers, not a guarantee, and that the SEP that moves the extension out of Beta decides the destination.

Figure 1 illustrates how the stages progress and the principles governing where each stage's specifications are located. As of November 10, 2026, the actual locations do not match these principles in some repositories (see Section 9.1).

4.3 The Identifier Does Not Change When the Stage Changes

The overview page describes the relationship between identifiers and stages as follows:

An extension's identifier does not change when its stage changes.

The overview page also states that identifiers remain unchanged even in the event of breaking changes. A new identifier is used only in the following case:

A new identifier (e.g., io.modelcontextprotocol/my-extension-v2) is used only when old and new behavior must coexist under one protocol revision.

When Beta extensions introduce breaking changes, the overview page recommends adding a revision string to the settings object, or increasing its value. This is to allow the other side to detect a mismatch.

This rule differs from the rule in SEP-2133. SEP-2133 (Extensions) states that breaking changes require the use of a new identifier. SEP-3392 clarifies that its own section regarding identifiers supersedes this rule from SEP-2133. This difference is a difference in when the two SEPs were written, and the text of SEP-3392 states it (Stated). This article will use the overview page and SEP-3392 as the current rules.

4.4 Where Specifications Are Placed, in Principle

The overview page states that official extensions are located in repositories in the MCP GitHub organization, identified by names that begin with ext-. A single repository can contain several related extensions at different stages. The directory in the repository indicates the extension's stage.

the directory that holds an extension's specification shows its stage: specification/experimental/, specification/beta/ or specification/stable/

Extensions that have been integrated into the core or have ended are moved to the specification/archived/ directory. SEP-3392 states that no repository is renamed when an extension's stage changes. Stage changes are implemented by moving the directory, and involve an Extension Maintainer opening a pull request, which a Core Maintainer then approves.

This section outlines principles. The actual locations for extensions are listed in the table in Chapter 5 and in Section 9.1.

4.5 Stable Revisions and Promotion to the Core

Stable extensions are released as revised versions aligned with the core protocol. An example location is specification/stable/<name>/2026-07-28/. The overview page states that published revisions cannot be changed. Modifications accumulate in the draft/ directory and only take effect when included in a new version of the core protocol. The behavior of the extension between a pair of peers is the behavior defined for the protocol version the two peers negotiate.

When a Standards Track SEP promotes an extension into the core in a protocol version, the overview page states that, for requests that declare that version or later, the functionality is core behavior, whether or not the extension is declared. For earlier versions, the extension's final revision continues to apply, so clients supporting those earlier versions should keep declaring the extension. Once that version is released, the extension's specification is moved to the specification/archived/ directory.

5. The Official Extensions

This chapter lists six official extensions, presenting them in a table along with notes for each extension. The stage column in the table is the overview page's stage field, verbatim.

5.1 The Catalog Table

Extension	Identifier	Overview Page Stage	Repository	Specification Location (Actual)	SEP	Verification Date
OAuth Client Credentials	`io.modelcontextprotocol/oauth-client-credentials`	`Stable`	`ext-auth`	`specification/stable/oauth-client-credentials/2026-07-28/`	No statement found	2026-11-10
Enterprise-Managed Authorization	`io.modelcontextprotocol/enterprise-managed-authorization`	`Stable`	`ext-auth`	`specification/stable/enterprise-managed-authorization/2026-07-28/`	SEP-990	2026-11-10
MCP Apps	`io.modelcontextprotocol/ui`	`Stable`	`ext-apps`	`specification/2026-01-26/` and `specification/draft/`	SEP-1865	2026-11-10
MCP Tasks	`io.modelcontextprotocol/tasks`	`Beta, to Core`	`ext-tasks`	`specification/2026-07-28/` and `specification/draft/`	SEP-2663	2026-11-10
Skills over MCP	`io.modelcontextprotocol/skills`	`Beta, destination not yet stated`	`ext-skills`	`specification/beta/skills.mdx`	SEP-2640	2026-11-10
Server Cards	No statement found	`Beta, destination not yet stated`	`ext-server-card`	No `specification/` directory	SEP-2127	2026-11-10

The following explains how to interpret this table.

Only Beta extensions have a destination in the table. Beta, to Core indicates a Beta stage with a destination of Core. Beta, destination not yet stated indicates a Beta stage where the destination has not yet been specified.
The overview page does not list destinations for the three Stable extensions. While Stable extensions may also be incorporated into the core later, the overview page does not list any planned incorporations for any of the three Stable extensions.
All repositories are located under the modelcontextprotocol organization on GitHub.
The "Specification Location (Actual)" column reflects what was observed on GitHub on November 10, 2026. The rows for MCP Apps, MCP Tasks, and Server Cards do not align with the principles outlined in Section 4.4 (Section 9.1).
The "SEP" column refers to the SEP that the extension page, the repository README, the link in the overview page table, or the changelog page for version 2026-07-28 references. The status of all five SEPs in the column is Final. The Final status of the SEP is independent of the extension stage (Section 1.4).
The identifier for Server Cards was not found in the documentation reviewed for this article (Section 5.7). This does not indicate that the identifier is absent.

5.2 OAuth Client Credentials

The OAuth Client Credentials page describes how this extension implements the OAuth 2.0 client credentials flow within MCP, allowing automated systems to connect to MCP servers without requiring user interaction or explicit permission.

The specification is located in the specification/stable/oauth-client-credentials/2026-07-28/ directory in the ext-auth repository. The draft/ directory is also located under the same directory as the extension. This approach aligns with the principles outlined in Section 4.4.

Neither the OAuth Client Credentials page nor the ext-auth README mentions a specific SEP for this extension (No statement found). SEP-1046, a related proposal, suggests adding the client credentials flow to MCP authorization. It is currently in the "Final" status, categorized as "Standards Track," and was created on July 23, 2025. However, the content of SEP-1046 does not mention either this extension's identifier or ext-auth. Therefore, this article does not designate SEP-1046 as the SEP for this extension; connecting the two would be an inference (Inference).

5.3 Enterprise-Managed Authorization

The Enterprise-Managed Authorization page describes how this extension allows organizations to manage access to the MCP servers through their existing identity provider (IdP) in a single location. Clients receive an ID-JAG (Identity Assertion JWT Authorization Grant) token from their corporate IdP and then exchange it for an access token on the MCP server's authorization server.

The Enterprise-Managed Authorization page notes that ID-JAG is defined in draft-ietf-oauth-identity-assertion-authz-grant by the IETF's OAuth Working Group. The positioning of the ID-JAG document is further discussed on this site in Where AI Agent Authorization Standards Stand.

The Enterprise-Managed Authorization page references SEP-990 as the original proposal. SEP-990 is marked as "Final," categorized as "Standards Track," and was created on June 4, 2025. The specification can be found at ext-auth's specification/stable/enterprise-managed-authorization/2026-07-28/.

5.4 MCP Apps

The overview page states that MCP Apps is an extension that lets MCP servers display interactive UI elements inline in conversations. The extension table on the client matrix lists the identifier as io.modelcontextprotocol/ui. The extension negotiation section of the versioning page also uses the same identifier as an example of MCP Apps. Note that the identifier's name differs from the extension's name.

The ext-apps README describes two versions of the specification. The version dated 2026-01-26 is designated as "Stable," while "draft" is labeled as "Development." This "Stable" refers to the state of the specification version, not the extension's stage (see Section 1.4). The location for the specifications is specification/2026-01-26/ and specification/draft/; there is no specification/stable/ directory.

The ext-apps README also references SEP-1865. SEP-1865 is marked as "Final," categorized as an "Extensions Track" extension, and was created on November 21, 2025. The date when MCP Apps was released as the first official extension is covered on this site's Model Context Protocol Specification Version Timeline.

5.5 MCP Tasks

The overview page describes MCP Tasks as asynchronous tasks designed for long-running operations, and gives its stage as Beta, to Core. Its destination is Core.

The changelog page, version 2026-07-28, states that the experimental tasks feature has been moved out of the core protocol and formalized as an extension with the identifier io.modelcontextprotocol/tasks. The changelog page references SEP-2663 in connection with this change. SEP-2663 is marked as Final, categorized under the Extensions Track, and was created on April 27, 2026. SEP-2663 identifies the extension's identifier as io.modelcontextprotocol/tasks.

The destination of a feature that moved out of the core is Core again. According to SEP-3392 (Section 4.2), the destination listed in the table on the overview page represents a signal, rather than a promise. This article does not specify the timing of this return to Core. No statement regarding this timing could be found in the available materials (No statement found).

The README for ext-tasks indicates that schema version 2026-07-28 is designated as Stable, while draft is marked as Development. This "Stable" refers to the schema version, while the extension itself is currently in the Beta stage (Section 1.4). The specifications are located at specification/2026-07-28/ and specification/draft/, but there is no specification/beta/ directory.

The specific details of the MCP Tasks contract, including polling rules, cancellation handling, and the values representing task states, are outside the scope of this article. The significance of Tasks moving out of the core, in the context of migration, is addressed on this site's Migrating to the Stateless Model Context Protocol.

5.6 Skills over MCP

The overview page describes "Skills over MCP" as an extension for discovering workflow instructions and reading supporting files through MCP resources, and indicates the stage as Beta, destination not yet stated.

The Skills page states that the ext-skills repository provides the published specification for the official Skills extension and assigns it the identifier io.modelcontextprotocol/skills. The Skills page also notes that SEP-2640 is Final. The status of SEP-2640 is listed as Final, its type is Extensions Track, and its creation date is April 23, 2026. Even though the SEP is Final, the extension remains in the Beta stage (see Section 1.4).

The README for ext-skills specifies that the specifications are located at specification/beta/skills.mdx and indicates that the extension is in the Beta stage. The location, the README, and the stage on the overview page all align.

The Skills page notes that SDK and host support is still being implemented. Vetting the contents of Agent Skills is covered in this site's Agent Skills Security Vetting Guide.

5.7 Server Cards

The overview page describes Server Cards as extensions that allow clients to discover server metadata before establishing a connection, with the stage indicated as Beta, destination not yet stated. Server Cards do not have a dedicated page. The link in the table on the overview page leads to the SEP-2127 page. SEP-2127 has a status of "Final," belongs to the "Extensions Track," and was created on January 21, 2026.

The identifier for Server Cards was not found on the overview page, on the SEP-2127 page, in the README for ext-server-card, in the schema.ts and schema.json files in the same repository, or on the page for the Server Card Working Group's charter (No statement found). The migration section of SEP-3392 states that classified extensions will retain their respective identifiers, but it does not specify the value of the Server Cards identifier.

SEP-2127 states that the initial format for Server Cards does not advertise MCP capabilities or extension support.

the initial Server Card format does not advertise MCP capabilities or extension support

Server Cards are static metadata documents retrieved via HTTP before connecting to a server. The README for ext-server-card recommends placing them at <streamable-http-url>/server-card.

The README for ext-server-card describes the repository itself as "Experimental." This does not match the "Beta" stage listed on the overview page (Sources disagree, Section 9.1). The ext-server-card repository does not contain a specification/ directory; instead, the specification's types are located in the schema.ts and schema.json files directly in the repository.

5.8 When the Official Page's Table Took Its Current Form

The table showing the number and stages of extensions on the overview page was updated in the fall of 2026. This article verified this using Wayback copies.

Wayback Copy Date & Time	Extensions Listed	Stage Table
2026-09-10 00:16 UTC	4: OAuth Client Credentials, Enterprise-Managed Authorization, MCP Apps, MCP Tasks	Not present
2026-10-11 13:58 UTC and 2026-10-22 02:00 UTC	5: The above 4, plus Skills over MCP	Not present
2026-10-26 09:31 UTC	5	Not present
2026-11-05 14:20 UTC and 2026-11-06 13:26 UTC	6: The above 5, plus Server Cards	Present

The stage table and the listing of the 6th extension appeared on the official page between the Wayback copies dated 2026-10-26 09:31 UTC and 2026-11-05 14:20 UTC. SEP-3392 was created on September 25, 2026.

A previously published document, Migrating to the Stateless Model Context Protocol, lists 4 extensions as official as of its verification date. The Wayback copy from September 10, 2026, also lists 4 extensions, so this discrepancy is a difference in timing.

6. How Extensions Are Negotiated

This chapter specifies where clients and servers declare extensions, according to each version of the protocol. The overview page states that clients and servers declare their support for extensions in the extensions field of their respective capabilities declarations. The location where extensions are declared differs between versions 2026-07-28 and later, and versions 2025-11-25 and earlier.

Figure 2 illustrates the locations where clients and servers declare extensions, for the two version ranges.

6.1 Clients on Version `2026-07-28` and Later

The overview page describes how clients should declare their support for extensions within each request, specifically by including _meta["io.modelcontextprotocol/clientCapabilities"]. The overview page's example shows how to place the protocol version and client capabilities in the _meta section of a tools/call request.

"_meta": {
  "io.modelcontextprotocol/protocolVersion": "2026-07-28",
  "io.modelcontextprotocol/clientCapabilities": {
    "extensions": {
      "io.modelcontextprotocol/ui": {
        "mimeTypes": ["text/html;profile=mcp-app"]
      }
    }
  }
}

The example above extracts only the client capabilities section from the _meta section shown in the overview page example. This declaration is not sent once during connection, but rather included with each request.

6.2 Servers on Version `2026-07-28` and Later

The overview page states that the server declares support for extensions in the response to server/discover.

"capabilities": {
  "tools": {},
  "extensions": {
    "io.modelcontextprotocol/ui": {}
  }
}

The example above extracts only the capabilities section from a sample response to server/discover on the overview page.

6.3 Version `2025-11-25` and Earlier

The overview page states that extensions became an official part of the protocol in version 2026-07-28. Even before that version, many SDKs, clients, and servers were negotiating extensions on version 2025-11-25 and earlier in the initialize handshake. The request uses params.capabilities.extensions, while the response uses result.capabilities.extensions. Identifiers and settings objects follow the same rules as described in Section 6.1.

The overview page includes the following note regarding this field:

The extensions field is not part of the published schemas for these protocol versions, and supporting it is not required for conformance.

The overview page recommends that SDKs capable of transmitting capabilities.extensions in the initialize process do so. If the other side's capabilities do not include extensions, or if they lack a specific extension, that extension should be treated as unsupported, and the behavior outlined in Section 3.4 should be followed.

The changelog page for version 2026-07-28 states that the ClientCapabilities and ServerCapabilities now include an extensions field. This entry on the changelog page does not reference a specific SEP number.

6.4 Settings Objects

The overview page and versioning page state that each extension defines the schema for its own settings object. An empty object indicates that no configuration is present.

Even if a side declares an identifier, the extension will not function as expected if the contents of its settings object do not align with the other side. The string value of the revision field for Beta extensions serves as a means for the other side to detect such discrepancies (see Section 4.3).

7. Client Support

This chapter copies the client matrix table, including the verification date.

7.1 What the Client Matrix Is

The client matrix is a table that indicates which MCP clients support which official extensions. The client matrix describes its characteristics as follows:

This list is maintained by the community.

The client matrix requests that individuals who identify errors or wish to add information submit a pull request.

Regarding the authorization extension columns in the client matrix, it states that support for authorization extensions is tracked separately from core authorization features such as Dynamic Client Registration (DCR) and Client ID Metadata Documents (CIMD). The client registration and authorization processes are outside the scope of this article (see Section 1.2).

7.2 The Support Table

The following table shows values read from the HTML version of the client matrix as of November 10, 2026. A checkmark (✓) indicates the presence of a checkmark symbol in the client matrix cell. "Partial" is the text in the client matrix cell. A blank cell indicates that the client matrix cell is empty.

Client	MCP Apps	OAuth Client Credentials	Enterprise Auth	Skills	Tasks
Claude (web)	✓				✓
Claude Desktop	✓
Claude Code					✓
VS Code GitHub Copilot	✓
Microsoft 365 Copilot	✓
Goose	✓
Postman	✓
MCPJam	✓			✓	✓
ChatGPT	✓			Partial
Cursor	✓
Archestra.AI	✓		✓
PostHog Code	✓
Kiro Crew	✓
fast-agent				Partial
MCP Inspector				Partial
mcpc MCP CLI		✓	✓	✓
Glean	✓		✓	✓	✓

The verification date for all rows in the table is 2026-11-10. The column names remain as they appear in the headings of the client matrix. The "Enterprise Auth" column refers to Enterprise-Managed Authorization, the "Skills" column refers to Skills over MCP, and the "Tasks" column refers to MCP Tasks.

The values presented in this table have not been verified against the documentation provided by each client's provider.

7.3 What the Table Does Not Tell You

The client matrix table does not reveal the following:

That a client with a blank cell does not support a particular extension. A blank cell means that the community table has no checkmark; it is not a statement that the client lacks support.
Support for Server Cards. The client matrix does not include a column for Server Cards (Documentation does not list).
Version or revision differences for extensions. The client matrix does not specify which versions of an extension are supported.
Relative advantages or disadvantages between clients. The table only copies the cells of the client matrix.

The extension table on the client matrix lists only four extensions by name and identifier: MCP Apps, OAuth Client Credentials, Enterprise-Managed Authorization, and Skills over MCP. It does not include rows for MCP Tasks or Server Cards (Documentation does not list). The identifier for MCP Tasks can be verified on the Tasks page and in SEP-2663 (see Section 5.5).

8. The Experimental Layer and SDKs

This chapter describes the Experimental layer outside the six official extensions, and clarifies the relationship between the SDK and the extensions.

8.1 The Experimental Layer

The overview page states that the Experimental extensions area serves as a space for Working Groups and Interest Groups to test proposals. Experimental extensions are either placed under the specification/experimental/ directory within existing ext- repositories, or in dedicated repositories that begin with experimental-ext-. Anything within a repository starting with experimental-ext- is considered Experimental.

As of November 10, 2026, a search for ext- in the MCP organization on GitHub revealed six repositories beginning with experimental-ext-:

experimental-ext-file-uploads
experimental-ext-filesystems
experimental-ext-interceptors
experimental-ext-tool-annotations
experimental-ext-triggers-events
experimental-ext-variants

This article does not cover the contents of these repositories. The overview page indicates that implementers should pin Experimental extensions to a tag or commit. This is because two revisions of Experimental extensions do not need to be compatible. The overview page also states that Core Maintainers can archive or remove Experimental extensions.

Finally, the overview page specifies that published packages for Experimental extensions must clearly indicate their Experimental status, for example, through the README file or package name.

8.2 SDK Tiers and Extensions

The overview page describes the relationship between the SDK and extensions as follows:

SDKs can choose to implement extensions, but it's not required for protocol conformance.

The overview page states that the maintainers of the SDK are free to decide which extensions it will support. If the SDK does support an extension, the SDK's documentation should list those supported extensions.

The SDK page, as of November 10, 2026, lists the SDKs categorized into three tiers.

Tier	SDK
Tier 1	TypeScript, Python, C#, Go, Rust, Ruby
Tier 2	Java
Tier 3	Swift, PHP, Kotlin

The SDK tiers page states that SDKs in Tier 1 implement all non-experimental features. Furthermore, it states:

Experimental features and protocol extensions (such as Tasks and MCP Apps) are not required for any tier.

Being an SDK in Tier 1 does not mean that it supports the official extensions. This article does not specify when the Ruby SDK was added to Tier 1. This is because no such date is found in the SDK page or the Ruby SDK's README (No statement found). What the TypeScript and Python SDKs require of server developers is covered on this site's What the MCP TypeScript and Python SDKs Ask of Server Authors.

9. Where the Sources Disagree and What They Do Not Say

This chapter gathers information regarding discrepancies between documents and information that is not documented.

9.1 Where the Sources Disagree

The principle for specification locations, and the actual repositories: The overview page states that the directory that holds a specification indicates its stage (Section 4.4). As of November 10, 2026, the current state of five repositories is as follows:

Repository	Overview Page Stage	Content Under `specification/`	Alignment with Principle
`ext-auth`	Stable	`stable/`	Aligned
`ext-skills`	Beta	`beta/`	Aligned
`ext-apps`	Stable	`2026-01-26/` and `draft/`	Not aligned
`ext-tasks`	Beta	`2026-07-28/` and `draft/`	Not aligned
`ext-server-card`	Beta	No `specification/` directory	Not aligned

The migration section of SEP-3392 describes the intended destination for each repository when the SEP reaches Final. ext-apps will move to specification/stable/, while ext-tasks and ext-server-card will move to specification/beta/. Date-stamped copies directly under specification/ and the draft/ directory will be moved under the extension's own directory. An example from SEP-3392 is specification/beta/tasks/2026-07-28/. Reading this as the three repositories not yet having made this move is an inference by this article (Inference).

If one were to judge the stage based solely on the repository directory structure, it would be impossible to determine the stage for three of the repositories. The stage should be verified using the table on the overview page.

Server Cards Stage: The overview page indicates that Server Cards are in the Beta stage. The migration table in SEP-3392 also classifies ext-server-card as Beta. The beginning of the README file for ext-server-card states:

Status: Experimental. This work is for prototyping and feedback only, and is not an accepted or official MCP extension.

The statements in these two sources do not match (Sources disagree). This article does not conclude that either source is incorrect.

This article observed two facts. The README for ext-server-card states that the SEP is still under review, while the status of SEP-2127 is marked as "Final." When accessed on November 10, 2026, github.com/modelcontextprotocol/experimental-ext-server-card redirects to ext-server-card. Both SEP-2127 and the Working Group's charter page refer to an older repository name. Reading the README as still containing wording from before the SEP was accepted is an inference by this article (Inference).

Identifier Rules: SEP-2133 states that breaking changes must use a new identifier. The text of SEP-2127 also references SEP-2133, stating that breaking changes require a new extension identifier. The overview page and SEP-3392, however, state that even with breaking changes, identifiers are kept, and new identifiers are only used when both old and new behaviors coexist within a single version of the protocol. SEP-3392 explicitly states that its rules supersede those of SEP-2133 (Section 4.3). This discrepancy is a difference in timing, and the wording in SEP-3392 determines the current rule.

9.2 What the Documentation Does Not List

The Server Cards column in the client matrix (Section 7.3).
In the extension table on the client matrix, the rows for MCP Tasks and Server Cards (Section 7.3).
On the overview page, plans to promote the three Stable extensions into the core (Section 5.1).

9.3 Items with No Statement Found

The identifier for Server Cards. Searched in the overview page, SEP-2127, the ext-server-card README, schema.ts, schema.json, and the Server Card Working Group charter (Section 5.7).
The SEP for the OAuth Client Credentials extension. Searched in the OAuth Client Credentials page and the ext-auth README (Section 5.2).
When MCP Tasks will be promoted into the core (Section 5.5).
The date the Ruby SDK reached Tier 1. Searched in the SDK page and the Ruby SDK README (Section 8.2).

The fact that an item cannot be found does not necessarily mean that the item does not exist.

9.4 Important Notes When Reading

The values in the tables in this article are as of November 10, 2026. The stage table first appeared on the official page only recently, between October 26 and November 5, 2026, and the moves of specification locations are also in progress (Inference, Section 9.1).
The community manages the client matrix, and it may change with pull requests.
Before using the list, reopen both the overview page and the client matrix.

10. Failure Modes

This chapter gathers common failures identified from the materials presented in Chapters 3 through 9.

Determining the extension stage based on the repository directory names: As of November 10, 2026, in three out of five repositories, the directories do not indicate the extension stage. The stage can be determined from the table on the overview page (Section 9.1).
Interpreting "Stable" in a README as the Stable stage of the extension: The "Stable" designation in the ext-tasks README refers to the state of the schema version. The MCP Tasks stage is currently Beta (Sections 1.4 and 5.5).
Considering an SEP being Final as indicating that the extension is Stable: While SEP-2640 is Final, the Skills over MCP stage is Beta (Sections 1.4 and 5.6).
Waiting for new identifiers whenever there are breaking changes: Under current rules, even with breaking changes, the identifiers do not change. Beta extensions are expected to indicate breaking changes using the revision string in the settings object (Section 4.3).
Writing the old rule of SEP-2133 as the current rule: SEP-3392 states that it replaces the rules of SEP-2133 (Sections 4.3 and 9.1).
Assuming that Stable extensions are enabled by default: Extensions are not enabled by default, regardless of their stage (Section 3.3).
Relying on extension behavior when the other side has not declared the extension: If the other side does not declare support, treat the extension as unsupported (Sections 3.4 and 6.3).
Declaring extension support to the other side on version 2026-07-28 or later only in the locations for versions 2025-11-25 and earlier: The overview page states that, for versions 2026-07-28 and later, clients declare extensions in the _meta of each request, while servers declare them in the server/discover response (Sections 6.1 and 6.2).
Writing blank entries in the client matrix as indicating a lack of support: The community maintains the table, and blank entries do not explicitly state that an extension is unsupported (Section 7.3).
Using the client matrix as a table listing support for all six extensions: The client matrix does not have a column for Server Cards (Section 7.3).
Treating Beta destinations as promises: SEP-3392 states that the destination is a signal, not a promise (Section 4.2).
Assuming that Tier 1 SDKs support official extensions: Extensions are not required for any tier (Section 8.2).
Inferring the Server Cards identifier from the format used by other extensions: The identifier was not found in the documentation referenced in this article (Section 5.7).
Copying this article and previously published lists without regard to the verification date: The number of official extensions increased from four in September 2026 to six in November 2026 (Section 5.8).

11. Frequently Asked Questions About MCP Official Extensions

This section answers common questions related to the reader profile outlined in Section 1.1, using sentences from Chapters 3 through 9.

Q1. How many official extensions are available, and which ones are considered Stable?

As of November 10, 2026, there are six official extensions available. Of these, three are considered "Stable": OAuth Client Credentials, Enterprise-Managed Authorization, and MCP Apps. The remaining three—MCP Tasks, Skills over MCP, and Server Cards—are currently in Beta (see Section 5.1). The term "Stable" refers to the stage listed in the table on the overview page.

Q2. Can you determine the stage by looking at the repository's directory names and the README file?

Not for every repository. The overview page states that the directory where the specifications are located indicates the stage. As of November 10, 2026, only two repositories, ext-auth and ext-skills, have directories that align with this principle. The "Stable" designation in the README files for ext-tasks and ext-apps refers to the state of the schema or specification version. The README file for ext-server-card describes itself as "Experimental" (see Section 9.1). You can verify the stage by checking the table on the overview page.

Q3. If there is a breaking change, will the extension identifier change?

According to the current rules, it will not. Both the overview page and SEP-3392 state that the identifier remains the same even with breaking changes. A new identifier is only used when old and new behavior must coexist within a single protocol version. SEP-2133 originally required a new identifier for breaking changes, but SEP-3392 superseded this requirement (Section 4.3).

Q4. Do blank cells in the client matrix mean that those clients do not support the extension?

A blank cell does not tell you that. The client matrix is a table managed by the community. A blank cell means that the table has no checkmark; it does not explicitly state that the client lacks support (see Section 7.3). The client matrix does not include a column for Server Cards.

Q5. If an SEP is Final, is its extension Stable?

No. The "Final" status of an SEP indicates that the proposal document has been accepted. The stage of the extension is shown in the table on the overview page. SEP-2640 is Final, but the "Skills over MCP" stage is currently in Beta (Section 1.4).

Q6. Is it not possible to use extensions on versions before `2026-07-28`?

There are cases where they can be used. The overview page states that extensions became an official part of the protocol in version 2026-07-28, and that before that, many SDKs, clients, and servers negotiated extensions in initialize. However, on version 2025-11-25 and earlier, the extensions field is not part of the published schemas, and supporting it is not required for conformance (Section 6.3). The overview page advises users to verify whether their SDK can send and receive this field, and to confirm that the extension supports the negotiated protocol version.

Q7. Is a Stable extension active without a declaration?

No. The overview page states that extensions are disabled by default at any stage and that developers must explicitly opt in (Section 3.3). Extensions only function when both the client and server have declared their support.

Q8. When will MCP Tasks return to the core?

The documents reviewed for this article do not contain any information regarding that timeframe (No statement found). While the destination listed in the overview page's table is "Core," SEP-3392 states that this destination is a signal to implementers and not a commitment (Sections 5.5 and 4.2).

Q9. What is the identifier for Server Cards?

The documents reviewed for this article do not contain the Server Cards identifier (No statement found). SEP-2127 states that the initial Server Card format does not advertise MCP capabilities or extension support (Section 5.7). This does not indicate the absence of an identifier.

Q10. Does a Tier 1 SDK support the official extensions?

Not necessarily. The SDK tiers page states that experimental features and protocol extensions are not required for any tier. The overview page indicates that the SDK maintainers are free to decide which extensions to support (Section 8.2). Check the SDK documentation to confirm which extensions are supported.

12. Summary

Before using the list of official MCP extensions, check the following:

Revisit the overview page and confirm that the number, stages, and destinations of the extensions have not changed since the verification date of November 10, 2026.
Refer to the table on the overview page to determine the extension stages, rather than relying on repository directory names or README files.
Use the term "Stable" solely to indicate the extension stage, and avoid mixing it with "Stable" from README files or "Final" from SEPs.
Verify the location where you declare extensions within your protocol version. For versions 2026-07-28 and later, this is in _meta and server/discover; for versions 2025-11-25 and earlier, it is within initialize under capabilities.extensions.
If only one side supports an extension, determine whether your extension should fall back to core behavior or reject the request.
Interpret the client matrix as a community-maintained table with verification dates, and do not assume that blank entries indicate non-support.
Confirm which extensions your SDK supports by consulting its documentation.
Avoid inferring and writing values that are not found in the documentation, such as the Server Cards identifier.

13. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi