Extensions
Tasks, MCP Apps, and the authorization extensions — optional, opt-in additions to the core protocol, and how negotiation actually works
Extensions
TL;DR
Extensions add capability beyond the core protocol — machine-to-machine auth, inline interactive UI, durable long-running operations — without changing core behavior for anyone who doesn't opt in. They're identified by a vendor-prefixed name, negotiated through the same capability declarations used elsewhere in MCP, and always disabled by default.
| Property | Value |
|---|---|
| Level | Intermediate |
| Reading time | ~18 minutes |
| Prerequisites | Connecting Claude to MCP |
| You will understand | How extensions are identified, negotiated, and what the notable official ones actually do |
What an Extension Is, and Isn't
An extension is an optional, opt-in addition to the core spec — never required for basic protocol conformance, and always something both sides have to explicitly agree to before it does anything.
Extensions are identified with a namespaced format: {vendor-prefix}/{extension-name}. Official extensions use io.modelcontextprotocol — for example io.modelcontextprotocol/oauth-client-credentials. A third party building their own would use a reversed domain they actually own, the same convention Java packages use, to avoid collisions: a company owning example.com would prefix theirs as com.example/my-extension.
Extensions exist for functionality that's modular (a distinct concern like authentication), specialized (industry-specific logic that most servers will never need), or experimental (an idea being incubated before it's proven enough for core inclusion).
Negotiation
Both sides advertise extension support through the same capability-declaration mechanism covered in The MCP Architecture — the client's per-request _meta, and the server's server/discover response.
// Client, in the _meta of any request
{
"_meta": {
"io.modelcontextprotocol/clientCapabilities": {
"extensions": {
"io.modelcontextprotocol/ui": {
"mimeTypes": ["text/html;profile=mcp-app"]
}
}
}
}
}// Server, in its server/discover response
{
"result": {
"capabilities": {
"extensions": {
"io.modelcontextprotocol/ui": {}
}
}
}
}Each extension defines the shape of its own settings object — an empty object simply means "supported, no configuration needed."
Graceful degradation
If one side supports an extension and the other doesn't, someone has to fall back — and that behavior should be designed in, not discovered by accident. A server offering UI-enhanced tools through the MCP Apps extension should still return meaningful plain-text content for a client that never declared support for it. A server that requires a specific auth extension can instead reject the connection outright, if falling back genuinely isn't viable — but that choice should be a deliberate one, documented, not a silent failure.
Notable Official Extensions
MCP Apps: Interactive UI Inline
Lets a server return more than text — charts, forms, a video player — rendered directly inside the conversation, rather than described in prose. A server exposing a data-query tool might use this to return an actual interactive chart instead of a table dumped as text, for clients that declared support for it.
MCP Tasks: Durable Handles for Long-Running Work
Not every operation finishes in the time a normal request-response round trip allows. Tasks let a server return a durable handle immediately, which the client can poll for status, and which can accept mid-flight input if the operation needs it.
Client: "Re-index my entire knowledge base" (a job that will take minutes)
Server: returns a task handle immediately, rather than blocking the connection
Client: polls the handle periodically
Server: reports progress, and eventually a result, against that same handleThis is the extension the MCP project brief points to for exactly this kind of job — a long-running re-index that shouldn't block a single tool call.
Authorization Extensions
Two extensions extend the OAuth model from Authorization & Security to situations it doesn't naturally fit:
When the core OAuth flow isn't the right shape
OAuth Client Credentials (machine-to-machine)
The core authorization flow assumes a human in the loop — a browser, a login screen, a user clicking "authorize." That doesn't fit a service-to-service call with no person present. The Client Credentials extension provides a flow for exactly that: one machine authenticating directly to another.
Enterprise-Managed Authorization
A framework for enterprise environments that need centralized, org-wide access control rather than per-user, per-server authorization decisions made independently everywhere.
The Extension Lifecycle
Extensions follow a deliberate process before becoming official:
From idea to adopted extension
Propose
A SEP (Specification Enhancement Proposal) in the main MCP repository, Extensions Track
Implement
At least one reference implementation in an official SDK — required before review, not after
Review
Core Maintainers review and have final authority over inclusion
Publish
Added to the official extension repository
Adopt
Other clients, servers, and SDKs can now implement it too
Experimental extensions get an earlier incubation path — associated with a Working Group or Interest Group, living in a repository clearly marked experimental, before going through the same SEP process to graduate to official status.
Backwards compatibility
A breaking change to an extension needs a new identifier, not a silent change under the old one. Removing or renaming a field, changing a field's type, or adding a new required field are all breaking changes. The convention is a versioned identifier — io.modelcontextprotocol/my-extension-v2 — rather than mutating the meaning of io.modelcontextprotocol/my-extension out from under anyone already using it.
Non-breaking evolution (new optional fields, new capability flags) can happen within the same extension identifier — that's the normal, expected path. It's only a semantic break that forces a new name.
Concept Checks
Check yourself
A server declares support for the MCP Apps extension, but a connecting client doesn't. What should the server do?
Fall back to returning meaningful plain-text content instead of the interactive UI, rather than failing the request or returning something the client can't render. Graceful degradation is the expected design for an optional extension — the server should have planned for clients that don't support it, documenting that fallback behavior rather than treating it as an edge case.
Why does the OAuth Client Credentials extension exist, when the core authorization flow already covers OAuth?
Because the core flow assumes a human is present to authorize in a browser via PKCE, which doesn't fit a service calling another service with nobody watching. Client Credentials is a distinct, extension-level flow specifically for machine-to-machine authentication, where user interaction was never going to happen.
An extension maintainer wants to remove a required field from their extension's settings object. What should they do, per the backwards-compatibility rule?
Publish it under a new, versioned identifier (like appending -v2) rather than changing the existing identifier's meaning, since removing a required field is explicitly listed as a breaking change. Implementations still relying on the old identifier keep working against the old behavior; new implementations opt into the new identifier deliberately.
Key Concepts Recap
| Concept | One-line summary |
|---|---|
| Extension | An optional, opt-in addition beyond the core protocol |
| Identifier format | {vendor-prefix}/{extension-name} — io.modelcontextprotocol for official ones |
| Negotiation | Client _meta.clientCapabilities.extensions, server server/discover capabilities |
| Always opt-in, always disabled by default | Neither side should assume support without checking |
| Graceful degradation | Fall back to core behavior, or reject explicitly if the extension is mandatory — decide deliberately |
| MCP Apps | Interactive UI (charts, forms, video) rendered inline |
| MCP Tasks | Durable handles for long-running operations, with polling |
| Auth extensions | Client Credentials (machine-to-machine), Enterprise-Managed Authorization |
| Lifecycle | Propose → Implement → Review → Publish → Adopt |
| Breaking changes need a new identifier | Non-breaking additions can stay under the same one |
Next
With the protocol and its extensions covered, the next page turns to how MCP servers actually fit into an agent's tool surface: MCP Agents & Tool Design.
Connecting Claude to MCP
The full claude mcp add reference — transports, scopes, authentication, config files — plus Claude Desktop and the Claude API's MCP connector
MCP Agents & Tool Design
What changes about agent tool design once tools come from MCP servers you don't fully control, and how to keep a federated tool list usable