MCP's official specification defines three distinct roles, and it's worth being precise about them since the terms get used loosely in casual conversation. A Host is the actual AI application. A Client is a connector living inside that host, one per connected server. A Server is the separate program actually exposing tools, resources, or prompts.
Learning Objectives
- Define Host, Client, and Server precisely, and how they relate to each other.
- Explain why a host uses a separate client per server connection.
- Read a real request/response exchange between a client and a server.
The Three Roles
| Role | What it actually is |
|---|---|
| Host | The AI application the user interacts with, an IDE assistant, a chat app |
| Client | A connector inside the host, managing one connection to one specific server |
| Server | A separate program exposing a specific set of tools, resources, or prompts |
Host
the AI application
Client
one per server
Server
exposes tools/data
A single host commonly runs multiple clients at once, one per connected server, a filesystem client, a GitHub client, and a Slack client all running inside the same host application simultaneously.
Why One Client Per Server, Not One Client for Everything
Each client-server pair negotiates its own connection independently, including which capabilities each side actually supports. Keeping connections separate means one server going down, or being added or removed, doesn't affect any other active connection.
What a Real Exchange Looks Like
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list"
}{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [
{ "name": "read_file", "description": "Read a file's contents" },
{ "name": "write_file", "description": "Write content to a file" }
]
}
}{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": { "name": "read_file", "arguments": { "path": "/logs/error.log" } }
}Every message follows the same JSON-RPC 2.0 shape regardless of which server it's talking to, or what the tool actually does internally. That consistency is what lets a host treat every connected server the same way at the protocol level.
Connection Lifecycle
Connect
Negotiate Capabilities
Discover Tools/Resources
Exchange Requests
Capability negotiation happens once, right after connecting, each side declares what it supports before any real request is sent, which is what lets a client and server with slightly different feature sets still work together correctly.
Common Beginner Mistakes
- Using "client" and "host" interchangeably, the host is the whole application; a client is one specific connection living inside it.
- Assuming one client can talk to multiple servers, each client manages exactly one server connection.
- Forgetting that capability negotiation happens before any real request, and skipping it in a custom implementation causes compatibility issues.
- Assuming every server exposes the same tools, always checking what's actually available (tools/list) rather than assuming.
FAQ
Can a single server be used by multiple different hosts at once?
Yes, a server doesn't know or care which specific host it's connected to, any MCP-compliant host can connect to it, each through its own client.
Is the connection between a client and server always local, on the same machine?
Not necessarily, MCP supports both local connections (a server running as a local process) and remote ones, depending on how the server is deployed and configured.
What happens if a client sends a request the server doesn't support?
Capability negotiation at connection time is meant to prevent this by declaring what each side supports upfront, but an unsupported request would typically receive a structured JSON-RPC error response rather than succeeding silently.
Interview Questions
Define Host, Client, and Server precisely, in MCP's terms.
The Host is the actual AI application the user interacts with. A Client is a connector living inside the host, managing one connection to one specific server. A Server is a separate program exposing tools, resources, or prompts.
Why does a host use a separate client per connected server, instead of one client managing all of them?
Each client-server pair negotiates its own connection and capabilities independently, so one server's connection issues or capability differences don't affect any other active connection.
What underlying message format does every MCP request and response use?
JSON-RPC 2.0, giving every tool call and response the same structured shape regardless of which server is involved or what the tool does internally.
What happens during capability negotiation, and when does it occur?
Right after a client and server connect, before any real request is sent, each side declares what features and capabilities it supports, which lets clients and servers with different feature sets still interoperate correctly.
Summary
MCP's architecture has three precise roles: the Host (the AI application), a Client (one per connected server, living inside the host), and a Server (exposing tools, resources, or prompts). Every exchange uses JSON-RPC 2.0, and a connection begins with capability negotiation before any real tool call happens.
What's Next?
The next lesson covers the three things a server can actually expose, tools, resources, and prompts, with a concrete example of each.