MCP Architecture: Hosts, Clients, Servers
Understand the three-layer architecture and how messages flow between each component.
MCP has a clean three-layer architecture. Understanding these three roles makes every design decision in the protocol click into place.
Host. The application the user interacts with directly, like Claude Desktop or Cursor. The host manages the LLM and spawns MCP clients as needed.
Client. Lives inside the host. Manages a one-to-one connection with a single MCP server. It translates between the model's tool calls and the MCP protocol messages.
Server. An independent process, local or remote, that exposes capabilities through the MCP protocol. Each server focuses on one domain: file system, database, external API, and so on.
All of this is just JSON-RPC 2.0 messages sent over a transport (stdio for local servers, HTTP/SSE for remote ones). There is no magic under the hood, just a request-response protocol with a fixed vocabulary of methods like `initialize`, `tools/list`, and `tools/call`. Step through the exact messages below.
This is the actual wire traffic for connecting to the hello-mcp-server from the companion repo and calling its one tool. Step through every message that crosses the client-server boundary.
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"clientInfo": { "name": "cursor", "version": "1.4.0" },
"capabilities": {}
}
}