Client Primitives: Sampling, Elicitation, and Logging
Servers Can Ask Things of Clients Too
So far every primitive has been something a server offers a client. But MCP also defines primitives that clients expose to servers — letting server authors build richer, interactive integrations. There are three: sampling, elicitation, and logging. They flip the usual direction: now the server makes a request and the client fulfills it.
| Client primitive | What the server can do | Method |
|---|---|---|
| Sampling | Ask the client's LLM for a completion | sampling/createMessage |
| Elicitation | Ask the end user for input or confirmation | elicitation/create |
| Logging | Send log messages to the client for debugging | (logging notifications) |
Client primitives let a server use the host's LLM, ask the user questions, and emit logs — without bundling those capabilities itself.
Remember capability negotiation
A server can only use a client primitive the client advertised during initialization. If the client declared "elicitation": {}, the server may call elicitation/create; if it didn't, the server must not. This is the capabilities contract from the lifecycle lesson, applied in the server→client direction.
Sampling — Borrow the Host's LLM
Sampling lets a server request a language-model completion from the client's AI application, via sampling/createMessage. Why is this powerful? It means a server author can use an LLM without bundling a model SDK or API key into their server. The server stays model-independent — it asks the client 'please run this through your model' and gets the result back.
Example: a server that summarizes database query results could, instead of calling an LLM API directly, send the rows to the client via sampling and let the host's Claude summarize them. The server ships no AI dependency and works with whatever model the host uses.
Sampling needs human oversight
Because sampling spends the host's model budget and runs generations the user didn't directly type, well-behaved clients put a human in the loop — showing or approving sampling requests rather than executing them blindly. The protocol enables the capability; the client governs its use.
Elicitation — Ask the User
Elicitation lets a server request additional information from the user mid-operation, via elicitation/create. This is for when the server needs a value it doesn't have or wants confirmation before doing something consequential — 'Which environment should I deploy to?' or 'Confirm: delete 3 records?'. The client renders the request to the user and returns their answer.
Elicitation lets a server pause and request input or confirmation from the user through the client.
Logging and the Bigger Picture
Logging lets a server send log messages to the client for debugging and monitoring — useful when you can't easily see the server's own console (e.g. a remote server). Beyond these three, MCP also has cross-cutting utility features like progress notifications for long operations and an experimental Tasks primitive for durable, deferred execution.
- •Sampling — server requests an LLM completion from the client (stays model-independent).
- •Elicitation — server requests user input or confirmation mid-operation.
- •Logging — server sends log/debug messages to the client.
- •(Utility) progress notifications and the experimental Tasks primitive for long-running work.
Next
Client primitives round out the data layer. Next we go operational: running servers remotely with Streamable HTTP, and what changes when your server leaves your laptop.
Key Takeaways
- ✓MCP defines client primitives — capabilities a client exposes to servers — that flip the direction: the server requests, the client fulfills.
- ✓The three are Sampling (sampling/createMessage), Elicitation (elicitation/create), and Logging.
- ✓Sampling lets a server request an LLM completion from the client, so the server stays model-independent (no bundled model SDK or key).
- ✓Elicitation lets a server ask the user for input or confirmation mid-operation (e.g. 'which environment?', 'confirm delete?').
- ✓Logging lets a server send debug/monitoring messages to the client — valuable for remote servers you can't watch directly.
- ✓Client primitives are capability-gated (a server can only use what the client advertised), and sampling in particular warrants human oversight; MCP also has progress notifications and an experimental Tasks primitive.
Check Your Understanding
Test what you learned in this lesson.
Q1.How do client primitives differ from server primitives?
Q2.What is the main benefit of the sampling primitive for a server author?
Q3.When would a server use elicitation/create?
Q4.What governs whether a server may call a client primitive like elicitation?
Practice This Lesson