Extensions Overview changedextensions/overview
Nearest release: v2.1.314, published 12 hours after upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 29 Oct 2026 11:37 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 29 Oct 2026 12:07 UTC.
Upstream edited
Recorded here
Lines+68added
Lines−35removed
From line
12
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits9to this page, all time
## Extension Lifecycle ### MCP Server Cards ### Promotion to Core ### Graduation to Official Status
The whole hunk
from line 12, old and new numbered
/
from line 12
1212>
1313> If you're building a third-party extension, use a reversed domain name you own as the vendor prefix to avoid collisions (similar to Java package naming). For example, a company owning `example.com` would use `com.example/` as their prefix (e.g., `com.example/my-extension`).
1414
15## Extension Lifecycle
16
17Every extension is at one of three stages, and may later be promoted into the core specification. The stage decides which changes are allowed, who approves them, and what implementers can expect. For full details, see [SEP-3392: Extension Lifecycle](https://modelcontextprotocol.io/seps/3392-extension-lifecycle.md).
18
19| Stage | Protocol changes | Changes approved by | Entry | What implementers can expect |
20| - | - | - | - | - |
21| **Experimental** | Any change, at any time, without notice | Extension Maintainer | Added by an Extension Maintainer | Nothing. The design may change or disappear. |
22| **Beta** | Any change, with breaking changes expected to be rare | Extension Maintainer | Extensions Track SEP | Real usage is welcome. Breaking changes are documented. |
23| **Stable** | Only with a new core protocol revision | Extension Maintainer | Second Extensions Track SEP | Behavior is fixed within a protocol revision. |
24
25An extension starts as Experimental and must pass through Beta. From Beta it either becomes Stable, or a Standards Track SEP promotes it into the core specification. A Stable extension can also be promoted later. Each Beta extension states its intended destination, Stable or Core, which may change while it is in Beta.
26
27An extension's identifier does not change when its stage changes.
28
1529## Official Extension Repositories
1630
17Official extensions live inside the [Model Context Protocol GitHub organization](https://github.com/modelcontextprotocol/) in repositories with the `ext-` prefix.
31Official extensions live inside the [Model Context Protocol GitHub organization](https://github.com/modelcontextprotocol/) in repositories with the `ext-` prefix. One repository can hold several related extensions at different stages. Inside the repository, the directory that holds an extension's specification shows its stage: `specification/experimental/`, `specification/beta/` or `specification/stable/`. Extensions that were promoted to the core specification or have ended move to `specification/archived/`.
1832
1933### MCP Authorization Extensions
2034
from line 37
2337> Extensions for supplementary authorization mechanisms beyond the core
2438> specification.
2539
26| Extension | Description |
27| - | - |
28| [OAuth Client Credentials](https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials.md) | OAuth 2.0 client credentials flow for machine-to-machine authentication. |
29| [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization.md) | Framework for enterprise environments requiring centralized access control. |
40| Extension | Stage | Description |
41| - | - | - |
42| [OAuth Client Credentials](https://modelcontextprotocol.io/extensions/auth/oauth-client-credentials.md) | Stable | OAuth 2.0 client credentials flow for machine-to-machine authentication. |
43| [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization.md) | Stable | Framework for enterprise environments requiring centralized access control. |
3044
3145### MCP Apps
3246
from line 48
3448>
3549> Extensions for interactive UI elements in conversational MCP clients.
3650
37| Extension | Description |
38| - | - |
39| [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview.md) | Allows MCP Servers to display interactive UI elements (charts, forms, video players) inline within conversations |
51| Extension | Stage | Description |
52| - | - | - |
53| [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview.md) | Stable | Allows MCP Servers to display interactive UI elements (charts, forms, video players) inline within conversations |
4054
4155To get started building MCP Apps, see the [quickstart guide](https://modelcontextprotocol.io/extensions/apps/build.md#getting-started) or read the full [MCP Apps documentation](https://apps.extensions.modelcontextprotocol.io/api/documents/Quickstart.html).
4256
4357### MCP Tasks
4458
45| Extension | Description |
46| - | - |
47| [MCP Tasks](https://modelcontextprotocol.io/extensions/tasks/overview.md) | Asynchronous task execution for long-running operations, with polling, mid-flight input, and durable handles. |
59> **[modelcontextprotocol/ext-tasks](https://github.com/modelcontextprotocol/ext-tasks)**
60>
61> Extensions for long-running operations.
4862
63| Extension | Stage | Description |
64| - | - | - |
65| [MCP Tasks](https://modelcontextprotocol.io/extensions/tasks/overview.md) | Beta, to Core | Asynchronous task execution for long-running operations, with polling, mid-flight input, and durable handles. |
66
4967### Skills over MCP
5068
5169> **[modelcontextprotocol/ext-skills](https://github.com/modelcontextprotocol/ext-skills)**
from line 70
5270>
5371> Discover and read Agent Skills from MCP servers.
5472
55| Extension | Description |
56| - | - |
57| [Skills over MCP](https://modelcontextprotocol.io/extensions/skills/overview.md) | Discover workflow instructions and read supporting files through MCP resources. |
73| Extension | Stage | Description |
74| - | - | - |
75| [Skills over MCP](https://modelcontextprotocol.io/extensions/skills/overview.md) | Beta, destination not yet stated | Discover workflow instructions and read supporting files through MCP resources. |
5876
5977See the [Skills overview](https://modelcontextprotocol.io/extensions/skills/overview.md) to get started and the
6078[client matrix](https://modelcontextprotocol.io/extensions/client-matrix.md) for implementation support.
6179
80### MCP Server Cards
81
82> **[modelcontextprotocol/ext-server-card](https://github.com/modelcontextprotocol/ext-server-card)**
83>
84> HTTP discovery of MCP server metadata.
85
86| Extension | Stage | Description |
87| - | - | - |
88| [Server Cards](https://modelcontextprotocol.io/seps/2127-mcp-server-cards.md) | Beta, destination not yet stated | Lets clients discover a server's metadata before connecting to it. |
89
6290## Experimental Extensions
6391
64Experimental extensions provide an incubation pathway for [Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups.md) to prototype ideas and collaborate on extension concepts before formal SEP submission.
92Experimental extensions provide an incubation pathway for [Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups.md) to prototype ideas and collaborate on extension concepts before or alongside a SEP.
6593
66Experimental extension repositories live within the MCP GitHub organization with the `experimental-ext-` prefix (e.g., `experimental-ext-interceptors`).
94An Experimental extension lives either under `specification/experimental/` in an existing `ext-` repository, or in its own repository with the `experimental-ext-` prefix (e.g., `experimental-ext-interceptors`). Everything in an `experimental-ext-` repository is Experimental.
6795
6896### Ground Rules
6997
7098* Every experimental extension needs to be associated with a Working Group or Interest Group
71* Repositories and published packages need to clearly indicate their experimental status (e.g., in the README and package name)
72* [Core Maintainers](https://modelcontextprotocol.io/community/contributor-ladder.md#core-maintainer) retain oversight of experimental extension repositories, including the ability to archive or remove them
99* Published packages need to clearly indicate their experimental status (e.g., in the README and package name)
100* Implementers should pin to a tag or commit, because two revisions of an Experimental extension need not be compatible
101* [Core Maintainers](https://modelcontextprotocol.io/community/contributor-ladder.md#core-maintainer) retain oversight of experimental extensions, including the ability to archive or remove them
73102
74### Graduation to Official Status
75
76To promote an experimental extension to official status, it goes through the standard SEP process (Extensions Track). Feel free to reference the experimental repository and any reference implementations you built during incubation to demonstrate the extension's practicality.
77
78103## Creating Extensions
79104
80The lifecycle for official extensions follows a SEP-based process. For full details, see [SEP-2133: Extensions](https://modelcontextprotocol.io/seps/2133-extensions.md).
1051. **Prototype**: Add the extension under `specification/experimental/` in an `ext-` repository, or create an `experimental-ext-` repository.
1062. **Propose Beta**: Create a SEP in the main MCP repository using the [standard SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md) with type **Extensions Track**. State whether the extension is intended to become Stable or to be promoted to Core.
1073. **Implement**: Build at least one reference implementation in an official SDK. This is required before the SEP can be reviewed.
1084. **Review**: [Core Maintainers](https://modelcontextprotocol.io/community/contributor-ladder.md#core-maintainer) review the SEP and have final authority over inclusion.
1095. **Publish**: Once the SEP is accepted, open a PR that moves the extension to `specification/beta/` in an `ext-` repository. A Core Maintainer approves the move.
1106. **Gather evidence**: During Beta, keep a public list of known implementations and the feedback received from them.
1117. **Stabilize or promote**: A second Extensions Track SEP moves the extension to Stable. It needs two independent, interoperating implementations (one client-side, one server-side) and a [conformance scenario](https://modelcontextprotocol.io/community/sep-guidelines.md#conformance-test-requirement). Alternatively, a Standards Track SEP promotes the extension into the core specification.
81112
821. **Propose**: Create a SEP in the main MCP repository using the [standard SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md) with type **Extensions Track**.
832. **Implement**: Build at least one reference implementation in an official SDK — this is required before the SEP can be reviewed.
843. **Review**: [Core Maintainers](https://modelcontextprotocol.io/community/contributor-ladder.md#core-maintainer) review the SEP and have final authority over inclusion.
854. **Publish**: Once approved, open a PR to add the extension to the extension repository.
865. **Adopt**: After that, other clients, servers, and SDKs can implement the extension too.
87
88113### Requirements
89114
90115* Extension specifications need to use RFC 2119 language (MUST, SHOULD, MAY)
91* Extensions must have an associated working group or interest group
116* Extensions must have an associated working group or interest group, and at least one Extension Maintainer listed in the repository's `MAINTAINERS.md`
92117
93118### SDK Implementation
94119
from line 121
96121
97122> [!NOTE]
98123>
99> Extensions are always disabled by default and require explicit opt-in from the developer.
124> Extensions are always disabled by default and require explicit opt-in from the developer, at every stage.
100125
101126### Evolution
102127
103Extensions evolve independently of the core protocol. Updates are managed by the extension repository maintainers and don't require core maintainer review.
128Changes to an extension are approved by its Extension Maintainers and don't require Core Maintainer review. What may change depends on the stage:
104129
105That said, backwards compatibility matters. When you need to change an extension, prefer using capability flags or versioning within the extension settings object rather than creating a new extension identifier. If a breaking change is unavoidable, use a new identifier (e.g., `io.modelcontextprotocol/my-extension-v2`).
130* **Experimental**: anything, at any time.
131* **Beta**: prefer additive changes, such as new optional fields or capability flags in the settings object. Breaking changes are allowed but should be rare and batched, announced in the Working Group or Interest Group first, and recorded in a changelog. An extension that makes a breaking change should add or increment a `revision` string in its settings object, so that peers can detect a mismatch.
132* **Stable**: published as revisions keyed to core protocol revisions, such as `specification/stable/<name>/2026-07-28/`. A published revision is immutable. Changes accumulate in a `draft/` directory and take effect only with a new core protocol revision. The behavior of the extension for a pair of peers is the behavior defined for the protocol revision they negotiate.
106133
134Breaking changes keep the extension's identifier. A new identifier (e.g., `io.modelcontextprotocol/my-extension-v2`) is used only when old and new behavior must coexist under one protocol revision.
135
107136A **breaking change** is any modification that would cause existing implementations to fail or behave incorrectly, including:
108137
109138* Removing or renaming fields
from line 139
110139* Changing field types
111140* Altering the semantics of existing behavior
112141* Adding new required fields
142
143### Promotion to Core
144
145When a Standards Track SEP promotes an extension into the core specification in protocol revision R, the feature is core behavior for requests that declare R or later, whether or not the extension is advertised. For earlier revisions, the extension's final revision still applies, so a client that supports earlier revisions should keep advertising the extension. The extension's specification moves to `specification/archived/` once R is released.
113146
114147## Negotiation
115148
No line in this hunk matches that.