MCP: hosts, clients, servers and its three primitives

By the end, you can

• Explain the MCP host, client and server roles and the isolation the specification's own design principles require between them, using the current official specification (LA-10).
• Distinguish MCP's three server-offered primitives — resources, prompts and tools — by which party controls each one, using the spec's own model-controlled, user-controlled and application-driven language (LA-10).
• Explain why MCP exists as a shared protocol rather than another vendor-specific tool-calling format, extending Tool use and the agent loop's three-vendor comparison by name (LA-8, LA-10).

Before you start

This is Lesson 1 of 3 in MCP and interoperable tools, this course's closing restored-depth module — but not its closing pedagogical arc: Evidence and evaluation and Rollback and handoff still follow this module and remain where the course actually ends. This lesson assumes Tool use and the agent loop's Tool schemas and the call/result round-trip lesson by name, without re-teaching it: that lesson showed Ollama, OpenAI and Anthropic each wiring the same call-a-function idea through three genuinely different JSON shapes, a builder has to check against each runtime's own current docs. It also assumes The model underneath's System, user, tool and retrieved context lesson's four-category context map. This lesson introduces the Model Context Protocol (MCP) — a specification, not a vendor's API — and the vocabulary its own architecture defines for the two lessons that follow.

One protocol, three roles

MCP's own architecture specification states its core components plainly, and the three roles are worth learning as named terms, not paraphrased loosely:

The isolation between these roles is not incidental — it is one of the specification's own named design principles: "Servers should not be able to read the whole conversation, nor 'see into' other servers." Concretely, that means "full conversation history stays with the host," "each server connection maintains isolation," and the "host process enforces security boundaries" across every client-server pair it manages. A single host talking to a filesystem server and a database server at the same time is exactly the picture the specification's own architecture diagram shows — one host process, several isolated client-server pairs, none of them able to see what the others are doing.

This is worth pausing on against this course's own earlier vocabulary. Filesystem and network scope built a run plan naming exactly what one bounded task may read, write and reach — a scope a builder had to design and write down by hand. MCP's host/client isolation is the same idea enforced one layer up, at the protocol's own architecture: a server the host connects to for reading project files structurally cannot see the conversation happening with a separate server the host also happens to be using, regardless of what either server's own code tries to do.

• **Host** — "The host process acts as the container and coordinator": it creates and manages multiple client instances, "controls client connection permissions and lifecycle," "enforces security policies and consent requirements," and "coordinates AI/LLM integration and sampling." A host is the application a person actually uses — an IDE, a desktop assistant, a chat client.
• **Client** — "Each client is created by the host and maintains an isolated server connection": it "establishes one stateful session per server," handles "protocol negotiation and capability exchange," and "maintains security boundaries between servers." A host application creates and manages multiple clients, "with each client having a 1:1 relationship with a particular server." A client is not something a person sees or launches — it is the in-process connector the host creates internally, one per server it talks to.
• **Server** — "Servers provide specialized context and capabilities": they "expose resources, tools and prompts via MCP primitives," "operate independently with focused responsibilities," and "must respect security constraints." A server "can be local processes or remote services" — concretely, anything from a small local program exposing one project folder's files to a remote service wrapping a vendor's API.

Why a protocol, not another vendor tool-calling shape

Tool schemas and the call/result round-trip walked through the same underlying idea — a model requests a tool, code runs it, an answer comes back — wired through three different wire shapes on Ollama, OpenAI and Anthropic's own current APIs: different field names, arguments arriving as a parsed object on two runtimes and a string to parse on the third, a different result-message shape on each. Porting a working tool loop between them meant re-checking each runtime's own docs field by field.

MCP exists to give that same request/dispatch/answer idea one shared shape a server author writes once and any MCP-compliant host can speak, rather than a shape tied to one model vendor's own API. The specification calls this out as a design principle in its own right: "servers should be highly composable" and interoperate through "a shared protocol," and "servers should be extremely easy to build" because a host application — not each server — absorbs the complex orchestration.

The specification itself is a living, dated document, and that matters for how a builder should treat any claim made about it. Its own versioning page states the scheme directly: "The Model Context Protocol uses string-based version identifiers following the format `YYYY-MM-DD`, to indicate the last date backwards incompatible changes were made," and names the version this lesson (and the two that follow) verify against explicitly: "The current protocol version is **2025-11-25**." Every MCP claim in this module is pinned to that exact revision and carries a tight review date in this course's own source register, for the same reason this course already tags quantisation, runtime and hardware claims as staleness-prone: a protocol under active revision is not a fact that settles once and stays settled.

Three primitives, three different controllers

A server exposes its capabilities through exactly three primitives, and the specification's own naming is precise about who is in charge of each one — this distinction matters more than it first appears, because it decides who has to act before something happens.

A worked example makes the three-way distinction concrete. A local "project-notes" MCP server for a small team could expose: one **resource** — the team's shared meeting-notes file, read via `resources/read`, available for the host to include as context whenever it decides to; one **prompt** — a `summarize-notes` template a user explicitly triggers from a menu, asking the model to produce a structured summary of whichever notes the user picked; and one **tool** — a `search_notes` function the model itself decides to call mid-conversation, when it judges that answering the user's question requires searching the notes rather than guessing. Three different mechanisms, three different parties deciding when each one fires.

One connection worth naming before the next two lessons build on it: a resource's content — the meeting notes file above, read back through `resources/read` — is exactly The model underneath's own retrieved context category, now delivered through a standard protocol mechanism instead of a bespoke retrieval pipeline. Lesson 3 returns to that connection directly, because what is true of retrieved context generally is true of an MCP resource specifically.

• **Tools** — "Functions for the AI model to execute." The Tools specification states the interaction model directly: "Tools in MCP are designed to be **model-controlled**, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts." This is exactly Tool use and the agent loop's own tool-call pattern, now standardized at the protocol level rather than left to each runtime's own field names.
• **Prompts** — "Templated messages and workflows for users." The Prompts specification states the opposite control model: "Prompts are designed to be **user-controlled**, meaning they are exposed from servers to clients with the intention of the user being able to explicitly select them for use" — commonly surfaced as something like a slash command a person chooses on purpose, not something the model reaches for on its own.
• **Resources** — "Context and data, for the user or the AI model to use." The Resources specification calls this pattern "**application-driven**, with host applications determining how to incorporate context based on their needs" — a host might expose resources through a picker UI, let a user search and filter them, or include them automatically by heuristic.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. All quoted specification text and worked examples appear as plain inline or block text, readable and copyable by assistive technology and keyboard-only users. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Architecture — Model Context Protocol. Documents the host/client/server core components and the design principle that servers should not read the whole conversation or see into other servers.
2. Versioning — Model Context Protocol. States that the current protocol version is 2025-11-25 and explains the YYYY-MM-DD version-identifier scheme.
3. Specification overview — Model Context Protocol. Names Resources, Prompts and Tools as the three server-offered features.
4. Tools — Model Context Protocol. States that tools are model-controlled.
5. Prompts — Model Context Protocol. States that prompts are user-controlled.
6. Resources — Model Context Protocol. States that resources are application-driven.