MCP Architecture: Hosts, Clients & Servers
The three roles and the message flow that let a model discover and call your tools.
MCP has a clean architecture built from three roles — host, client, and server — talking over well-defined transports. Understanding this model makes building and debugging MCP integrations straightforward.
🎯 Learning Objectives
- Understand the host, client, and server roles
- Know the transports MCP uses (stdio and HTTP/SSE)
- Follow the connection lifecycle and message flow
- Understand capability discovery
The Three Roles
| Role | What it is | Example |
|---|---|---|
| Host | The AI application the user interacts with; contains the model | An AI IDE, a chat assistant, a desktop app |
| Client | A connector inside the host, one per server, that speaks MCP | The host’s MCP client for the GitHub server |
| Server | An external program exposing tools/resources/prompts | A GitHub server, a Postgres server |
The relationship: one host runs one or more clients, and each client maintains a dedicated 1:1 connection to one server.
┌───────────────── Host (AI app) ─────────────────┐
│ Model │
│ │ │
│ ┌─┴───────┐ ┌──────────┐ ┌──────────┐ │
│ │ Client A │ │ Client B │ │ Client C │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
└────────┼──────────────┼──────────────┼───────────┘
▼ ▼ ▼
GitHub server Postgres server Files server💡 Why one client per server?
Each client-server pair is an isolated, stateful session. This keeps servers independent — one crashing or misbehaving doesn’t affect the others — and lets the host manage permissions per connection.
Transports
MCP messages (JSON-RPC 2.0) travel over one of two main transports:
| Transport | Use case | How |
|---|---|---|
| stdio | Local server on the same machine | Host launches the server as a subprocess; they exchange messages over stdin/stdout |
| Streamable HTTP (with SSE) | Remote server over a network | HTTP requests plus server-sent events for streaming responses |
Local developer tools usually use stdio (simple, no network); hosted/shared servers use HTTP.
The Connection Lifecycle
A client and server go through a defined handshake before any tools are called:
1. initialize client ▶ server "here's my protocol version + capabilities"
2. initialize server ▶ client "here's mine"
3. initialized client ▶ server "ready"
── now the session is live ──
4. tools/list client ▶ server "what tools do you have?"
5. tools/call client ▶ server "run create_issue with these args"
6. (result) server ▶ client "here's the result"Step 4 is capability discovery — the client asks the server what it offers, so the model can be told which tools are available without hardcoding anything.
What a Tool Definition Looks Like
When the client calls tools/list, the server returns each tool’s name, description, and an input schema. The description and schema are what the model reads to decide when and how to call it:
{
"name": "create_issue",
"description": "Create a new issue in a GitHub repository",
"inputSchema": {
"type": "object",
"properties": {
"repo": { "type": "string", "description": "owner/name" },
"title": { "type": "string" },
"body": { "type": "string" }
},
"required": ["repo", "title"]
}
}⚠ Descriptions are the model's instructions
The model chooses tools based on their names and descriptions. Vague descriptions lead to misuse; clear, specific ones (“Create a GitHub issue; use only when the user asks to file a bug”) make the model reliable. Treat tool descriptions as prompt engineering.
A Full Message Flow
Putting it together, when a user asks the assistant to “file a bug about the login crash”:
User ▶ Host: "file a bug about the login crash"
Host ▶ Model: prompt + available tools (from tools/list)
Model ▶ Host: "call create_issue(repo=acme/app, title=Login crash)"
Host ▶ Client ▶ Server: tools/call create_issue {...}
Server ▶ GitHub API: creates the issue
Server ▶ Client ▶ Host: { url: "https://github.com/.../issues/42" }
Host ▶ Model ▶ User: "Done — filed issue #42."The model decides what to do; the host mediates and enforces permissions; the server does the actual work.
🧪 Hands-on Lab
Map the Roles
In this setup, name the host, the client(s), and the server(s): “An AI coding assistant connects to a local filesystem server (launched as a subprocess) and a remote Jira server over HTTP.”
🧠 Knowledge Check
What is the relationship between MCP clients and servers?
What does the tools/list step accomplish?
💼 Interview Preparation
Explain the MCP architecture and why it separates host, client, and server.
Summary
You now understand MCP’s host-client-server model, its transports, the connection lifecycle, and capability discovery. With the architecture clear, let’s build one: next you’ll create your first MCP server exposing a tool.