MCP Server vs. Client vs. Host: What You Actually Build (and What You Don't)

If you've started reading about the Model Context Protocol (MCP) and gotten tangled in the words host, client, and server, you're not alone. The names sound interchangeable, they all show up in the same diagram, and most explanations assume you already know which is which. This article untangles them once and for all, with concrete examples, so you can stop guessing and start building the right thing.

TL;DR: The three MCP roles in one paragraph

In MCP, the host is the AI app the user already runs (Claude Desktop, Claude Code, Cursor) — it holds the LLM and orchestrates everything. The client is internal plumbing that lives inside the host: the host spawns exactly one client per server to maintain a 1:1 connection. The server is the program you write that exposes tools, resources, and prompts — a weather lookup, a GitHub connector, a notes store. As a developer, the only piece you build is the server. The host and client come from the AI vendor.

What is the Model Context Protocol (MCP)?

MCP is an open standard that lets AI applications connect to external tools and data in a consistent way. Instead of every AI app inventing its own plugin format, MCP defines a shared protocol so any compliant host can talk to any compliant server. Think of it like USB-C for AI tools: one connector spec, many devices.

The protocol defines three roles. Confusing them is the single most common reason developers stall before writing a line of code, so let's define each precisely.

What is an MCP host?

The host is the AI application the user runs. It contains (or connects to) the large language model and orchestrates the whole conversation — deciding when to call a tool, sending the request, and folding the result back into the model's answer.

Examples of MCP hosts:

• Claude Desktop — the desktop chat app.
• Claude Code — the command-line coding agent.
• Cursor — the AI code editor.

The key point for builders: you do not build the host. The user already has it installed. Your job is to give that host something useful to connect to.

What is an MCP client?

The client is a connector that lives inside the host. When a user adds a server, the host creates exactly one client dedicated to that server, and that client maintains the 1:1 connection over the MCP protocol — handling the handshake, message framing, and request/response traffic.

Here's the part that trips everyone up: the client is not a separate app, SDK, or download. You don't ship a client to your users, and your users don't install one. The host creates it automatically the moment a server is configured. It is pure internal plumbing.

Rule of thumb: One server connected means one client spun up inside the host. Three servers means three clients, all managed by the host, all invisible to you.

So when documentation says "the client sends a tools/call request," it means the host's internal connector did so on the model's behalf — not some piece of software you were supposed to write.

What is an MCP server?

The server is a program that exposes capabilities over MCP. Those capabilities come in three flavors:

• Tools — actions the model can invoke, like get_forecast or create_issue.
• Resources — data the model can read, like a file or a database record.
• Prompts — reusable prompt templates the host can offer the user.

A server can run two ways:

1. Locally, communicating over stdio (standard input/output) — common for tools that touch the user's own machine, like a filesystem server.
2. Remotely, over HTTP/SSE — common for hosted products and shared services.

This is the thing developers actually build. Examples:

• A weather server exposing a single get_forecast(city) tool that calls a weather API.
• A filesystem or notes server that reads and writes Markdown files on disk.
• A GitHub server with tools like list_repos, open_pr, and create_issue.
• A database server that runs read-only queries against your Postgres instance.

Notice the pattern: a server is a thin, well-described layer in front of something else — an API, a database, or a file store. MCP standardizes how the AI talks to your layer; what's behind it is ordinary code.

The three MCP roles at a glance

How the pieces connect: the request chain

Here is the full path a single tool call travels. Read it top to bottom:

User in Host (e.g. Claude Desktop)
        │
        ▼
Host's built-in MCP Client   ← created automatically, one per server
        │
        │  [ MCP protocol: stdio or HTTP/SSE ]
        ▼
Your MCP Server              ← the part you build
        │
        ▼
Whatever backs the server    ← an API, a database, a file store

Walked through with the weather example:

1. The user asks Claude Desktop (host), "What's the forecast in Chicago?"
2. The model decides it needs the get_forecast tool and tells the host.
3. The host's internal client for your weather server sends a tools/call request over MCP.
4. Your server receives it, calls the weather API, and returns the forecast.
5. The host feeds the result back to the model, which writes the final answer.

You wrote step 4. Everything else came from the vendor's host.

The biggest misconception: "Do I build the client?"

No. This is worth repeating because it derails so many people. The client is not an SDK you import into your product, not an app your users download, and not something you deploy. It is spawned by the host automatically when a server is added to its config.

When you read MCP SDK docs, you'll notice they include "client" libraries too. Those exist for people building a host (or testing a server). If you're building a product on top of MCP, you can ignore them. You build the server. Full stop.

Where does "the app" fit? Two very different apps

"App" is the word that quietly causes the most confusion, because there are two of them and they live in different worlds.

App #1 — the AI app the user runs. This is the host (Claude Desktop, Cursor, etc.). You don't build it.

App #2 — your own product's web app. If you're building a product on MCP, you almost always also have a normal SaaS web app: a marketing page, signup, a dashboard, billing, and a "Connect" page that hands the user a server URL and an access token. This web app has nothing to do with MCP. It's plain HTTP, plain auth, plain frontend code.

MCP only enters the picture at one specific moment: when the user takes the URL/token from your web app and pastes it into their host to connect. Before and after that, your web app is just a web app.

Concrete example: a hosted notes/Markdown store

Imagine you sell a hosted Markdown notes service that an AI can read and write.

• Your web app (notes.example.com): users sign up, pick a plan, pay, and land on a dashboard. On a "Connect to your AI" page, they copy a personal server URL and token. This is 100% normal SaaS — no MCP involved.
• Your MCP server (a separate endpoint): exposes tools like list_notes, read_note, and write_note, backed by your notes database. This is the MCP piece.
• The user's host (their AI app): they paste the URL/token in, the host spins up a client for your server, and now their AI can manage their notes.

Same product, two distinct surfaces. The website earns the signup; the server does the MCP work. Keeping them mentally separate is the unlock.

So what do you actually build?

For an MCP-based product, your build list is short:

1. Your MCP server — the tools (and the API, database, or file store behind them). Required.
2. A normal web app around it — signup, dashboard, billing, the connect page. Optional, but typical for a real product.

That's it. The host and the client come from the AI vendor and cost you zero engineering. If you're just exposing a tool for your own use (say, that weather server), you can skip the web app entirely and run the server locally over stdio.

Frequently asked questions

Do I build the MCP client?

No. The host creates the client automatically — one per connected server. It's internal plumbing, not an app or SDK you ship. You only build the server.

Is an MCP server local or remote?

Either. Local servers communicate over stdio and are great for accessing the user's own machine (files, local tools). Remote servers run over HTTP/SSE and suit hosted, multi-user products. The protocol is the same; only the transport differs.

Where does my web app fit into MCP?

Outside it, mostly. Your product's web app (signup, dashboard, billing, the connect page) is ordinary SaaS with no MCP in it. MCP appears only when the user connects their host to your server using a URL/token your web app provides.

What's the difference between the host and the client?

The host is the whole AI application (it runs the model and decides when to call tools). The client is a small connector inside that host, dedicated to one server. One host can manage many clients — one for each server it's connected to.

Can one host connect to multiple servers?

Yes. A host can connect to many servers at once, spinning up one client per server. That's how an AI app can use a GitHub server, a database server, and a notes server simultaneously.

The one-line summary

Host = the AI app the user runs. Client = its internal connector (auto-created). Server = the thing you build. Remember that, and the entire MCP architecture clicks into place.