Host vs Client vs Server: The Distinction That Must Be Precise

Recall Module 2’s own closing promise — this distinction deserves its own, dedicated module, because it’s genuinely the single most common source of confusion for anyone new to MCP. Let’s make it precise with two, real, concrete examples, rather than abstract definitions alone.

Example 1: a local, real filesystem connection

Let’s trace a genuine, real scenario — a desktop AI application reading files from your own computer.

flowchart LR
    A[Claude Desktop] --> B[Host]
    B --> C[MCP Client]
    C --> D[Filesystem MCP Server]
    D --> E[Local Files]

Here, Claude Desktop is the Host — the actual application you opened, the one with the real chat window. The MCP Client is a real, internal component living inside Claude Desktop, specifically responsible for maintaining the live connection to the Filesystem Server. The Filesystem MCP Server is a genuinely separate program, often running as its own real, local process, whose only job is exposing safe, real access to your files.

Example 2: a remote, real GitHub connection

Let’s trace a genuinely different, real scenario now — an enterprise agent platform reaching a remote service over the network.

flowchart LR
    A[Enterprise Agent Platform] --> B[Host]
    B --> C[MCP Client]
    C --> D[GitHub MCP Server]
    D --> E[GitHub API]

The real, structural roles are identical, even though the actual system looks completely different. The Agent Platform is the Host. An MCP Client, again living inside it, maintains a connection — this time genuinely over a network, not a local process. The GitHub MCP Server is real, separate infrastructure, potentially running on entirely different hardware, whose job is translating real MCP requests into real GitHub API calls.

The precise, real definition of each role

Host owns the real, actual AI application and user experience. It’s genuinely responsible for the chat interface, the model calls, and deciding which Servers to connect to at all.

Client maintains one real, live, stateful connection to exactly one Server. This is worth being precise about: a Client is not “the app” — it’s a real, specific, internal component whose entire job is this one connection’s lifecycle.

Server exposes real capabilities — Tools, Resources, Prompts — and does the actual, real work of reaching an external system. A Server genuinely has no idea who the end user is, or what application it’s connected to; it only ever sees requests from its one, connected Client.

The honest, important detail: one Host, many Clients

This is worth stating directly, since both examples above only showed one connection each.

flowchart TD
    H[Host] --> C1[MCP Client 1]
    H --> C2[MCP Client 2]
    H --> C3[MCP Client 3]
    C1 --> S1[GitHub Server]
    C2 --> S2[Database Server]
    C3 --> S3[Filesystem Server]

A single, real Host genuinely runs one real, separate Client instance per connected Server — recall Module 1’s own GitHub-plus-database-plus-filesystem example. This is precisely why a real assistant can search GitHub, query a database, and read local files all in the same real conversation: three genuinely separate Client-Server connections, coordinated by one Host.

Common mistakes worth avoiding

Referring to “the MCP connection” as if a Host only ever has one. Recall this module’s own real, multi-client diagram — a real Host genuinely manages one Client per Server, often several at once.

Assuming a Server knows anything about the end user. Recall this module’s own real definition — a Server only ever sees requests from its one, connected Client; user identity and permissions are the Host’s and Client’s real responsibility, covered fully once Module 14 reaches security.

Using “Host” and “Client” interchangeably in real conversation. Recall this module’s own precise distinction — the Host is the whole, real application; the Client is one, specific, internal connection-management component. Getting this precise now will save real confusion once you’re debugging a genuine, multi-server setup.

What you should take away from this module

• A Host is the real application; a Client is one real, internal connection-management component; a Server is real, separate infrastructure exposing capabilities.
• The exact same, real three-role structure applies whether the connection is local (a filesystem) or remote (GitHub over a network).
• A single, real Host genuinely runs multiple Clients at once, one per connected Server — this is precisely how a real assistant reaches several external systems in one conversation.

Where this goes next

The next module covers the MCP Lifecycle and Capability Negotiation — exactly what a Client and Server actually say to each other the moment a connection starts, before any real tool gets used.