MCP: host, client, server and the primitives

Why it matters

Before a shared protocol, every AI application integrated every tool on its own, and each connector broke in its own way when the upstream API changed. With M applications and N tools the work is M times N. The Model Context Protocol turns that into M plus N: a tool is wrapped once as a server, and any application that speaks the protocol can discover and use it. Interviewers ask about MCP because it is now the common way an agent reaches data outside the model, and because candidates who have only clicked "add server" often cannot say which side runs what.

The idea

MCP is an open standard governed under the Linux Foundation's Agentic AI Foundation; the current spec version is 2026-07-28. On the wire it is JSON-RPC 2.0, split into a data layer that defines the messages and a transport layer that carries them.

Three participants

The host is the AI application: the chat client, the IDE, the agent runtime. It owns the model, the system prompt and the loop. For every server it uses it creates a client, one per connection, which speaks the protocol on its behalf. The server wraps something useful, a database, a file system, a ticketing system, and exposes it through a fixed set of primitives. The server never talks to the model; the host decides what the model sees.

Three server primitives

Take a server in front of an orders database.

Tools are actions the model may call: here, a query tool that runs a read-only SQL statement and returns rows. Tools are model-controlled: the host places their definitions in the model's tool list and the model decides when to call them. Everything the Designing a tool lesson says applies.

Resources are data the application attaches as context, addressed by URI: here, schema://orders, the table definitions. Resources are application-controlled and have no side effects.

Prompts are reusable templates the user invokes: here, a few-shot prompt showing the model how to write a safe aggregate query. Prompts are user-controlled.

Each primitive has a list method and a fetch method: tools/list and tools/call, resources/list and resources/read, prompts/list and prompts/get. A tools/list entry looks like this.

{
  "name": "query",
  "title": "Run a read-only query",
  "description": "Run one SELECT against the orders database. Do not use for writes.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": { "type": "string", "description": "e.g. SELECT count(*) FROM orders WHERE status = 'open'" }
    },
    "required": ["sql"]
  }
}

The client-side primitive is elicitation: the server asks the user, through the host, for input or a confirmation before it continues. Sampling, where a server asked the host to run the model, is deprecated, as is server-to-client logging.

Discovery and statelessness

The current protocol is stateless. Every request carries the protocol version and the caller's capabilities in a _meta field, so a server can answer any single message on its own; there is no session to initialise and lose. A client learns what a server offers with server/discover, which returns the server's capabilities and supported versions. Then list, then call: the host fetches the tool list, hands the definitions to the model, and when the model emits a tool-use block the client sends tools/call and returns the output as the tool result. If a server's offerings change, a client that has opted into a subscriptions/listen stream is notified; otherwise it lists again.

Transports

stdio runs the server as a local child process and talks over its standard input and output: no network, the user's own permissions, right for tools on a developer's machine. Streamable HTTP serves the protocol over HTTP for remote servers, with OAuth the recommended way to authenticate. Two extensions matter: Tasks, durable handles for long-running requests, and MCP Apps, interactive interfaces inside the AI client.

Where MCP stops

MCP says how a host finds and calls tools, reads resources and fetches prompts. It says nothing about how the host uses the model: which definitions go in the prompt, how the loop runs, what the model may do without asking. All of that stays in the host, which is the subject of the Agent loop module.

Trade-offs

A protocol costs a round trip per call and plumbing per server, pure overhead when one application needs one integration. Definitions still cost tokens on every request, so a host with a dozen servers must filter or search hundreds of them. Because the server runs with real credentials and the host trusts its results, a malicious or careless server is a prompt-injection channel and an exfiltration channel at once; the next lesson covers securing one.

In an interview

The sentence: "MCP turns M times N integrations into M plus N: a server exposes tools, resources and prompts over JSON-RPC, the host runs one client per server, and the model only sees what the host shows it." At junior depth, name the three participants and the three primitives. At mid depth, walk through discover, list and call, say what elicitation is, and contrast stdio with streamable HTTP. At senior depth, explain why statelessness suits remote servers behind load balancers, when to opt into notifications, what Tasks adds, and what it means that a server holds credentials. Expect the follow-up: "Does the server see the model?" No. It sees requests from a client; the host owns the model.