Where does the MCP client live, and why is it one to one with a server?

Flashcard·Easy·4.0 · 0·~30s·Relevant atAnthropic Block Sourcegraph Zed

Attempt it

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).

Your answer

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.

Memory aid

Easy to grasp

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.

Key concepts

MCP Client Host Application JSON-RPC 2.0 MCP Server

Detailed answer & concept explanation

~5 min read

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.

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.

Claude Desktop instantiates one client per server entry in its mcpServers config; five configured servers means five client objects running inside the Claude Desktop process.
Cursor 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.
Claude Code and the OpenAI Agents SDK both build on the official SDKs and aggregate tool catalogs across multiple connected server clients.
The Python `mcp` package on PyPI is the canonical client implementation; most Python-based agent runtimes import it directly rather than reimplementing the protocol.
Google 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?

QWhere does the LLM live relative to the client?

QHow does the client surface server capabilities back to the host?

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.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.