The three-layer MCP architecture
MCP uses a clean separation of concerns with three key roles. Think of it like a restaurant: the customer (Host) orders from a menu (Client), which sends the order to the kitchen (Server).
The three roles
🏠 MCP Host
The application that wants to use tools and data. Examples: Claude Desktop, Claude Code, a custom Python chatbot, a web app. The Host says "I want to use tools like search, or read files, or query a database." If you are weighing Claude Code against VSCode-style assistants such as Cursor, see Claude Code vs Cursor AI (2026).
🔌 MCP Client
The protocol layer that runs inside the Host. It knows how to speak MCP — how to list available tools, how to call them, how to handle results. You rarely interact with the Client directly.
🛠️ MCP Server
The bridge to the actual resource or tool. It exposes tools, resources, and prompts that the model can use. Examples: a file system server, a GitHub server, a database server. The Server says "here are the tools I can provide."
How they work together
The flow is straightforward:
Host connects to Server — Claude Desktop loads your config file and starts MCP servers.
Client gets the tool list — The Client asks the Server "what tools do you have?" and gets back descriptions.
Host shows tools to AI model — The Host tells Claude "here are the available tools" and includes their descriptions.
Model calls a tool — Claude decides to use a tool and sends a request back to the Host.
Host passes request to Client → Server — The request flows through the Client layer to the Server.
Server executes and returns result — The Server runs the tool and sends back the result.
Result flows back to model — Host shows Claude the result, and the loop continues.
Transport: How they communicate
MCP servers can communicate via two transport methods:
stdio (standard I/O)
Server runs locally as a subprocess. Host communicates via stdin/stdout. Simple, fast, great for development and local tools.
HTTP/SSE
Server runs as a web service. Host connects via HTTP. Better for remote servers or when you need to share a server across applications.
MCP vs alternatives
| REST API | Function Calling | MCP | |
|---|---|---|---|
| Standard | No — each API is custom | Per-LLM standard | Unified standard |
| Host responsibility | Write and maintain HTTP client | Integrate into LLM prompt/system | Load MCP server — everything else is automatic |
| Reusability | Only with custom wrappers | Tied to that LLM | Works with any MCP-compatible host |
| Resources & Prompts | Not a standard part | Not a standard part | First-class primitives |
Quick summary
- MCP has three layers: Host, Client, Server — each with a clear responsibility
- Communication can be via stdio (local) or HTTP (remote)
- MCP is the standard; REST APIs and function calling are the alternatives
- Next page: we'll explore the three things servers can expose — Tools, Resources, and Prompts