Skip to content

SEP-2133: Extensions framework for MCP#2133

Merged
pja-ant merged 6 commits into
mainfrom
sep/extensions
Jan 26, 2026
Merged

SEP-2133: Extensions framework for MCP#2133
pja-ant merged 6 commits into
mainfrom
sep/extensions

Conversation

@pja-ant

@pja-ant pja-ant commented Jan 22, 2026

Copy link
Copy Markdown
Contributor

This SEP ports the Extensions proposal from issue #1724 to the new PR-based SEP format (per SEP-1850).

Summary

Establishes a framework for extending the Model Context Protocol while maintaining interoperability, clear governance, and appropriate legal structure.

Key Points

  • Extension identifiers: Reverse domain notation with extension name (e.g., io.modelcontextprotocol/oauth-client-credentials)
  • Official extensions: Live under github.com/modelcontextprotocol/ext-* repositories
  • Extensions Track: New SEP type for extension proposals (follows same process as Standards Track)
  • Capability negotiation: Extensions advertised via extensions field in ClientCapabilities/ServerCapabilities
  • Legal requirements: Includes trademark, antitrust, licensing, and contributor license grant provisions

Design Consistency

The patterns described are consistent with existing official extensions (ext-apps and ext-auth).

References

@pja-ant pja-ant changed the title SEP: Extensions framework for MCP SEP-2133: Extensions framework for MCP Jan 22, 2026
@pja-ant pja-ant marked this pull request as ready for review January 22, 2026 16:44
@localden localden added SEP in-review SEP proposal ready for review. labels Jan 22, 2026
@localden localden moved this to In Review in SEP Review Pipeline Jan 22, 2026
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated

@dsp-ant dsp-ant left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add the extension page outline to this PR.

Comment thread seps/2133-extensions.md
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md
Comment thread seps/2133-extensions.md Outdated
Comment thread seps/2133-extensions.md Outdated
@pja-ant pja-ant requested a review from a team as a code owner January 26, 2026 17:24
@pja-ant pja-ant force-pushed the sep/extensions branch 2 times, most recently from 80b489c to 84bdbfd Compare January 26, 2026 17:28
CaitieM20
CaitieM20 previously approved these changes Jan 26, 2026
@pja-ant pja-ant force-pushed the sep/extensions branch 2 times, most recently from 02e50c7 to 1a747b2 Compare January 26, 2026 18:04
bhosmer-ant
bhosmer-ant previously approved these changes Jan 26, 2026
@dsp-ant

dsp-ant commented Jan 26, 2026

Copy link
Copy Markdown
Member

This was accepted by @modelcontextprotocol/core-maintainers unanimously:

Voting results:

  • 7x yes,
  • 2x yes with changes,
  • 0x no votes.

Once comments are addressed, this can be merged and status changed to final. @pja-ant please ensure that SDK's are implementing the necessary changes.

@pja-ant pja-ant deleted the sep/extensions branch January 26, 2026 23:57
@pja-ant pja-ant added final SEP finalized. and removed accepted SEP accepted by core maintainers, but still requires final wording and reference implementation. labels Jan 27, 2026
@localden localden moved this from In Review to Final in SEP Review Pipeline Jan 28, 2026
@mcp-virtual-tpm mcp-virtual-tpm Bot added this to the 2026-06-30-RC milestone Apr 17, 2026
koic added a commit to modelcontextprotocol/ruby-sdk that referenced this pull request Jun 14, 2026
## Motivation and Context

SEP-2133 (modelcontextprotocol/modelcontextprotocol#2133, merged for
the 2026-07-28 spec release) establishes the extensions framework for MCP:
both `ClientCapabilities` and `ServerCapabilities` gain an optional `extensions`
member keyed by reverse-DNS extension identifiers
(e.g. `"io.modelcontextprotocol/tasks"`, `"com.example/feature"`), with arbitrary
extension-defined configuration objects as values and an empty object meaning
"supported with no settings". Official extensions such as MCP Apps (SEP-1865)
and the Tasks extension (SEP-2663) are layered on this field.

This mirrors the shape the TypeScript SDK merged (typescript-sdk#1630):
plain declaration and passthrough, no registrar API and no key-format validation
(the naming convention is documented instead).

- `MCP::Server::Capabilities` gains `support_extensions` (repeated calls merge),
  accepts an `:extensions` key in its constructor hash, and includes `extensions`
  in `to_h`. The class was previously dead code: it was never required and
  `Server.new` only took plain hashes. It is now required by `lib/mcp/server.rb`,
  and `Server.new(capabilities:)` accepts either a plain Hash (as before) or
  a `Capabilities` instance.
- Server-declared extensions appear in the `initialize` result;
  extensions the client declares during `initialize` were already stored verbatim and
  are readable via `Server#client_capabilities[:extensions]` and
  `ServerSession#client_capabilities[:extensions]` (now covered by tests).
- `MCP::Client#connect(capabilities:)` already passes capabilities through verbatim;
  its documentation now covers the `extensions` member.

Resolves #378.

## How Has This Been Tested?

- New `test/mcp/server/capabilities_test.rb` covers the previously untested
  `Capabilities` class: empty default, constructor round-trip, extensions via
  constructor and `support_extensions`, merge semantics, nil tolerance,
  and omission from `to_h` when never declared.
- New tests in `test/mcp/server_test.rb` assert that the `initialize` result
  carries declared extensions (from both a plain hash and a `Capabilities` instance)
  and that client-declared extensions are readable via `Server#client_capabilities`
  and `ServerSession#client_capabilities`.

## Breaking Changes

None. `extensions` is additive and appears on the wire only when declared;
servers constructed with plain capability hashes behave exactly as before.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

final SEP finalized. SEP

Development

Successfully merging this pull request may close these issues.

9 participants