MCP Client vs Server vs Host: Roles Explained

If you've read about MCP, you've probably seen the terms "host," "client," and "server" used somewhat interchangeably — or seen Claude Desktop called both a "host" and an "MCP client" in the same breath. Neither use is wrong, but the loose terminology hides a precise architectural distinction that matters enormously when you're building, debugging, or securing MCP integrations. Here's what each role actually means, which software plays each role, and why the distinction is worth understanding.

The Source of the Confusion

In traditional client-server software, there are two roles: client (initiates requests) and server (responds to them). MCP introduces a third role — the host — that sits above the client. This trips people up because "host" and "client" are often collapsed into a single application like Claude Desktop.

Here's the key: when someone says "Claude Desktop is an MCP client," they're using shorthand. What they mean is "Claude Desktop contains MCP clients." The distinction matters as soon as you have multiple MCP servers connected simultaneously — which is the normal case in production use.

The Host: The Application You Actually Run

The host is the user-facing application. It's the thing you install, launch, and interact with. Claude Desktop is a host. Cursor is a host. Zed is a host. Any AI coding tool or chat interface that supports MCP is functioning as a host.

The host's responsibilities include:

• User interface — showing the chat window, rendering tool call outputs, displaying consent dialogs.
• AI model integration — connecting to the underlying language model (Claude, in Claude Desktop's case) and passing tool results back to it.
• MCP client lifecycle — starting, stopping, and managing the individual MCP client components that connect to each server.
• User consent enforcement — deciding which tool calls require user approval before execution, and showing those prompts.
• Configuration — reading the claude_desktop_config.json (or equivalent) to know which servers to connect to and with what arguments.

The host is the policy layer. It's where decisions like "should this tool call be auto-approved?" and "which servers is this user allowed to connect to?" are made. Servers don't make these decisions — they just respond to requests.

The Client: One Per Server Connection

Inside the host, for every MCP server that's connected, there is exactly one MCP client managing that connection. If Claude Desktop is connected to your filesystem server, your GitHub server, and a web search server simultaneously, it's running three separate MCP clients internally — one for each server.

The client's responsibilities are narrow and focused:

• Transport management — opening and maintaining the connection (stdio pipe, HTTP stream, or WebSocket, depending on the server type).
• Protocol handling — sending JSON-RPC messages, receiving responses, matching responses to their requests by ID.
• Capability tracking — remembering what tools, resources, and prompts this specific server advertised during the initialize handshake.
• Session state — managing the lifecycle of this one connection from initialization to shutdown.

A client knows nothing about other clients. Client A (connected to the filesystem server) has no idea Client B (connected to GitHub) even exists. Isolation is by design — servers shouldn't be able to observe or interfere with each other's connections.

The Server: The External Process That Provides Capabilities

The server is what most people in the MCP community are actually building. An MCP server is an external process — or a remote HTTP endpoint — that exposes tools, resources, and prompts. It runs independently of the host and communicates only with the single client that's connected to it.

Servers don't initiate connections. They wait. When a client connects (for stdio servers, this means the server process was started by the host and is waiting on stdin), the server participates in the initialize handshake, advertises its capabilities, and then processes requests as they arrive.

Well-known MCP servers include:

• @modelcontextprotocol/server-filesystem — exposes file read/write tools
• @modelcontextprotocol/server-github — exposes GitHub API tools
• mcp-server-postgres — exposes database query tools
• @modelcontextprotocol/server-brave-search — exposes web search tools

Each of these is a server. None of them is a client or a host. If you're writing integration code that adds capabilities to Claude, you're almost certainly writing a server.

How the Three Roles Work Together

Here's the complete picture of a typical MCP session:

HOST (Claude Desktop)
│
├── MCP Client A ──── stdio ──── MCP Server: filesystem
│   (manages one connection)     (exposes: read_file, write_file, list_dir)
│
├── MCP Client B ──── stdio ──── MCP Server: github
│   (manages one connection)     (exposes: create_issue, list_prs, merge_pr)
│
└── MCP Client C ──── HTTP  ──── MCP Server: web-search (remote)
    (manages one connection)     (exposes: search, fetch_page)

When you ask Claude in Claude Desktop to "create a GitHub issue for the bug I just found in README.md," here's what actually happens:

1. Claude (the AI model, running inside the host) decides it needs to call two tools: read_file and create_issue.
2. The host routes the read_file call through Client A to the filesystem server.
3. Client A sends a tools/call JSON-RPC request to the filesystem server and gets back the file contents.
4. The host passes the file contents back to Claude.
5. The host routes the create_issue call through Client B to the GitHub server.
6. Client B sends a tools/call JSON-RPC request to the GitHub server and gets back the new issue URL.
7. The host passes the result back to Claude, which incorporates it into its response to you.

At no point do the filesystem server and the GitHub server know about each other. Clients A and B are completely independent. The host is the only component that has the full picture.

Why This Distinction Matters for Security

The three-role architecture isn't just organizational — it directly shapes the security model. Understanding MCP security trust levels starts here.

The host is the trust anchor. It's the application the user installed and trusts. When a server tries to do something potentially dangerous, the host decides whether to let it through — and shows the user a consent dialog if appropriate. Servers operate at a lower trust level than the host because they're third-party code running in a separate process.

The client isolation model means a compromised server can't directly affect other servers. If a malicious server sends unexpected data, only Client X sees it. Client Y and Client Z, connected to other servers, are unaffected. The blast radius of a bad server is contained to its own client connection.

This is also why the security risks in MCP servers are framed the way they are — the risks are mostly about what a malicious server can convince Claude (via the host) to do, not about servers directly attacking each other.

Common Misconceptions Cleared Up

"Claude is an MCP server." No — Claude is the AI model running inside the host. Claude doesn't expose tools; it uses them. MCP servers are what Claude calls into.

"I'm building an MCP client." Probably not. If you're adding a new integration — connecting Claude to your database, your Slack workspace, your internal API — you're building a server. You'd only be building a client if you were writing a new host application from scratch (a new AI chat app, a new code editor with AI features, etc.).

"The host and client are the same thing." In practice they're often in the same executable (Claude Desktop is one app that contains both host logic and client components), but they're architecturally distinct layers with different responsibilities. Knowing which layer does what saves you hours of confusion when something breaks.

"Remote MCP servers work differently." The host/client/server roles are the same regardless of transport. The difference between local and remote MCP servers is only in how the client connects — stdio for local processes, HTTP for remote endpoints. The role boundaries don't change.

Practical Implications for Builders

If you're building a new MCP integration today, you are almost certainly building a server. You write a process (Node.js, Python, Go, whatever you prefer) that listens for JSON-RPC requests over stdio or HTTP, handles tools/list and tools/call, and returns results. You don't write a client — the host (Claude Desktop, Cursor, etc.) provides the client for you.

If you're building a new AI application that you want to be MCP-compatible — something that lets users plug in MCP servers — then you're building a host, and you need to implement MCP clients internally. That's a significantly more complex undertaking. The MCP SDK for TypeScript and Python both include client implementations you can embed.

If you're just a user connecting existing servers to Claude Desktop, you don't need to think about this at all — the host handles everything. Configure your claude_desktop_config.json with the server commands, restart the app, and the host spins up the clients automatically.