Client primitives — Cheat Sheet
Curso MCP Engineering · M1
This guide explains, from scratch and taking nothing for granted, the three client primitives: sampling, roots and elicitation. They are the "other half" of the protocol. If in the previous guide the server offered capabilities, here the roles are reversed: it's the server that asks the client for something. Read it slowly; every term is explained.
In one sentence
The client primitives are three capabilities that the client offers back to the server. They are what enable richer, more agentic servers (that reason and act across several steps). One detail that changes everything: all three are optional and are activated by capability negotiation — a handshake at connection time where each side says what it supports. If the client doesn't offer it, the server can't use it.
The three primitives at a glance
| Primitive | What it does | Why it matters |
|---|---|---|
Sampling (sampling/createMessage) | The server asks the host to generate a response with its LLM. | Model-independent servers: they don't bring or pay for their own AI; control and privacy stay on the client side. |
| Roots | Defines the boundaries (folders / URIs) where the server can operate. | Clear security and scope: the server touches nothing outside those edges. |
| Elicitation | The server asks the user for structured data midway through an operation. | Interactive flows: the server asks instead of guessing or failing. |
1. Sampling — "ask the host's brain to think"
What it is: with the sampling/createMessage method, the server asks the host to generate a response using its LLM (the language model, the AI "brain"). The server doesn't bring or pay for its own model: it uses the one the host already has.
Analogy: you're a chef (the server) who needs an expert opinion, but instead of hiring your own sommelier, you ask the house's sommelier (the host). You don't pay their salary, and the client keeps control of what gets asked and what gets answered.
Example: a server that processes reviews receives 200 comments and needs to classify them as "positive / negative". Instead of including its own model, it does sampling/createMessage —"classify this text"— and the host provides the LLM to answer. The server orchestrates; the brain is provided by the client.
2. Roots — "this far you may operate"
What it is: the boundaries —folders or URIs— within which the server can work. A URI is the address of a resource (like file:///project/ or a web address).
Analogy: you lend your house to someone but tell them "you can use the kitchen and the living room, not the bedrooms". Roots marks those doors.
Example: you connect a file server and the client declares as root only file:///home/you/abr-project/. The server can read and write inside that folder, but it can't go out to file:///home/you/private-documents/. The scope stays bounded and explicit.
3. Elicitation — "I need to ask you something midway"
What it is: the server asks the user for structured data in the middle of an operation —for example, "do you confirm the deletion?" or "what date do you want?"—. Instead of guessing or failing, it pauses and asks.
Analogy: the electrician is working, stops for a second and tells you "do you want the outlet on the left or the right?". They don't invent the answer; they consult you and continue with your data.
Example: a booking server is about to confirm a flight but is missing the passport number. It fires an elicitation asking you for that data with a structured form; you fill it in and the operation continues without breaking off.
Why sampling matters so much (model independence)
Of the three, sampling is the one that changes the game. Without sampling, each server would have to include and pay for its own AI model. With sampling, the server only asks for a response and the host provides the model. That means:
- Model-independent: the same server works with any LLM the host uses. It isn't tied to a provider.
- Privacy and control stay on the client/host side, not the server's: the host decides what gets sent to the model and what doesn't.
- Server-driven agents (that reason across several steps) become possible without the server having to bring intelligence of its own.
The role inversion (why they're called "client" primitives)
Go back for a second to the server primitives: there the server offered tools, resources and prompts, and the host used them. Here it's the opposite: it's the client that offers capabilities, and the server that asks for them. That's why they're called client primitives. The direction of the request is reversed, and with it, who's doing whom a favor.
Golden rule: in the server primitives, the server offers; in the client ones, the server asks and the client decides.
Glossary
- Client primitive: capability that the client offers the server (roles inverted).
- Sampling: the server asks the host to generate text with its LLM (
sampling/createMessage). - Roots: the boundaries of folders/URIs where the server can operate.
- Elicitation: the server asks the user for structured input midway through an operation.
- Capability negotiation: the initial agreement where each side declares what it supports.
- Optional: if the client doesn't declare it, that capability doesn't exist for that connection.
- URI: address of a resource (e.g.
file:///project/). - LLM: language model; the AI "brain" that generates responses.
- Agentic: a server that reasons and acts across several steps, not just answering once.
To remember
- The three client primitives are sampling, roots and elicitation, and all are optional.
- They're activated by capability negotiation: if the client doesn't offer it, the server doesn't use it.
- Sampling is the key to agentic, model-independent servers.
- Roots = boundaries of where to operate; Elicitation = ask the user in real time.
- Golden rule: the server asks, the client decides.
Turning Point Academy · MCP Engineering Course · Module 1 · Client primitives