In MCP, what is elicitation and when does a server use it?
answer
- Server needs something only the human knows
- Structured ask, not free text
- Schema-described fields the client renders
- Answered on the client's retry, not a callback
- Form mode for ordinary values, URL for secrets
basics
~20 sElicitation is MCP's way for a server to ask the human user for structured input while it is handling a request — a missing parameter, a confirmation, a choice between accounts. The client shows the ask and returns the user's answer.
solid answer
~40 sElicitation lets an MCP server ask the person behind the client for information it cannot get from the model or from its own configuration. The server issues an `elicitation/create` ask carrying human-readable prompt text and a `requestedSchema` describing the fields it wants; the client renders that to the user and sends back the answer. Typical uses: a tool discovers mid-call that it needs a value nobody supplied, a destructive action needs explicit confirmation, or the user must pick between several accounts the server just discovered. In revision 2026-07-28 the ask is delivered inside the result of the request the server is already handling, because that revision removed server-initiated requests entirely. Elicitation survived the 2026-07-28 deprecation sweep that hit roots and sampling — it is current, not legacy.
go deeper
Be able to say in one sentence that elicitation is a server asking the human user for specific fields, and give one concrete example such as confirming a destructive action or choosing an account.
Explain the shape: prompt text plus a schema of fields, answered with accept, decline or cancel, delivered as an interim result the client answers by retrying in revision 2026-07-28.
Show judgment about when to interrupt a user at all — batch fields into one ask, keep prompts intelligible to someone who forgot your server exists, and never rely on an answer arriving.
Own the position that elicitation is a consent surface, not a data channel: it must be rare, legible and never used to route secrets, and clients without the capability must still be able to use your server.
## The problem elicitation solves An MCP server exposes tools, resources and prompts to a host application that embeds a language model. Most of the time the model supplies every argument a tool needs. Sometimes it cannot, because the missing piece is genuinely the human's to give: which of the three AWS accounts the user just turned out to have should the deployment target? Does the user really want this table dropped? What is the ticket number, which only the person knows? Elicitation is the protocol feature for exactly that gap. It is a structured, schema-described request for user input, raised by the server in the middle of handling something else. ## The shape of the ask The ask is an `elicitation/create` request. It carries two things that matter: human-readable prompt text explaining to the user what is being asked and why, and a `requestedSchema` — a JSON Schema object describing the fields the server wants back. The schema is deliberately narrow: one flat object of primitive properties (string, number, integer, boolean, enum), no nesting and no arrays, so that any client can render it as a generic form without understanding the server's domain. The user's answer comes back with one of three actions: `accept` (they filled it in), `decline` (they refused), or `cancel` (they dismissed it without deciding). ## How it reaches the client in revision 2026-07-28 This is where a candidate who learned MCP in 2025 goes wrong. In the older revisions (2025-11-25 and earlier) a server could open a JSON-RPC request of its own back to the client, and elicitation was such a request. Revision 2026-07-28 removed server-initiated requests: there is no `ServerRequest` union any more. Instead the server returns an interim result from the request it is currently handling — a `tools/call`, a `prompts/get`, or a `resources/read` — and the elicitation ask rides inside that result. The client collects the user's answer and re-issues the original request with the answer attached, under a new JSON-RPC id. Those are the only three methods that may raise an elicitation. The consequence worth internalising: from the server's point of view, elicitation is not a callback. It is "return, and hope the client comes back". Nothing obliges the client to come back at all. ## What elicitation is not It is not a way to reach the model. Asking the model to generate something was `sampling/createMessage`, a separate feature, deprecated in 2026-07-28 in favour of integrating with an LLM provider directly. Elicitation targets the human. It is not a way to collect secrets in a form. The specification states that form-mode elicitation MUST NOT request sensitive information — no passwords, API keys or card numbers. When the server genuinely needs the user to hand something sensitive over, it uses URL mode: the client opens a URL where the user completes the interaction out of band, so the secret never travels through the client or the model's context. It is also not guaranteed to be available. Client capabilities travel on every request in 2026-07-28, and `elicitation` is one of them. A client that does not declare it cannot be asked; a client that declares it as an empty object supports form mode only. Because the protocol is stateless, the server checks the capabilities carried on the request in front of it — it must not remember what a previous request declared. ## Practical guidance Ask for everything you need in one elicitation rather than three sequential ones — each one costs a full round trip and a fresh decision from the user, and a form can carry several fields at once. Write the prompt text as if the user has no idea what your server is: they are being interrupted by a dialog raised by software they may not have thought about since they configured it. And design tools so that elicitation is the exception: an argument the model can supply belongs in the tool's input schema, not in a mid-call interruption. ## Version note Everything above describes revision 2026-07-28. Elicitation exists in 2025-06-18 onwards; what changed in 2026-07-28 is the delivery mechanism (interim result plus client retry, instead of a server-initiated request) and the addition of URL mode alongside form mode.
- Which requests can raise an elicitation, and which cannot?Only `tools/call`, `prompts/get` and `resources/read` may return an interim result asking for input in revision 2026-07-28. Listing methods such as `tools/list` and `resources/list`, and `server/discover`, must answer directly. That keeps discovery and enumeration cheap and non-interactive, so a client can build its catalogue without ever putting a dialog in front of a user.
- What should a server do if the client never comes back with an answer?Treat it as the request simply not completing. The server returned an interim result and released the request; there is no callback pending and nothing to time out on the wire. Any resources the server reserved should be cheap to abandon, and any state it stashed to resume with should expire on its own. Never assume a retry is coming.
- Does elicitation let the server read what the user typed into the chat?No. A server sees only what the client sends it: the arguments of the request plus whatever the user supplies in answer to its own elicitation. It cannot read the conversation, cannot see other servers' traffic, and cannot ask the client for arbitrary context. Elicitation is a narrow, user-approved channel for specific named fields.
saying these in an interview costs you the question
- Says the server sends elicitation/create to the client as a request
- Calls elicitation a way to ask the model for text
- Thinks any method, including tools/list, can elicit
- Believes the client must answer an elicitation
- Assumes elicitation was deprecated alongside roots and sampling