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

Flashcard·Easy·4.0 · 0·~30s·Asked atCrewai Pinterest Runway·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.

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

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

The MCP client is one of the three roles in the Model Context Protocol, alongside the host and the server. It is also the role most likely to be misunderstood, because it is not something the user installs or sees in the UI. The client is the protocol plumbing inside the host application.

This deep dive answers both parts of the question: where the client lives (inside the host, as a library) and why it is one to one with a server (isolation, simplicity, adoption speed). By the end you should be able to point at any MCP integration and identify which code is the client and which is the host.

Where the client lives: inside the host, as a library

Every working MCP integration has a host application. Claude Desktop is a host. Cursor is a host. Zed is a host. Claude Code is a host. The OpenAI Agents SDK with its MCP adapter is a host. Google Gemini CLI is a host. Each of these embeds one or more MCP clients inside its own process.

The client is implemented as a library the host imports. In TypeScript, you import @modelcontextprotocol/sdk. In Python, you import mcp. In Kotlin, Swift, Java, Rust, or C#, you use the corresponding official SDK. The host instantiates a client object, connects it to a server, and uses it for the life of the connection.

From the user's perspective, there is no visible artifact called 'the client.' You open Claude Desktop, you configure some servers, and the app talks to them. Internally, the host creates one client per server, and each client handles the protocol mechanics for that connection. The client is invisible to the user and that is by design.

The one to one cardinality with servers

What the client does mechanically

Where the client ends and the host begins

Why the one to one design became standard

Situations where this technique stops working.

2–4 min · Everything important, quickly.

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.

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?

Isolation. A crashed or misbehaving server only takes down its own client connection, not every integration in the host. It also keeps the protocol simple: no multiplexing, no fan-out logic, no shared request-ID space. The host pays a small cost in object count for a big simplicity win.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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 bullets to scan on the way to the call.

Define the MCP client using the in-process and one to one properties.
Explain what the client does during the initialize handshake.

Primary sources. Browse if you want the original framing.