What is elicitation, and how does it let a server ask the user for additional input mid-operation?
Quick Answer
Elicitation (added in the 2025-06-18 spec revision) is a mechanism that lets a server send an elicitation/create request mid-task, asking the client to collect a specific piece of structured information directly from the user — for example, a tool that books a flight might realize partway through that it needs the user's seating preference, and elicit that instead of guessing, failing, or requiring the model to have collected it upfront in the original tool call. The request includes a message describing what's being asked and a JSON Schema describing the expected shape of the response; the client is expected to present this to the user (not silently auto-fill it), collect their answer, and return it, or return that the user declined/cancelled. This gives servers a clean way to handle genuinely interactive workflows without forcing every possible input to be front-loaded into the original tool call's arguments.
Detailed Answer
Before elicitation existed, a tool that discovered mid-execution it needed more information had few good options. It could fail with an error and hope the model re-asks the user and re-invokes the tool with better arguments, or it could make an assumption on the user's behalf. Elicitation gives it a direct, structured third option.
Example
// Server -> Client, mid-tool-execution
{"method": "elicitation/create", "params": {
"message": "Which seat would you like for this flight?",
"requestedSchema": {
"type": "object",
"properties": {
"seatType": {"type": "string", "enum": ["window", "aisle", "middle"]}
},
"required": ["seatType"]
}
}}
// Client, after prompting the user through its own UI
{"result": {
"action": "accept",
"content": {"seatType": "window"}
}}
The action field can also be "decline" — the user was asked but chose not to answer — or "cancel" — the user dismissed the request entirely. This lets the server tell "no answer given" apart from "explicitly said no" versus "walked away."
Why this belongs at the client/user layer, not the model layer
The model could just ask the user a clarifying question directly in the conversation and re-invoke the tool with the missing piece. Often that's exactly what should happen for simple cases. Elicitation is useful specifically when a tool's own execution logic, not the model's reasoning, is what determines a follow-up question is needed. That often happens deep inside a multi-step operation the model isn't tracking step-by-step. Getting a clean, schema-validated answer directly, rather than parsing it back out of a free-form model turn, meaningfully simplifies the server's implementation.
Design guidance
Keep elicited requests narrow and specific — a single, clearly-scoped question with a small schema. Don't use elicitation to front-load an entire complex form's worth of fields the server could reasonably have required as part of the initial tool call. Overusing elicitation for things that could have simply been tool arguments adds unnecessary round trips and interrupts the flow of a task the user expected to run to completion in one shot.