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.
1.6 KiB
| layout | title | nav_order |
|---|---|---|
| default | Capability Extensions | 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:
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, 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:
client.connect(capabilities: { extensions: { "com.example/feature" => {} } })