What is MCP Extensions?
MCP Extensions are optional, namespaced additions to the Model Context Protocol that define capabilities beyond Core and activate only when both Client and Server explicitly support them.
Quick Facts
| Full Name | Model Context Protocol Extensions |
|---|---|
| Created | Formalized in MCP 2026-07-28 |
| Specification | Official Specification |
How It Works
Core versus extension
Core MCP defines the common roles, request model, Tools, Resources, Prompts, Elicitation, standard Transports, and utilities required for baseline interoperability. An Extension adds optional behavior for a narrower problem, such as Tasks, interactive MCP Apps, Skills distribution, or supplementary authorization. Core conformance does not imply any Extension, and an Extension cannot silently redefine Core semantics.
Identifiers and governance
Extension identifiers use a mandatory vendor prefix and name, such as io.modelcontextprotocol/tasks. Official Extensions use the io.modelcontextprotocol prefix and live in ext-* repositories under MCP governance; experimental repositories are explicitly marked as non-official. Third parties should use a reversed domain they control. Breaking changes require a new identifier when existing compliant implementations would otherwise fail or change behavior.
Two-sided negotiation
A Client lists supported Extensions in the extensions map inside io.modelcontextprotocol/clientCapabilities on each Request. A Server lists its Extensions in the capabilities returned by server/discover. The extension-specific settings object refines support; an empty object means support without settings. Implementations must check both sides before using extension messages or result shapes and must not reuse capability state from an unrelated Request.
Fallback and independent evolution
Extensions are disabled by default and evolve independently from Core and from one another. When one peer lacks support, the implementation either falls back to a documented Core behavior or returns a precise missing-capability error when the Extension is mandatory. Deployments should pin the Core revision, Extension identifier and version, SDK package, settings, and fallback path, then test mixed-support combinations rather than assuming a Host or SDK supports every official Extension.
Security and release evidence
Negotiation proves declared compatibility, not provenance, safety, authorization, or user approval. Review the Extension repository and status, validate settings, namespace remote metadata, constrain result sizes, and treat new UI, files, credentials, tasks, and messages as new trust surfaces. Release tests should cover unsupported peers, malformed settings, downgrade behavior, descriptor changes, permission denial, partial SDK support, rollback, and telemetry that records the effective Core and Extension set.
Key Characteristics
- Optional capability layer: adds behavior without changing baseline Core conformance
- Namespaced identity: official and third-party identifiers avoid collisions and implied endorsement
- Two-sided opt-in: Client and Server both advertise support before extension behavior is used
- Independent lifecycle: each Extension owns its specification, compatibility, maintainers, and release cadence
- Graceful degradation: unsupported peers use documented Core fallback or an explicit capability error
- Expanded trust surface: every Extension requires separate provenance, policy, interoperability, and rollback review
Common Use Cases
- Adding asynchronous Tasks to long-running Tool calls without requiring every MCP Client to support them
- Rendering MCP Apps only in Hosts that advertise the UI Extension
- Distributing Agent Skills while reusing Core Resource reads
- Selecting machine-to-machine or enterprise authorization mechanisms beyond the Core user flow
- Incubating a domain-specific protocol feature before considering broader standardization
Example
Loading code...Frequently Asked Questions
Are MCP Extensions part of the Core protocol?
They are recognized by the MCP specification but remain optional additions outside Core. A Client or Server can conform to Core without implementing Tasks, Skills, Apps, or authorization Extensions. Each Extension defines its own messages, settings, compatibility, and fallback behavior.
How do a Client and Server negotiate an MCP Extension?
The Client includes the identifier and settings in its per-request Client Capabilities, and the Server advertises the same identifier in `server/discover`. Extension behavior is available only when both declarations satisfy that Extension's rules. A previous Request or a familiar Server name is not a substitute for the current declaration.
What is the difference between an official and experimental MCP Extension?
Official Extensions have completed the Extensions Track process, use the official vendor prefix, and are maintained in MCP `ext-*` repositories. Experimental Extensions are incubation work, explicitly marked non-official, and can change or be archived. Neither status guarantees support in a particular Host or SDK.
Can an MCP Extension evolve without a new Core release?
Yes. Extensions have independent maintainers and release cycles. Compatible improvements can keep the same identifier, while a breaking change that would alter existing behavior requires a new identifier. Deployments should pin and test the exact Extension version and SDK implementation they use.
Does Extension negotiation make the added capability safe?
No. It proves only that both peers declared compatible support. The Host and Server must still verify provenance, validate data, enforce authorization and consent, constrain side effects and resource use, handle unsupported peers, audit effective versions, and provide rollback.