MCP architecture: hosts, clients, servers, tools, resources, prompts, and transports
A detailed walkthrough of the MCP client-server architecture: how hosts embed clients, how clients connect to servers, how tools and resources are exposed and invoked, how prompts standardise interactions, and how transports carry messages between components.
Why this subject matters
Understanding the MCP architecture is essential for building secure, reliable AI-tool integrations. The architecture defines clear boundaries between components — hosts, clients, and servers — each with distinct responsibilities.
Current status
The architecture has been stable since the initial specification. Transport support has expanded from stdio-only to include HTTP with Server-Sent Events (SSE) and experimental WebSocket support.
Core concepts
- Host process
- The application that the user interacts with — Claude Desktop, VS Code, a web app. The host creates and manages client instances. One host can connect to many servers.
- Client-server connection
- Each client maintains exactly one connection to one server. The connection is established when the client starts and terminates when the client disconnects or the server process exits.
- Capability negotiation
- At connection time, client and server exchange capability declarations. This tells each side what features the other supports. Unknown capabilities are silently ignored for forward compatibility.
- Tool invocation lifecycle
- 1. Server declares available tools at connection. 2. Model decides to invoke a tool. 3. Host sends tool call request through client to server. 4. Server executes the tool. 5. Server returns structured result. 6. Result is added to model context.
- Resource subscription model
- The host can subscribe to resources that change over time. When a subscribed resource changes, the server sends an update notification.
Implementation options
Stdio transport
HTTP + SSE transport
Streamable HTTP (experimental)
Comparisons
| Aspect | Option A | Option B |
|---|---|---|
| Direction of control | Tools: model decides when to call | Resources: host decides what to inject |
| Latency model | Tools: synchronous request-response | Resources: pre-fetched or subscribed (async updates) |
| Transport | Stdio: local, process-level security | HTTP+SSE: remote, requires TLS and auth |
Timeline / Significant changes
Claims and Evidence
Each MCP client maintains exactly one connection to one server.
Capability negotiation ensures forward compatibility — unknown capabilities are silently ignored.
MCP's architecture draws heavily from the Language Server Protocol (LSP) design pattern.
Open questions / Disputed areas
- Will streamable HTTP replace SSE as the recommended remote transport?
- How should large binary resources be handled over JSON-RPC?