c9d36b04bf
Three pages carried names the 2026-07-28 specification does not use: "Multi-Round-Trip Results" for the pattern the specification titles Multi Round-Trip Requests (MRTR) and serves at basic/patterns/mrtr - the results are the `InputRequiredResult` wire type, not the feature - plus "Completions" for the utility the specification titles Completion, and "Notification Subscriptions" for the pattern it titles Subscriptions. Retitle the three pages to the specification's names, move them to /server/mrtr/ and /client/mrtr/, /server/completion/, and /server/subscriptions/ following the specification's slugs, update every internal reference, and keep the URLs published with v1.3.0 working via jekyll-redirect-from. The Discovery page keeps its title but moves from /server/discovery/ to /server/discover/, matching the specification's slug and the `server/discover` RPC, with its published URL redirected the same way.
35 lines
1.6 KiB
Markdown
35 lines
1.6 KiB
Markdown
---
|
|
layout: default
|
|
title: Capability Extensions
|
|
nav_order: 2
|
|
---
|
|
|
|
# Capability Extensions
|
|
|
|
Per SEP-2133, both clients and servers can declare protocol extensions under the `extensions` member of their capabilities.
|
|
Keys are extension identifiers using the reverse-DNS prefix convention (e.g. `"io.modelcontextprotocol/tasks"`, `"com.example/feature"`);
|
|
values are extension-defined configuration objects, with `{}` meaning "supported with no settings".
|
|
|
|
On the server, declare extensions through the `capabilities` keyword, either as a plain hash or via the `MCP::Server::Capabilities` builder:
|
|
|
|
```ruby
|
|
capabilities = MCP::Server::Capabilities.new
|
|
capabilities.support_tools
|
|
capabilities.support_extensions("com.example/feature" => { enabled: true })
|
|
|
|
server = MCP::Server.new(name: "my_server", capabilities: capabilities)
|
|
```
|
|
|
|
The declared extensions appear in the `initialize` result's `capabilities.extensions`. Extensions the client declared during `initialize` are
|
|
readable via `server.client_capabilities[:extensions]` (or `session.client_capabilities[:extensions]` for per-session transports).
|
|
|
|
On the [modern lifecycle](/server/discover/#the-stateless-modern-lifecycle), the same declarations appear in the `server/discover` result,
|
|
and the client's extensions ride each request's `_meta` envelope instead of an `initialize` handshake.
|
|
Inside a handler, `server_context.client_capabilities[:extensions]` reads the current request's declarations
|
|
with envelope-first resolution, on either lifecycle.
|
|
|
|
On the client, pass extensions through `connect`:
|
|
|
|
```ruby
|
|
client.connect(capabilities: { extensions: { "com.example/feature" => {} } })
|
|
```
|