Extensions overview

Optional additions to the Model Context Protocol beyond the core specification.

Adapted from Extensions Overview.

Extensions expand what hosts and servers can do while keeping the core protocol stable.

Executive summary

Extensions are modular, specialised or experimental capabilities identified as {vendor-prefix}/{extension-name} (official ones use io.modelcontextprotocol/...). They are disabled by default and require explicit opt-in via capability negotiation.

Official extension areas

Area	Examples
Authorization	OAuth client credentials, enterprise-managed authorization
MCP Apps	Interactive HTML UIs inside hosts — Apps
Tasks	Async long-running operations — Tasks

Official repos live under the Model Context Protocol org with an ext- prefix. Experimental work uses experimental-ext-.

See the client matrix for which hosts implement which extensions.

Negotiation

Clients advertise extension support in _meta["io.modelcontextprotocol/clientCapabilities"].extensions on each request. Servers advertise extensions in server/discover capabilities.

If only one side supports an extension, fall back to core behaviour or reject when the extension is mandatory — document the expected fallback.

Creating extensions

Lifecycle is SEP-based (SEP-2133): propose → implement reference → Core Maintainer review → publish → adopt. Third parties should use a reversed domain they own as vendor prefix.

Negative cases

• Assuming an extension is universal → check the client matrix.
• Enabling extensions by default in SDKs → violates “opt-in” rule.
• Breaking changes without a new extension id / capability flag → breaks clients.

Key takeaways

• Extensions are opt-in and negotiated.
• Official prefix: io.modelcontextprotocol.
• Prefer capability flags over silent breaking changes.

What to do next

Explore MCP Apps, Authorization extensions and Tasks.