MCP architecture: hosts, clients, and servers
MCP is a client-server protocol with three roles. Getting these straight makes everything else easier to reason about.
The three roles #
- Host is the AI application the user interacts with: Claude Desktop, an IDE extension, or your own agent. It manages the model and the user experience.
- Client lives inside the host. Each client maintains one dedicated, stateful connection to one server. A host with three servers runs three clients.
- Server is a program that exposes capabilities (tools, resources, prompts) over MCP. It wraps a service, a database, a filesystem, or an API.
How they relate #
A host spins up a client per server. The client and server perform a handshake, negotiate what each supports, and then exchange messages for the life of the connection. The model never talks to a server directly, the host mediates: it presents the server's tools to the model, and when the model chooses one, the host routes the call through the client.
textHost application (e.g. Claude Desktop)
|
|-- MCP client <-----> MCP server (filesystem)
|-- MCP client <-----> MCP server (GitHub)
|-- MCP client <-----> MCP server (Postgres)
Why one client per server #
Each connection is isolated and stateful. Keeping one client per server means a misbehaving or slow server cannot corrupt another's session, capabilities are negotiated independently, and the host can grant or revoke servers individually. It is the same isolation principle that makes the model safer to run against many tools at once.
Resources & further reading
- MCP specification MCPThe authoritative protocol spec: messages, capabilities, transports, and lifecycle.
- modelcontextprotocol.io MCPThe official Model Context Protocol site: concepts, quickstarts, and client list.