## 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.
47 lines
2.4 KiB
Markdown
47 lines
2.4 KiB
Markdown
---
|
|
layout: default
|
|
title: Overview
|
|
nav_order: 1
|
|
permalink: /client/
|
|
redirect_from:
|
|
- /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](/client/lifecycle/)
|
|
- Server discovery via the `server/discover` method (`MCP::Client#discover`); see [Explicit Discovery](/client/lifecycle/#explicit-discovery)
|
|
- Liveness check via the `ping` method (`MCP::Client#ping`), and automatic answers to server pings;
|
|
see [Answering Server Pings](/client/ping/#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](/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 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/)
|
|
- Automatic JSON-RPC 2.0 message formatting
|
|
- UUID request ID generation
|
|
|
|
Clients are initialized with a [transport layer](/client/transports/) instance that handles the low-level communication mechanics.
|
|
Authorization is handled by the transport layer; see [Authorization](/client/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.
|