[Doc] Align the Docs Page Names With the MCP Specification

README.md

@@ -9,7 +9,7 @@ Detailed guides are available at https://ruby.sdk.modelcontextprotocol.io.
 - Build [MCP servers](https://ruby.sdk.modelcontextprotocol.io/server/) that expose tools, prompts, and resources to any MCP host
 - Build [MCP clients](https://ruby.sdk.modelcontextprotocol.io/client/) that connect to any MCP server, with automatic lifecycle negotiation and OAuth 2.1 authorization
 - Speak every standard transport: stdio and Streamable HTTP (including SSE), with a Rails integration
-- Cover the full protocol surface: server-to-client requests, multi round-trip results, notifications, progress, logging, cancellation, completions, and pagination
+- Cover the full protocol surface: server-to-client requests, multi round-trip requests, notifications, progress, logging, cancellation, completions, and pagination
 
 ## Installation
 

docs/_client/index.md

@@ -25,9 +25,9 @@ This class supports:
 - Resource reading via the `resources/read` method (`MCP::Client#read_resource`)
 - Prompt listing via the `prompts/list` method (`MCP::Client#prompts`)
 - Prompt retrieval via the `prompts/get` method (`MCP::Client#get_prompt`)
-- Completion requests via the `completion/complete` method (`MCP::Client#complete`); see [Completions](/server/completions/)
+- Completion requests via the `completion/complete` method (`MCP::Client#complete`); see [Completion](/server/completion/)
 - Automatic driving of multi round-trip `input_required` results once `on_elicitation`, `on_sampling`,
-  or `on_roots` handlers are registered; see [Multi-Round-Trip Results](/client/multi-round-trip-results/)
+  or `on_roots` handlers are registered; see [Multi Round-Trip Requests](/client/mrtr/)
 - Cancellation of in-flight requests via the `cancellation:` keyword; see [Cancellation](/client/cancellation/)
 - Cursor-based page iteration on the `list_*` methods and whole-collection fetching with
   the `max_pages` guard; see [Pagination](/client/pagination/)

docs/_client/lifecycle.md

@@ -32,7 +32,7 @@ only when the server does not serve the modern lifecycle, or when `mode: :legacy
 ## Lifecycle Negotiation
 
 `MCP::Client#connect` selects the protocol lifecycle automatically by default: on the bundled
-`MCP::Client::HTTP` and `MCP::Client::Stdio` transports it probes [`server/discover`](/server/discovery/) first and adopts
+`MCP::Client::HTTP` and `MCP::Client::Stdio` transports it probes [`server/discover`](/server/discover/) first and adopts
 the stateless modern lifecycle (MCP 2026-07-28, SEP-2575) when the server serves it, falling back to
 the classic `initialize` handshake otherwise. Custom transports whose `connect` does not declare
 a `mode:` keyword always receive the classic call shape, unchanged.
@@ -69,7 +69,7 @@ Pass `mode: :legacy` for an immediate return to the previous behavior, or switch
 `MCP::Client#discover` sends `server/discover` directly: sessionless capability discovery
 that works before (or instead of) `connect`. It returns an `MCP::Client::DiscoverResult` struct
 exposing `supported_versions`, `capabilities`, `server_info`, `instructions`, and
-the `ttl_ms` / `cache_scope` cache hints; see the server [Discovery](/server/discovery/) page
+the `ttl_ms` / `cache_scope` cache hints; see the server [Discovery](/server/discover/) page
 for the wire shapes.
 
 ```ruby

docs/_client/multi-round-trip-results.md → docs/_client/mrtr.md

@@ -1,10 +1,12 @@
 ---
 layout: default
-title: Multi-Round-Trip Results
+title: Multi Round-Trip Requests
 nav_order: 4
+redirect_from:
+  - /client/multi-round-trip-results/
 ---
 
-# Multi-Round-Trip Results
+# Multi Round-Trip Requests
 
 MCP 2026-07-28 replaces in-flight server-to-client requests with Multi Round-Trip Requests (SEP-2322): instead of issuing `sampling/createMessage`, `roots/list`,
 or `elicitation/create` while a request is being processed, a server may answer with a result whose `resultType` is `"input_required"`, carrying an `inputRequests` map
@@ -57,4 +59,4 @@ Servers on legacy protocol versions never send `resultType`, so existing behavio
 ## Server Side
 
 Authoring `input_required` results with `InputRequiredResult`, securing `requestState`, `resultType` stamping, and the legacy fulfillment
-shim that serves pre-2026 clients are documented on the server [Multi-Round-Trip Results](/server/multi-round-trip-results/) page.
+shim that serves pre-2026 clients are documented on the server [Multi Round-Trip Requests](/server/mrtr/) page.

docs/_client/transports.md

@@ -166,7 +166,7 @@ a JSON-RPC `-32601` (method not found) error. To handle methods other than `elic
 
 On a [modern](/client/lifecycle/) connection servers cannot send requests at all; the same
 registered handlers instead drive the requests embedded in `input_required` results,
-as documented on [Multi-Round-Trip Results](/client/multi-round-trip-results/).
+as documented on [Multi Round-Trip Requests](/client/mrtr/).
 
 ### Server-to-Client Requests (Sampling)
 

docs/_extensions/capability-extensions.md

@@ -23,7 +23,7 @@ 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/discovery/#the-stateless-modern-lifecycle), the same declarations appear in the `server/discover` result,
+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.

docs/_server/cancellation.md

@@ -20,7 +20,7 @@ is never cancellable per the spec.
 {: .note }
 > Cancellation by notification belongs to the handshake lifecycle, where the session correlates
 > `notifications/cancelled` with the in-flight request it targets. Requests of the
-> [modern lifecycle](/server/discovery/#the-stateless-modern-lifecycle) are sessionless single POST exchanges, so a separately
+> [modern lifecycle](/server/discover/#the-stateless-modern-lifecycle) are sessionless single POST exchanges, so a separately
 > POSTed cancel notification cannot reach them; a modern client abandons a request by closing
 > the connection instead.
 

docs/_server/completions.md → docs/_server/completion.md

@@ -1,10 +1,12 @@
 ---
 layout: default
-title: Completions
+title: Completion
 nav_order: 16
+redirect_from:
+  - /server/completions/
 ---
 
-# Completions
+# Completion
 
 MCP spec includes [Completions](https://modelcontextprotocol.io/specification/latest/server/utilities/completion),
 which enable servers to provide autocompletion suggestions for prompt arguments and resource URIs.

docs/_server/configuration.md

@@ -201,6 +201,6 @@ If an invalid `protocol_version` value is set, an `ArgumentError` is raised.
 The pin scopes the `initialize` handshake, so it accepts handshake versions (`2025-11-25` and earlier) only. Per the SEP-2575 era model,
 `2026-07-28` carries its version on every request and has no handshake at all, so there is nothing for a pin to configure there and setting it raises `ArgumentError`;
 a client asking `initialize` for a modern version is counter-offered the pinned version (or the latest handshake version), matching the TypeScript and Python SDKs.
-Clients reach `2026-07-28` through [`server/discover`](/server/discovery/) and the per-request `_meta` envelope, which the bundled transports serve alongside the handshake with no configuration needed.
+Clients reach `2026-07-28` through [`server/discover`](/server/discover/) and the per-request `_meta` envelope, which the bundled transports serve alongside the handshake with no configuration needed.
 
 Be sure to check the [MCP spec](https://modelcontextprotocol.io/specification/versioning) for the protocol version to understand the supported features for the version being set.

docs/_server/discovery.md → docs/_server/discover.md

@@ -2,6 +2,8 @@
 layout: default
 title: Discovery
 nav_order: 3
+redirect_from:
+  - /server/discovery/
 ---
 
 # Discovery

docs/_server/elicitation.md

@@ -13,9 +13,9 @@ Elicitation is a **server-to-client request**. The server sends a request and bl
 
 {: .note }
 > Unlike [roots](/server/roots/) and [sampling](/server/sampling/), elicitation carries no SEP-2577 deprecation
-> and remains fully available. On the [modern lifecycle](/server/discovery/#the-stateless-modern-lifecycle) (MCP 2026-07-28), which forbids server-initiated requests,
+> and remains fully available. On the [modern lifecycle](/server/discover/#the-stateless-modern-lifecycle) (MCP 2026-07-28), which forbids server-initiated requests,
 > an `elicitation/create` request is embedded in an `input_required` result instead;
-> see [Multi-Round-Trip Results](/server/multi-round-trip-results/).
+> see [Multi Round-Trip Requests](/server/mrtr/).
 
 {: .important }
 > Per SEP-2260, server-to-client requests (`roots/list`, `sampling/createMessage`, `elicitation/create`) must be associated with

docs/_server/index.md

@@ -31,11 +31,11 @@ It implements the Model Context Protocol specification, handling model context r
 
 - `initialize` - Initializes the protocol and returns server capabilities
 - `server/discover` - Sessionless capability discovery (MCP 2026-07-28, SEP-2575): returns the server's capabilities
-  before `initialize` and without an `Mcp-Session-Id`, and anchors the stateless modern lifecycle; see [Discovery](/server/discovery/)
+  before `initialize` and without an `Mcp-Session-Id`, and anchors the stateless modern lifecycle; see [Discovery](/server/discover/)
 - `subscriptions/listen` - Long-lived notification subscription stream (MCP 2026-07-28, SEP-2575), replacing the legacy HTTP GET
-  listening stream; see [Notification Subscriptions](/server/notification-subscriptions/)
+  listening stream; see [Subscriptions](/server/subscriptions/)
 - Multi round-trip `input_required` results (MCP 2026-07-28, SEP-2322): handlers return `MCP::Server::InputRequiredResult` to ask
-  the client for additional input instead of performing a server-initiated request; see [Multi-Round-Trip Results](/server/multi-round-trip-results/)
+  the client for additional input instead of performing a server-initiated request; see [Multi Round-Trip Requests](/server/mrtr/)
 - `ping` - Simple health check
 - `logging/setLevel` - Configures the minimum log level for the server
 - `tools/list` - Lists all registered tools and their schemas

docs/_server/logging.md

@@ -15,7 +15,7 @@ The `notifications/message` notification is used for structured logging between
 > while remaining fully supported under `2025-11-25`. Use stderr or OpenTelemetry for new servers.
 
 {: .note }
-> On the [modern lifecycle](/server/discovery/#the-stateless-modern-lifecycle), where `logging/setLevel` does not exist, the level
+> On the [modern lifecycle](/server/discover/#the-stateless-modern-lifecycle), where `logging/setLevel` does not exist, the level
 > comes per request from the `io.modelcontextprotocol/logLevel` `_meta` member: it authorizes
 > `notifications/message` for that request only, delivered on the request's own response stream.
 > A request without the member (or with an unrecognized level) receives no log messages.

docs/_server/multi-round-trip-results.md → docs/_server/mrtr.md

@@ -1,12 +1,14 @@
 ---
 layout: default
-title: Multi-Round-Trip Results
+title: Multi Round-Trip Requests
 nav_order: 10
+redirect_from:
+  - /server/multi-round-trip-results/
 ---
 
-# Multi-Round-Trip Results
+# Multi Round-Trip Requests
 
-The [modern lifecycle](/server/discovery/#the-stateless-modern-lifecycle) (MCP 2026-07-28) forbids server-initiated requests. Instead, per SEP-2322, a `tools/call`, `prompts/get`, or `resources/read` handler that
+The [modern lifecycle](/server/discover/#the-stateless-modern-lifecycle) (MCP 2026-07-28) forbids server-initiated requests. Instead, per SEP-2322, a `tools/call`, `prompts/get`, or `resources/read` handler that
 opts in to [`server_context:`](/server/server-context/) may return `MCP::Server::InputRequiredResult.new(input_requests:, request_state:)` to ask the client for
 additional input (`elicitation/create`, `sampling/createMessage`, or `roots/list` shapes):
 
@@ -82,4 +84,4 @@ the modern client driver follows. The shim is on by default (matching the TypeSc
 ## Client Side
 
 `call_tool`, `get_prompt`, and `read_resource` drive `input_required` results automatically once the matching handlers are registered;
-see the client [Multi-Round-Trip Results](/client/multi-round-trip-results/) page.
+see the client [Multi Round-Trip Requests](/client/mrtr/) page.

docs/_server/notifications.md

@@ -26,8 +26,8 @@ No extra configuration is needed.
 - **`notify_tools_list_changed`**, **`notify_prompts_list_changed`**, and **`notify_resources_list_changed`** are always broadcast to all connected clients,
 as they represent server-wide state changes. These should be called on the `server` instance directly.
 
-On the [modern lifecycle](/server/discovery/#the-stateless-modern-lifecycle) (MCP 2026-07-28), clients receive these broadcasts through the `subscriptions/listen` stream;
-see [Notification Subscriptions](/server/notification-subscriptions/).
+On the [modern lifecycle](/server/discover/#the-stateless-modern-lifecycle) (MCP 2026-07-28), clients receive these broadcasts through the `subscriptions/listen` stream;
+see [Subscriptions](/server/subscriptions/).
 
 ## Notification Format
 

docs/_server/ping.md

@@ -13,11 +13,11 @@ A `ping` request has no parameters, and the receiver MUST respond promptly with
 
 {: .note }
 > `ping` belongs to the handshake lifecycle: MCP 2026-07-28 removes the method altogether (SEP-2575),
-> since requests of the [modern lifecycle](/server/discovery/#the-stateless-modern-lifecycle) are single POST exchanges whose connection
+> since requests of the [modern lifecycle](/server/discover/#the-stateless-modern-lifecycle) are single POST exchanges whose connection
 > itself signals liveness, leaving nothing to probe between requests. The server answers `ping` on
 > the handshake lifecycle only - a modern request naming it is rejected with `-32601` Method not found -
 > and calling `ping` on a `server_context` while serving a modern request raises an error. The long-lived
-> [`subscriptions/listen`](/server/notification-subscriptions/) stream is kept alive by SSE keepalive
+> [`subscriptions/listen`](/server/subscriptions/) stream is kept alive by SSE keepalive
 > frames instead.
 
 Servers respond to incoming `ping` requests automatically - no setup is required.

docs/_server/progress.md

@@ -51,7 +51,7 @@ The `server_context.report_progress` method accepts:
 string tokens are supported.
 
 {: .note }
-> On the [modern lifecycle](/server/discovery/#the-stateless-modern-lifecycle), progress notifications emitted during a request ride
+> On the [modern lifecycle](/server/discover/#the-stateless-modern-lifecycle), progress notifications emitted during a request ride
 > the request's own SSE response stream. The bundled transport buffers them and flushes after
 > the handler returns, so they preserve order but arrive together with the final response rather
 > than in real time.

docs/_server/notification-subscriptions.md → docs/_server/subscriptions.md

@@ -1,10 +1,12 @@
 ---
 layout: default
-title: Notification Subscriptions
+title: Subscriptions
 nav_order: 12
+redirect_from:
+  - /server/notification-subscriptions/
 ---
 
-# Notification Subscriptions
+# Subscriptions
 
 `subscriptions/listen` is the long-lived notification subscription stream of MCP 2026-07-28 (SEP-2575),
 replacing the legacy HTTP GET listening stream.