The MCP Architecture: What I Wish Someone Had Drawn on a Whiteboard for Me

A practical map of MCP architecture for developers who already know the acronym but keep mixing up host, client, and server.

The shortest explanation

The useful mental model is:

User -> Host app -> Client connection -> MCP server -> Tools / Resources / Prompts

If you remember one line, remember that one. The host is the app the user is sitting inside. The client is the layer the app uses to communicate with a single MCP server. The server exposes capabilities.

Who this is for

This article is for developers who have already skimmed the MCP docs, even installed one server, but still find themselves asking:

Is Claude Desktop the client or the host?

Does one host connect to one server or multiple servers?

Why do people refer to a client when the user doesn't see a client UI?

Core Terms

What these MCP words actually mean:

Host = the app you open (Claude Desktop, Cursor).
Client = the part inside the host that handles one specific server connection.
Server = the thing that exposes tools/resources/prompts (e.g. filesystem server).
Tool = something the AI can do: search, query, send a message.
Resource = something the AI can read but not change (documents, schemas).
Prompt = a pre-made instruction from the server (e.g. "analyse this codebase").

The role boundary that matters

The most common confusion is between the host and the server.

The host is not the machine.

The host is not the deployment target.

The host is the app the user is actively in.

If you're using Claude Desktop with a filesystem MCP server:

Claude Desktop is the host.

Claude Desktop creates a client connection.

The filesystem process is the server.

That separation sounds obvious once you've seen it in action. It is much less obvious if you've only read prose definitions.

One host, many clients, many servers

A single host can manage multiple client connections.

Example:

Claude Desktop
|- Client A -> Filesystem server
|- Client B -> Browser server
|- Client C -> Search server

You do not usually have one global client for everything. The cleaner mental model is one client connection per server.

Transport options

1. stdio

Recommendation: best default for local development.

The host launches the server as a subprocess and communicates over standard input/output.

Pros:

Simple local setup

No extra network layer

Good for quick testing

Easy to reason about on one machine

Cons:

Host needs to manage the process lifecycle

Logging mistakes can break protocol output

Environment mismatches are common

2. SSE / HTTP-style transports

Recommendation: Use when the server should live outside the host process model.

Pros:

Better for remote/shared services

Cleaner separation of deployment

Can fit existing service infrastructure

Cons:

More moving parts

Auth and network behaviour become first-order concerns

Debugging can get split between the app network and the service

Capability types

Tools

These do work. They are the reason most people care about MCP at all.

Examples:

query a database

browse a page

read a file

trigger a workflow

Resources

These expose data that can be retrieved in a structured way.

Examples:

documentation chunks

a project summary object

a shared config payload

Prompts

These expose reusable prompt material through the server.

This part of the spec exists and can be useful, but many teams still treat MCP as mostly tool exposure in current practice.

Minimal architecture example

User asks Claude to find a config file
-> Claude Desktop (host) decides a tool call is needed
-> Host uses its client connection to talk to the filesystem MCP server
-> Server returns matching files
-> Host renders the result back to the user

Methodology note

This explanation is based on practical local testing on macOS with Claude Desktop and common filesystem/browser-style MCP setups, not a theoretical walk-through of every part of the spec.

My take

Most architecture explainers make MCP sound more abstract than it is. It is basically a standardised way for an app to speak to tool-providing servers. The spec matters.