FinalStandards Track
This SEP has reached Final status and is preserved as a historical record of
the design as accepted. Changes made to the protocol after finalization are
not reflected here. Refer to the current
specification and its changelog for authoritative
requirements.
Abstract
This SEP establishes a lightweight framework for extending the Model Context Protocol through optional, composable extensions. This proposal defines a governance model and presentation structure for extensions that allows the MCP ecosystem to evolve while maintaining core protocol stability. Extensions enable experimentation with new capabilities without forcing adoption across all implementations, providing clear extension points for the community to propose, review, and adopt enhanced functionality. This SEP defines both official extensions (maintained by MCP maintainers) and experimental extensions (an incubation pathway for Working Groups and Interest Groups to prototype and collaborate on extension ideas before formal acceptance). Externally maintained extensions will likely come at a later stage.Motivation
MCP currently lacks any form of guidance on how extensions are to be proposed or adopted. Without a process, it is unclear how these extensions are governed, what expectations there are around implementation, how they should be referenced in the specification, etc.Specification
Definition
An MCP extension is an optional addition to the specification that defines capabilities beyond the core protocol. Extensions enable functionality that may be modular (e.g., distinct features like authentication), specialized (e.g., industry-specific logic), or experimental (e.g., features being incubated for potential core inclusion). Extensions are identified using a unique extension identifier with the format:{vendor-prefix}/{extension-name}, e.g. io.modelcontextprotocol/oauth-client-credentials or com.example/websocket-transport. The names follow the same rules as the _meta keys, except that the prefix is mandatory.
To prevent identifier collisions, the vendor prefix SHOULD be a reversed domain name that the extension author owns or controls (similar to Java package naming conventions). For example, a company owning example.com would use com.example/ as their prefix.
Breaking changes MUST use a new identifier, e.g. io.modelcontextprotocol/oauth-client-credentials-v2. A breaking change is any modification that would cause existing compliant implementations to fail or behave incorrectly, including: removing or renaming fields, changing field types, altering the semantics of existing behavior, or adding new required fields.
Extensions may have settings that are sent in client/server messages for fine-grained configuration.
This SEP defines Official Extensions and Experimental Extensions. Experimental extensions are maintained within the MCP organization as an incubation pathway but are not yet officially accepted. Unofficial extensions are not recognized by MCP governance and may be introduced and governed by developers outside the MCP organization.
Official Extensions
Official extensions live inside the MCP github org at https://github.com/modelcontextprotocol/ and are officially developed and recommended by MCP maintainers. Official extensions use theio.modelcontextprotocol vendor prefix in their extension identifiers.
An extension repository is a repository within the official modelcontextprotocol github org with the ext- prefix, e.g. https://github.com/modelcontextprotocol/ext-auth.
- Extension repositories are created at the core maintainers discretion with the purpose of grouping extensions in a specific area (e.g. auth, transport, financial services).
- A repository has a set of maintainers (identified by MAINTAINERS.md) appointed by the core maintainers that are responsible for the repository and extensions within it (e.g. ext-auth MAINTAINERS.md, ext-apps MAINTAINERS.md).
- Extensions SHOULD have an associated working group or interest group to guide their development and gather community input.
- Extension specifications MUST use the same language as the core specification (i.e. [BCP 14] [RFC2119] [RFC8174]) and SHOULD be worded as if they were part of the core specification.
Experimental Extensions
Experimental extensions provide an incubation pathway for Working Groups (WGs) and Interest Groups (IGs) to facilitate discovery, prototype ideas, and collaborate on extension concepts before formal SEP submission. Experimental extensions allow cross-company collaboration under neutral governance with clear anti-trust protection and IP clarity. An experimental extension repository is a repository within the official modelcontextprotocol github org with theexperimental-ext- prefix, e.g. https://github.com/modelcontextprotocol/experimental-ext-interceptors.
- Any maintainer MAY create an experimental extension repository while the associated SEP is still in draft state (or before a SEP has been submitted).
- Experimental extensions MUST be associated with a Working Group or Interest Group, whose maintainers are responsible for day-to-day governance of the repository.
- Experimental extension repositories MUST clearly indicate their experimental/non-official status (e.g., in the README) to avoid confusion with official extensions.
- Any published packages from experimental extensions MUST use naming that clearly indicates their experimental status.
- Core maintainers retain oversight of experimental extension repositories, including the ability to archive or remove them.
Lifecycle
Creation
Extensions MAY optionally begin as experimental extensions (see Experimental Extensions section) to facilitate prototyping and collaboration before formal submission. This incubation period is encouraged but not required. To become an official extension, extensions are created via a SEP in the main MCP repository using the standard SEP guidelines but with a new type: Extensions Track. This type follows the same review and acceptance process as Standards Track SEPs, but clearly indicates that the proposal is for an extension rather than a core protocol addition. The SEP must identify the Working Group and Extension Maintainers that will be responsible for the extension. See SEP-2148 for how maintainers are appointed. Extension SEPs:- SHOULD be discussed and iterated on in a relevant working group prior to submission.
- MUST have at least one reference implementation in an official SDK prior to review to ensure the extension is practical and implementable.
- MAY reference an existing experimental extension repository and implementations developed during incubation.
- Will be reviewed by the Core Maintainers, who have the final authority over its inclusion as an Official Extension.
Iteration
Once accepted, extensions may be iterated on without further review from the Core Maintainers. The extension repository maintainers are responsible for the review and acceptance of changes to an extension and SHOULD coordinate change via the relevant working group(s). As extensions are independent of the core protocol, extensions may be updated and deployed at any time, but changes MUST ensure they account for backwards compatibility in their design.Promotion to Core Protocol (Optional)
Eventually, some extensions MAY transition to being core protocol features. This SHOULD be treated as a Standards Track SEP with separate core maintainer review. Note that not all extensions are suitable for inclusion in the core protocol (e.g. those specific to an industry) and may remain as extensions indefinitely.Spec Recommendation
Extensions will be referenced from a new page on the MCP website at modelcontextprotocol.io/extensions (to be created) with links to their specification. Links to relevant extensions MAY also be added to the core specification as appropriate (e.g. https://modelcontextprotocol.io/specification/draft/basic/authorization may link to ext-auth extensions), but they MUST be clearly advertised as optional extensions and SHOULD be links only (not copies of specification text).SDK Implementation
SDKs MAY implement extensions. Where implemented, extensions MUST be disabled by default and require explicit opt-in. SDK documentation SHOULD list supported extensions. SDK maintainers have full autonomy over extension support in their SDKs:- Maintainers are solely responsible for the implementation and maintenance of any extensions they choose to support.
- Maintainers are under no obligation to implement any extension or accept contributed implementations. Extension support is not required for 100% protocol conformance or the upcoming SDK conformance tiers.
- This SEP does not prescribe how SDKs should structure or package extensions. Maintainers may provide extension points, plugin systems, or any other mechanism they see fit.