88831b46f6
Move the documentation that had grown to 3000+ lines in README.md onto https://ruby.sdk.modelcontextprotocol.io and slim the README down to a quick start and feature overview, following the Python SDK layout: - Add 21 server pages as the docs/_server/ collection (overview plus transports, discovery, tools, prompts, resources, roots, sampling, elicitation, multi round-trip results, notifications, notification subscriptions, cancellation, progress, ping, completions, logging, pagination, server context, configuration, and custom methods), 8 client pages as the docs/_client/ collection (overview, transports, lifecycle, multi round-trip results, cancellation, ping, pagination, and authorization), and 3 extension pages as the docs/_extensions/ collection (overview, capability extensions, and MCP Apps, following the Extensions Overview recommendation that SDK documentation list the supported extensions) - one page per topic, ordered to match the sidebar of the 2026-07-28 specification, with the client-side APIs (pinging, cancelling, and paginating from MCP::Client) documented under Building Clients - Add top-level Examples and Protocol Versions pages after Installation, linking the runnable examples in examples/ and summarizing the supported protocol versions, the era model, and client negotiation - Render the three sections as just-the-docs collections, which list every page beneath a plain category heading in the sidebar with no folding, and serve every page at an extensionless URL under /server/, /client/, and /extensions/, matching the sibling SDK documentation sites - Replace docs/building-servers.md and docs/building-clients.md with redirects to the new section overview pages via jekyll-redirect-from, redirect the previously published /installation.html to its extensionless URL, fold their content that was missing from README.md into the new pages, and update the Tool argument keys reference comment in lib/mcp/server.rb to the relocated Tools page - Reduce README.md to the badges, a compact feature overview in the Python SDK style, installation instructions, a stdio server and client quick start, and a License section, using absolute URLs for the remaining repository links so they resolve on rubygems.org - Adapt formatting where GitHub rendering habits break on the site: convert the numbered "three ways to define" lists into headings, since kramdown restarts numbering at 1 when code blocks split list items, convert GitHub-style alerts into just-the-docs callouts with the SEP-2260 server-to-client association note raised to a red warning, merge the duplicated Exception Reporting and Configuration Block Data sections into the Configuration page, and relocate the Streamable HTTP settings that were nested under the Logging section into the Transports page - Refresh the migrated content against the current implementation: correct stale claims and broken samples the README carried, note on each session-era feature how it relates to the modern lifecycle of MCP 2026-07-28, and point spec links at the latest revision, keeping deliberate 2025-11-25 pins for pages the modern revision removed - Style the site after the Rails API documentation palette (red links and accents on neutral surfaces) with matching light and dark color schemes, center the sidebar and content as one block, add a Previous/Next footer pager following the sidebar order, open external links in a new tab, and serve the MCP logo as the favicon Every code block and heading from the previous README was verified to have a home in the new docs pages or the slimmed README before the reduction; a few samples were corrected rather than copied, as noted above.
4.1 KiB
| layout | title | nav_order |
|---|---|---|
| default | Lifecycle | 3 |
Lifecycle
Before sending requests, a client establishes its lifecycle with the server: the classic initialize handshake
on legacy protocol versions, or the sessionless modern lifecycle of MCP 2026-07-28.
This page covers MCP::Client#connect and how it negotiates between the two.
Handshake
Call MCP::Client#connect to perform the MCP initialization handshake before sending any other requests. The client sends an initialize request through the transport, followed by the required notifications/initialized notification, and caches the server's InitializeResult (protocol version, capabilities, server info, instructions):
client.connect
# => { "protocolVersion" => "2025-11-25", "capabilities" => {...}, "serverInfo" => {...} }
client.connected? # => true
client.server_info # => cached InitializeResult
connect accepts optional client_info:, protocol_version:, and capabilities: keyword arguments. It is idempotent: a second call returns the cached result without contacting the server. After close, state is cleared and connect will handshake again.
This applies to both the Stdio and HTTP transports described on the Transports page.
By default connect negotiates the lifecycle first and performs this handshake
only when the server does not serve the modern lifecycle, or when mode: :legacy or a legacy protocol_version: forces it.
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 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.
client.connect # negotiate automatically (default)
client.connect(mode: :modern) # require the modern lifecycle; fails on legacy-only servers
client.connect(mode: :legacy) # force the classic initialize handshake
client.connect(protocol_version: "2025-11-25") # an explicit legacy version pins the handshake, no probe
Prefer mode: :legacy for spawn-per-invocation CLI tools (the probe adds a round trip per process)
and when using server-initiated requests (on_elicitation / on_sampling), which exist only on
the legacy lifecycle.
Because the raw connect return value and MCP::Client#server_info mirror the wire result,
their shape depends on the negotiated lifecycle: InitializeResult (protocolVersion,
top-level serverInfo) on legacy, DiscoverResult (supportedVersions, ttlMs/cacheScope)
on modern. Code that should work against both lifecycles can use the era-independent readers instead:
client.protocol_version # negotiated or adopted version, either lifecycle
client.server_capabilities # capabilities Hash, either lifecycle
client.instructions # instructions text, either lifecycle
client.server_implementation # server name/version; nil when a modern server does not identify itself
Troubleshooting: if server_info["protocolVersion"] starts returning nil after a server you connect to was upgraded,
the server now serves the modern lifecycle and the automatic negotiation adopted it.
Pass mode: :legacy for an immediate return to the previous behavior, or switch to the readers above for a permanent fix.
Explicit Discovery
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 page
for the wire shapes.
result = client.discover
result.supported_versions # => ["2026-07-28"]