Elicitation
The one current client-side primitive — how a server asks the user for more information mid-operation, and the MRTR pattern behind it
Elicitation
TL;DR
Elicitation lets a server pause an operation and ask the user for more information through the client, via elicitation/create. It's the one client-side primitive that's still fully current — unlike Sampling, Roots, and Logging, all deprecated in the same spec revision. It's delivered through the Multi Round-Trip Requests (MRTR) pattern: a request that pauses, gets an answer from outside the server, and resumes.
| Property | Value |
|---|---|
| Level | Intermediate |
| Reading time | ~15 minutes |
| Prerequisites | Deprecated Primitives |
| You will understand | How elicitation works structurally, when to reach for it, and how it differs from ordinary input validation |
What Elicitation Is For
A server sometimes reaches a point mid-operation where it genuinely doesn't have enough information to proceed safely — and asking the model to guess, or failing outright, are both worse than just asking a human. Elicitation is the mechanism for that: the server requests input from the user, through the client, via elicitation/create.
Server: about to delete 47 files matching *.tmp
Server: elicitation/create → "Delete 47 files matching *.tmp — confirm?"
Client: shows this to the user, waits for a response
User: "Yes, go ahead"
Client: returns the answer to the server
Server: proceeds with the deletionClient support for elicitation is declared as a capability — "elicitation": {} in clientCapabilities, the same field you've seen in every _meta example throughout this track. A server can check whether the connected client supports elicitation before relying on it.
The Multi Round-Trip Requests (MRTR) Pattern
Ordinary MCP requests are single round trips: the client sends a request, the server sends back a result, done. Elicitation doesn't fit that shape — the server needs an answer from a human before it can finish, and a human might take real time to respond. MRTR is the structural pattern that handles this: instead of blocking on a single response, the exchange pauses partway through, waits for external input, and then resumes.
A concrete illustration of MRTR, even though the feature itself is deprecated: the old Roots mechanism used exactly this pattern. A server needing the client's roots would send an InputRequiredResult containing a roots/list sub-request; the client's answer came back inside inputResponses on a retried request, rather than as a normal single response. Elicitation follows the same structural shape — a pending operation, an embedded sub-request for missing input, and a resumed call once that input arrives.
This matters because it explains why elicitation isn't just "the server sends a message and gets a reply" — it's specifically built to handle the case where fulfilling a request requires a pause of unknown length for human input, then a resumption of the original operation with that input incorporated.
When to Reach for Elicitation
Good and bad fits for elicitation
Confirming a destructive or high-consequence action
RecommendedDeleting many files, sending a payment, overwriting existing data — cases where proceeding without confirmation risks real, hard-to-reverse harm.
A genuinely missing required piece of information
RecommendedThe model didn't supply a value the server needs and has no reasonable way to infer — rather than failing the whole call, the server can ask for just that piece.
Disambiguating between multiple plausible interpretations
"There are three files named report.pdf — which one?" is a case where guessing wrong is worse than a short pause to ask.
Routine argument validation
If a tool argument fails basic type or range validation, that's an ordinary error response, not an elicitation. Elicitation is for missing information a human needs to supply, not for enforcing a schema the model should have gotten right in the first place.
Elicitation vs Ordinary Validation
It's worth being precise about the boundary here, because the two look superficially similar — both involve a tool call not simply succeeding.
| Elicitation | Ordinary validation | |
|---|---|---|
| Who it asks | The human user, through the client | Nobody — it's a mechanical check |
| What triggers it | The server genuinely needs information it has no other way to get | The model's supplied arguments don't match the tool's schema |
| What happens | The operation pauses, waits for a real answer, then resumes | The call fails immediately with an error the model can read and retry from |
| Example | "Confirm this payment of $4,200" | "amount" was sent as a string, but the schema requires a number |
Don't reach for elicitation as a substitute for a well-designed schema. If a tool's inputSchema is tight and specific — required fields marked required, enums instead of free text — most "missing information" cases never reach the point of needing a human interruption at all. Elicitation is for the residual cases a schema genuinely can't resolve on its own, not a crutch for a loose one.
Concept Checks
Check yourself
Why can't elicitation be handled as a single, ordinary request-response exchange?
Because the server needs an answer from a human before it can complete the operation, and a human's response time is unbounded and external to the server's own processing. The Multi Round-Trip Requests pattern exists specifically to let an operation pause mid-flight, request the missing input, and resume once it arrives — rather than forcing the whole exchange to block synchronously inside one request-response pair.
A tool call fails because the model sent a string where the schema requires a number. Should the server use elicitation to ask the user to correct it?
No — that's ordinary schema validation, not a case for elicitation. The fix is a normal error response the model can read and retry from with a corrected argument; elicitation is reserved for cases where a human genuinely needs to supply information or a decision the server has no other way to obtain, not for enforcing type correctness the model should get right from the schema alone.
How does elicitation relate structurally to the old (deprecated) Roots mechanism's roots/list request?
Both use the same Multi Round-Trip Requests pattern — a pending operation embeds a sub-request for information it doesn't have, the client's answer is returned inside inputResponses on a retried request rather than a normal single response, and the original operation then resumes. Roots itself is deprecated, but the MRTR structure it used is exactly the mechanism elicitation still relies on today.
Key Concepts Recap
| Concept | One-line summary |
|---|---|
| Elicitation | A server asking the user for more input mid-operation, via elicitation/create |
| Still current | Unlike Sampling, Roots, and Logging — elicitation was not deprecated |
| MRTR | Multi Round-Trip Requests — the pattern for a request that pauses, waits, and resumes |
"elicitation": {} | The client capability flag declaring elicitation support |
| Good use cases | Confirming destructive actions, missing required info, disambiguation |
| Not a use case | Routine schema/type validation — that's an ordinary error response |
| Roots' old mechanism | Used the same MRTR pattern, even though Roots itself is deprecated |
Next
With every primitive covered, the next question is how messages actually get from a client to a server in the first place: Transports.