modelcontextprotocol/ruby-sdk
Watch
1
0
Fork
You've already forked ruby-sdk
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ruby-sdk/docs/_client/index.md
Koichi ITO 7e507f2963 [Doc] Document the client's ping answers and the stdio request limit 
## Motivation and Context

The client answers server pings automatically, but the docs leave out where that applies and what the stdio transport
does with the other server-to-client requests.

The client Transports page now lists the automatic ping answer among the things the stdio transport handles,
and a note states that `ping` is the only server-to-client request answered there: a wire-level `elicitation/create`
or `sampling/createMessage` is ignored over stdio, so a server that sends one waits for an answer that never comes,
while the SEP-2322 `input_required` route works on every transport and keeps `on_elicitation` and `on_sampling` handlers
working over stdio. Without this note, the only trace of the limitation is a hung tool call.

The client Ping page now says that over HTTP a ping reaches the client only on a stream that is already open
and that the client never opens one to receive pings, so a server can only ping a client that has a stream open.
Registering `on_server_request("ping")` moves to the end of the section as the advanced option it is, together with
its side effect of opening the GET listening stream on `connect`.

The client overview mentions the automatic answer next to `MCP::Client#ping`,
and the server Ping page's Client Side section points at it.

## How Has This Been Tested?

Documentation only; the linked headings and pages exist.

## Breaking Changes

None.
2026-09-12 00:02:36 +09:00

2.4 KiB
Raw Blame History

layout title nav_order permalink redirect_from
default Overview 1 /client/
/building-clients.html
/building-clients/

Building an MCP Client

The MCP::Client class provides an interface for interacting with MCP servers.

This class supports:

  • Lifecycle negotiation and connection via MCP::Client#connect, adopting the modern lifecycle when the server serves it; see Lifecycle
  • Server discovery via the server/discover method (MCP::Client#discover); see Explicit Discovery
  • Liveness check via the ping method (MCP::Client#ping), and automatic answers to server pings; see Answering Server Pings
  • Tool listing via the tools/list method (MCP::Client#tools)
  • Tool invocation via the tools/call method (MCP::Client#call_tool)
  • Resource listing via the resources/list method (MCP::Client#resources)
  • Resource template listing via the resources/templates/list method (MCP::Client#resource_templates)
  • 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 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 Requests
  • Cancellation of in-flight requests via the cancellation: keyword; see Cancellation
  • Cursor-based page iteration on the list_* methods and whole-collection fetching with the max_pages guard; see Pagination
  • Automatic JSON-RPC 2.0 message formatting
  • UUID request ID generation

Clients are initialized with a transport layer instance that handles the low-level communication mechanics. Authorization is handled by the transport layer; see Authorization.

Tool Objects

The client provides a wrapper class for tools returned by the server:

  • MCP::Client::Tool - Represents a single tool with its metadata

This class provides easy access to tool properties like name, description, input schema, and output schema.