MCP Client

What it is

The consuming half of a Model Context Protocol connection: the component inside a host application that opens a transport to a server, negotiates protocol version and capabilities during initialisation, enumerates what that server offers, invokes it, and keeps the connection alive for as long as the session needs it. A single host usually runs several of these at once and has to present their combined offerings to one model as a single coherent surface.

Why it matters

The client is where somebody else's software gets a say in what your model sees. Server- supplied names and descriptions are read by the model as instructions about what to do; a server's latency becomes your turn latency; a server's crash becomes your session's missing capability. All the connection-level decisions that determine whether that goes well — when to connect, what to trust, how to merge, what to do when a surface changes mid-turn — live in the client and nowhere else.

Where a client's responsibility ends

The client consumes a surface it did not define. It does not decide what a tool should do or how coarse it should be, which belongs to whoever implemented the server, and it is not a shared mediation point for other applications, which is a separate deployment with its own identity and policy concerns. A client's scope is one host's connections: establishing them, keeping them honest, and turning what comes back into something the local model session can safely use.

Key decisions

• Which transports the host supports, and therefore which servers it can reach at all: a locally spawned child process speaking over its standard streams, or a remote HTTP endpoint with its own network, certificate, and authorisation requirements.
• When connections open. Connecting to every configured server at startup makes the first turn slow and couples launch to the slowest server; connecting lazily makes the first use of each server slow and complicates the offered-tool list.
• What happens when two connected servers advertise the same tool name. Prefixing by server is unambiguous and makes names longer and less readable for the model; first-wins is invisible and wrong.
• Whether server-supplied descriptions reach the model verbatim, are reviewed once and pinned locally, or are rewritten by the host. Verbatim is the default and the riskiest.
• Whether the host honours server-initiated requests — a server asking the client to run a model completion, or to put a question to the user — and under what approval those run.
• How a change notification is applied. Rebuilding the offered set mid-turn can invalidate a call the model has already emitted against the previous surface.
• How much of a server's offering to expose at all: an unfiltered pass-through, or a host-side allowlist that the user or administrator controls.

Failure modes

• A connected server rewrites its tool descriptions after the user approved it, and the model follows new instructions embedded there without anything re-prompting for consent.
• One slow server blocks initialisation and the whole session starts late, or starts without tools the user expected and gives no indication why.
• A locally spawned server process is orphaned when the host crashes, and copies accumulate until the machine runs out of file descriptors.
• The client caches the enumerated surface, the server restarts with a different set, and every call fails with an unknown-tool error until the session is restarted.
• Server output is streamed into context with no size ceiling, and a single oversized response evicts the conversation the user cared about.
• Two servers expose the same name, one is silently shadowed, and calls intended for a staging system reach production because its connection was registered first.
• The client assumes a capability the server never declared during initialisation, and the failure surfaces as a protocol error the model cannot interpret or recover from.
• Errors from the transport and errors from the tool are collapsed into one message, so the model retries a permanently invalid request as though the network had hiccupped.

Related capabilities

• MCP Server — the counterpart that defines the surface being consumed
• MCP Gateway — what a client connects to when many servers are mediated centrally
• MCP Authentication — how the connection proves who is calling
• Tool Discovery — what the client does with an enumerated surface
• Tool Result Normalization — turns heterogeneous server output into one shape

Applies: Production readiness · Design questions