Merge pull request #525 from koic/align_docs_page_names_with_the_spec

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

Author: koic

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.mddocs/_client/multi-round-trip-results.md renamed to 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.mddocs/_server/completions.md renamed to 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.mddocs/_server/discovery.md renamed to docs/_server/discover.md

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