Why architecture matters here
Elicitation matters because servers legitimately need user input mid-operation, and the alternatives are all bad. Without elicitation, a server needing a missing value must either fail (can't proceed), guess (wrong guesses cause errors), or store the data ahead of time (requires the server to hold information it maybe shouldn't). Consider a deployment tool that needs a confirmation before deleting production resources, a configuration tool that needs a value the user hasn't set, or a tool that hits ambiguity (which of three matching records did you mean?). Each needs user input at that moment, and elicitation provides it — the server asks, the user answers, the operation continues. This enables interactive, user-in-the-loop server operations (confirmations, configuration, disambiguation) that static, no-input tools can't support, making MCP servers capable of the interactive workflows real tasks often require.
The trust boundary is the architectural heart, and it's what makes elicitation safe rather than dangerous. An MCP server may be third-party, and giving untrusted servers an uncontrolled channel to prompt users would be catastrophic: a malicious server could phish (prompt 'enter your password' with a convincing pretext), exfiltrate (prompt for sensitive data), or manipulate (prompt with misleading framing). Elicitation prevents this through client mediation and user control: the client (the trusted intermediary — the host application) presents the elicitation request, so the user sees it in the trusted UI (not the server's UI), understands it's a server request, and controls the response (provide, decline, cancel). The server can't force input, can't fake the UI, can't access declined data. This mediation — the client as trusted broker, the user as decision-maker — is the security model that lets servers request input without becoming a phishing vector, and it's the same model as sampling (client-mediated model access) applied to user input.
And the structured, schema-validated nature is what makes elicitation reliable rather than free-form. An elicitation request includes a schema describing the expected input (types, constraints, options) — so the user's response is structured and validated (a confirmation is a boolean, a config value has a type, a disambiguation is a choice from options), the server gets typed input it can use directly (no parsing free text), and the client can render appropriate UI (a checkbox for a boolean, a dropdown for options, a typed field for a value). This structure makes elicitation a reliable input mechanism (typed, validated) rather than a fragile free-text exchange, and it's what lets servers request specific, usable input — the schema is the contract that makes the input request precise and the response usable.
The architecture: every piece explained
Top row: the flow. A server needs input — mid-operation, it lacks a value, needs confirmation, or hits ambiguity requiring user resolution. It sends an elicitation request: a structured request containing a schema (describing the input needed — type, constraints, options) and a prompt (explaining what's needed and why). The client mediates: it receives the request and presents it to the user in its trusted UI — the user sees the prompt, understands it's a server request, and is asked to respond. The user responds: they provide structured input matching the schema (a confirmation, a value, a choice) — or decline/cancel. The response returns to the server (if provided), which continues its operation with the input.
Middle row: the guarantees. Schema validation: the response is validated against the schema — a typed value, a boolean confirmation, a choice from defined options — so the server gets structured, valid input (not free text to parse), and the client can render appropriate UI. User control is central: the user can approve (provide the input), decline (refuse this specific request), or cancel (abort the operation) — the user decides whether and how to respond, and the server proceeds only with what the user provides. Trust boundary: the server requests but can't force — it can't fake the UI (the client presents it), can't access declined input, can't coerce. The client mediation and user control are the security model. vs sampling: sampling requests the client's LLM to generate (the server asks the model to produce text); elicitation requests the user to provide input — both client-mediated (the same trust model), but one seeks model generation and the other seeks user input.
Bottom rows: applications and security. Use cases: configuration (the server needs a value the user hasn't set), confirmation (approve before a destructive or significant action — the human-in-the-loop gate), disambiguation (choose among matching options), and controlled credential provision (the user provides a credential the server doesn't store). Security: the mediation prevents phishing (the user sees it's a server request in the trusted UI, not a fake login), prevents coercion (the user can decline), and the client should guard against sensitive-data over-requesting (a server repeatedly asking for credentials or personal data is suspicious — the client can warn or limit). The ops strip: schema design (clear, appropriately-typed schemas that make the input request precise and the UI renderable), UX (presenting elicitation clearly — what's asked, why, by which server — so users make informed decisions), and consent flows (the user-control mechanisms — approve/decline/cancel — implemented so users are genuinely in control).
End-to-end flow
Trace elicitation through real interactive operations. A deployment MCP server is asked to deploy to production; before executing the destructive/significant action, it needs confirmation. It sends an elicitation request: schema (a boolean confirmation) plus prompt ('Deploy version 2.3 to production? This will replace the current version.'). The client presents this in its trusted UI — the user sees it's a request from the deployment server, understands the action, and confirms (or declines). The confirmation returns; the server deploys. The human-in-the-loop gate for a significant action, provided through elicitation — the server couldn't safely proceed without confirmation, and elicitation got it through a controlled flow. Had the user declined, the server would not deploy — the user's control is real.
The disambiguation and configuration vignettes show the range. A tool searches for a customer and finds three matches; rather than guessing or failing, it elicits: schema (a choice from the three options) plus prompt ('Multiple customers match "Smith" — which did you mean?'). The client renders a selection UI; the user chooses; the server continues with the right customer — disambiguation resolved by asking rather than guessing. A configuration case: a tool needs a project ID the user hasn't configured; it elicits (schema: a typed string, prompt: 'Which project should I use?'), the user provides it, the operation proceeds — missing configuration filled interactively rather than failing.
The security and trust vignettes complete it. A malicious server tries to phish: it sends an elicitation request prompting 'Enter your account password to continue.' But elicitation's mediation limits the damage: the client presents it clearly as a request from this specific server (not a fake system login), the user sees a third-party server asking for their password (suspicious — legitimate operations rarely need this), and the user declines (and possibly reports the server). The client can further guard: warning on sensitive-data requests, limiting repeated credential requests. The trust boundary (client-mediated, user-controlled, server can't force or fake) prevented the phishing from being effective — the user, in control and informed, refused. The consolidated discipline the team documents: use elicitation for legitimate mid-operation input needs (confirmation, disambiguation, configuration), design clear schemas (typed, precise, renderable), present elicitation clearly (what, why, which server) so users make informed decisions, implement genuine user control (approve/decline/cancel), and guard against sensitive-data over-requesting — because elicitation lets servers request user input for interactive workflows, but its safety depends entirely on the client mediation and user control that keep untrusted servers from turning input requests into phishing or coercion.