In MCP, what are the host, the client, and the server, and how do they relate?
answer
- three roles, one connector each
- the app the user runs is the host
- five servers means five connectors
- servers never see each other
- connections are plumbing, not memory
basics
~10 sThe host is the AI application the user runs. Inside it, one client per server speaks the protocol. Each server exposes one integration's tools, resources and prompts. Clients never talk to each other.
solid answer
~40 sThe **host** is the AI application — it holds the model, the user, and the UI. For every MCP server it wants to use, the host instantiates one **client**: a connector that speaks JSON-RPC to exactly that server over stdio or Streamable HTTP. The **server** is a separate program or remote service that exposes one integration's capabilities as MCP primitives — `tools/list` and `tools/call`, `resources/list` and `resources/read`, `prompts/list` and `prompts/get`, plus `server/discover`. A host wired to five servers runs five clients; each pairing has its own transport, its own authorization and its own trust decision, and a server sees only the requests its own client sends. Under revision 2026-07-28 none of those links is a session: each request is self-contained and carries its own protocol version and capabilities in `params._meta`.
go deeper
Be able to name the three roles in one breath: host is the app with the model and the user, client is the per-server connector inside it, server is the separate program exposing tools, resources and prompts.
Explain the one-client-per-server rule and what it implies — the host aggregates, servers cannot see each other, and the client always initiates. Mention that each request carries its own version and capabilities rather than inheriting them from a handshake.
Show you can place responsibilities correctly when designing a real integration: which failures are contained to one client, why a server must work for any host, and why nothing may depend on connection-scoped memory in revision 2026-07-28.
Own the framing that a server is a reusable capability boundary, not a plugin for one product, and that the host is the only place with the conversation, the user and cross-server context — which decides what may live where.
## The three roles MCP names three participants, and interviews start by checking that you can keep them straight. The **host** is the AI application a person actually uses — a desktop assistant, an IDE agent, a chat product, a backend agent runner. The host is where the language model lives, where the user is, and where any approval prompt is shown. It is also the only participant with a view of the whole picture: the conversation, the user's identity, and every server the application is wired to. The **client** is a protocol connector living inside the host. It is not a separate product; it is the component that opens a transport to one server, sends JSON-RPC requests, and hands results back to the host. A client is a thin, faithful speaker of the protocol. The **server** is a separate program (a local subprocess on stdio) or a remote service (an HTTP endpoint) that wraps exactly one integration — a ticket tracker, a database, a filesystem area, an internal API — and publishes what it can do as MCP primitives. It is written once and is meant to work with any conforming host. ## One client per server The pairing is one-to-one: a host that uses five servers instantiates five clients. There is no multiplexing client that fans out to several servers, and there is no server-to-server link. Everything a server can influence, it influences by answering the requests its own client sends. Aggregation — showing the model a single merged list of tools drawn from several servers, and routing a chosen call back to the right connector — happens above the clients, in the host. That shape has a direct consequence people often get wrong: an MCP server cannot read the conversation, cannot see the user's screen, and cannot see or call another server. It sees a stream of requests and whatever those requests carry. ## What travels between them Requests are ordinary JSON-RPC 2.0 messages. The server-side surface is small and fixed: `server/discover` (which servers MUST implement and clients MAY call) reports `supportedVersions`, `capabilities` and optional `instructions`; `tools/list` and `tools/call` cover executable actions; `resources/list`, `resources/read` and `resources/templates/list` cover readable data; `prompts/list` and `prompts/get` cover reusable prompt templates; `completion/complete` supplies argument autocompletion. Long-lived server→client change notifications flow only on a `subscriptions/listen` stream the client opted into. Every request carries `params._meta`, which under revision 2026-07-28 must include `io.modelcontextprotocol/protocolVersion` and `io.modelcontextprotocol/clientCapabilities` (an empty object is legal). `io.modelcontextprotocol/clientInfo` is optional and, like `io.modelcontextprotocol/serverInfo` on results, is self-reported and explicitly untrusted — it is a label for logs and UI, never an authentication or authorization signal. ## Direction of initiation The client always initiates. On stdio the client spawns the server process and writes newline-delimited JSON-RPC to its stdin; on Streamable HTTP the client POSTs to the server's single endpoint. Revision 2026-07-28 removed server-initiated JSON-RPC requests entirely — there is no `ServerRequest` union any more. When a server needs something from the user or the client (a form, a directory list, a model completion), it does not call back: it returns an `InputRequiredResult` with `resultType: "input_required"`, and the client decides whether to fulfil it and retry the original request with a new JSON-RPC id. ## No sessions anywhere in the picture The 2026-07-28 revision states plainly that MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities, and an open connection — including a running stdio process — is not a conversation or a session. The earlier `initialize` / `notifications/initialized` handshake and the `Mcp-Session-Id` header were removed in that revision. So the topology is three roles joined by connections that are transport plumbing, not memory. ## Where the model sits The model belongs to the host. This was already the normal arrangement, and 2026-07-28 sharpened it by deprecating **sampling** — the mechanism by which a server could ask the client to run a model completion — with the stated migration being for servers to integrate directly with LLM provider APIs. Deprecated features stay in the spec at least twelve months, so sampling is still described, but new servers should not design around borrowing the host's model. ## The confusions to avoid Do not call the server "the app" — the host is the app. Do not describe one client managing many servers. Do not imagine servers discovering each other. And do not treat a live connection as a place where context accumulates: in this revision, context is whatever the current request carries.
- If a host is wired to five servers, can one of them enumerate another's tools?No. Each server is reached by its own client, and the protocol gives a server no channel to another server and no view of the host's other connections. Merging tool lists happens in the host, above the clients. A server sees only the requests its own client sends it, plus whatever those requests carry in their arguments and `_meta`.
- Which side opens the connection, and can a server ever call the client first?The client always initiates: it spawns the subprocess on stdio or POSTs to the endpoint on Streamable HTTP. Revision 2026-07-28 removed server-initiated JSON-RPC requests altogether. A server that needs input returns an `InputRequiredResult` with `resultType: "input_required"`, and the client fulfils it and retries the original request with a new id.
- Where does the language model live in this topology, and did that change in 2026-07-28?The model belongs to the host; servers have no model of their own. The change is that sampling — a server asking the client to run a completion — was deprecated in 2026-07-28, with the stated migration being that servers integrate directly with LLM provider APIs. It remains in the spec for at least twelve months, but new servers should not be designed around borrowing the host's model.
Think of the host as an office with a row of separate phone lines. Each line reaches exactly one outside service, the office hears every line, and no line can hear another.
saying these in an interview costs you the question
- Calling the MCP server the application the user runs
- Describing one client multiplexing connections to several servers
- Claiming a server can read the conversation or the user's screen
- Saying servers discover and call one another directly
- Treating a running stdio process as a session that holds context