The MCP client lives inside the host application as an in-process library, not as a separate program. Each client object owns exactly one connection to one server. A host with three configured servers contains three client objects. The one to one design keeps the protocol simple (no multiplexing, no shared request-ID space) and isolates failures (a crashed server takes down only its own client connection, not the others).
The **MCP client** lives inside the host application as a library, not as a separate program you install or run.
When Claude Desktop, Cursor, or Claude Code connects to MCP servers, each host creates one client object per server. If you have configured the filesystem server, the GitHub server, and the Slack server, there are three client objects inside the host process. They share no state with each other.
Each client handles the protocol mechanics for its one server: it opens the transport (stdio for a local subprocess, streamable HTTP for a remote service), runs the `initialize` handshake to learn the server's capabilities, serializes outgoing JSON-RPC requests like `tools/list` and `tools/call`, parses responses, and surfaces the server's tool catalog back up to the host code.
The one to one design exists for two reasons. First, isolation: if the GitHub server crashes, only its client connection breaks. The filesystem and Slack connections keep working. Second, simplicity: with one client per server, there is no multiplexing, no shared request-ID space, and no fan-out logic to manage.
The host is the orchestrator above the clients. It aggregates tool catalogs from all connected clients into the single catalog it advertises to the model, decides which tools to expose, handles the UI, and drives the LLM inference. The client handles only the per-server protocol plumbing.
The **MCP client** is the in-process protocol layer inside a host application that owns exactly one connection to one MCP server. It is implemented as a library you import (from `@modelcontextprotocol/sdk` in TypeScript, `mcp` on PyPI in Python, or equivalent SDKs in Kotlin, Swift, Java, Rust, and C#), not a separate process.
A host with three configured servers contains three client objects, each with its own transport, its own state, and its own capability set negotiated during initialize. The clients do not know about each other. Each one only sees its single server's world.
The one to one cardinality is deliberate. It keeps the protocol simple: no multiplexing, no fan-out logic, no shared request-ID space across servers. It isolates failures: a crashed server takes down only its own client connection, leaving the other integrations intact. And it makes the protocol cheap to implement, which is why every major AI host added MCP support within roughly twelve months of its announcement.
Mechanically, each client does five things: opens the transport, runs the initialize handshake, serializes and parses JSON-RPC messages, dispatches notifications (like `notifications/tools/list_changed`) to the host, and manages disconnects.
The responsibility split with the host is sharp. The client owns the protocol plumbing for one server. The host owns everything that crosses a server boundary: which servers to configure, how to merge tool catalogs across clients, which tools to expose to the model, how to render tool calls in the UI, and how to drive the LLM inference loop.
Quick reference
TL;DR
The MCP client is an in-process library inside the host application, one per server, owning the JSON-RPC connection and surfacing server capabilities back to the host.
Imagine your AI app is a building with many phone lines. Each phone line goes to a different outside service: one to GitHub, one to your files, one to Slack. The phones are wired into the building's walls, not separate gadgets you carry around. Each phone follows the same dialing rules, but each one connects to only one outside service.
That phone is an MCP client. There is one per connected service, and they all live inside the same building (the app). The building manager (the host) decides which services to call and what to do with the answers. The phones just handle the connection.
This setup means if one outside service goes down, only its phone line breaks. The other lines keep working. And the dialing protocol stays simple because each phone talks to exactly one service.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Writing a one-shot script that calls a single tool over a private API. Importing an MCP client SDK to reach one tool is overkill. A direct HTTP or library call is simpler when there is no ecosystem benefit to the protocol layer.
Building an orchestrator that needs to multiplex across servers without acting as an LLM host. MCP clients are designed for use inside hosts that drive an LLM. A pure server to server bridge is better served by a custom proxy.
Constructing a custom transport that does not fit stdio or streamable HTTP. Official client SDKs assume the standard transports. Exotic transports require extending the SDK or reimplementing JSON-RPC yourself, removing most of the convenience.
Quick scan · 2–4 min
Everything important, quickly.
5 min: state the one-sentence definition with both properties (in-process, one to one), explain the cardinality with a concrete example (three servers = three clients), walk the five mechanical responsibilities, distinguish client from host on the responsibility axis, and close with the isolation and simplicity rationale.
Real-world examples
Real products, models, and research that use this idea.
1Claude Desktop instantiates one client per server entry in its mcpServers config; five configured servers means five client objects running inside the Claude Desktop process.
2Cursor uses the TypeScript SDK to embed MCP clients; the editor process imports `@modelcontextprotocol/sdk` and creates a new client for each server it connects to.
3Claude Code and the OpenAI Agents SDK both build on the official SDKs and aggregate tool catalogs across multiple connected server clients.
4The Python `mcp` package on PyPI is the canonical client implementation; most Python-based agent runtimes import it directly rather than reimplementing the protocol.
5Google Gemini CLI added native MCP client support in 2026, demonstrating the client role is portable across vendor stacks.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy one client per server instead of one client multiplexing across many?
Sign in or go Pro to see the approach for this follow-up.
QWhere does the LLM live relative to the client?
Sign in or go Pro to see the approach for this follow-up.
QHow does the client surface server capabilities back to the host?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Calling the client a separate application. It is a library inside the host, instantiated once per connected server. Three servers mean three client objects inside the same host process.