Most MCP tools assume they get everything they need up front. Real tasks don't work that way. A booking tool needs a date the user never mentioned; a delete tool wants a confirmation; a commit tool needs to know which branch. Elicitation is the MCP mechanism that lets a server stop mid-execution and ask — turning a one-shot tool call into a short, structured conversation.
The shape of the pattern
The flow is deliberately small: the server hits a point where it needs input, it elicits, the client renders a form, the user answers, and the server continues with the answer in hand. From the server author's side it's a single call — request input, then handle one of three outcomes: the user submitted, the user cancelled, or the user declined. Crucially, the client declares an elicitation capability during initialization, so the server knows up front whether it's even allowed to ask. If the client can't elicit, the server falls back gracefully instead of hanging.
Why this beats rolling your own UI
Before elicitation, a server that needed mid-flight input had two bad options: cram everything into the initial parameters and reject the call if anything was missing, or generate some ad-hoc prompt and hope the model relayed it faithfully. Both produced inconsistent experiences across clients. Standardising the interchange means the host owns the rendering — a coherent form in Claude, in VS Code, in whatever client — and the server just declares what it needs. Developers stop hand-building one-off dialogs, and users get a predictable "the tool is asking me something" moment.
Keep the schemas flat
The single most useful piece of practical advice: stick to primitive types — string, integer, boolean, enum — in your elicitation schemas. Deeply nested objects may not render well across every client, because each host turns your schema into a form and not all of them handle complex structures gracefully. If you need rich, structured input, that's a signal you want MCP Apps and a real interface, not an elicitation form. Use elicitation for the small, well-typed gaps: a date, a choice from a list, a yes/no, a single free-text field.
Where it shines
Four recurring cases cover most of the value. Missing parameters — fill the gap a user left out instead of failing the call. Confirmation — "Are you sure you want to delete these files?" before a destructive action, which doubles as a human-in-the-loop safety gate. Clarification — "Which environment should I deploy to?" Progressive disclosure — collect a complex request one step at a time. That confirmation case is especially valuable for write-capable servers, where a human checkpoint is often the difference between a safe tool and a dangerous one. See MCP permission scoping patterns for the broader safety picture.
Going further
Elicitation pairs naturally with the Tasks extension — a long job can pause to ask a question, then resume — and with MCP Apps for richer interaction. New to the protocol? Start with what is MCP. To build a server that uses it, see your first MCP server in Node.js or browse the developer-tools category.