MCP Elicitation: Ask the User Mid-Tool-Call
MCP elicitation turns a one-shot tool call into a user-guided workflow, but only when the client, transport, and server all handle interruption correctly.
MCP elicitation is the protocol mechanism that lets an MCP server ask the user for missing information while processing a tool call or another supported request. The client presents the question, returns the response, and lets processing continue. It solves one narrow problem: a server cannot safely guess input that only the user can provide.
Table of contents
- MCP elicitation, defined plainly
- How MCP elicitation works
- Worked example: changing a deployment window
- MCP elicitation vs tool approval
- When elicitation matters—and when it does not
- What breaks in production
- Client support reality
MCP elicitation, defined plainly
MCP elicitation is structured, server-requested user input routed through the MCP client. The server describes what it needs; the client owns the interface; the user can accept, decline, or cancel.
An MCP server knows why a workflow cannot continue, but it should not invent an email address, choose a production environment, or assume consent. The official MCP elicitation specification leaves the interface open: a client might use a dialog, terminal prompt, or inline card.
There are two modes. Form mode collects non-sensitive structured values using a restricted JSON Schema. URL mode sends the user to an external page for credentials, payments, or third-party authorization so secrets do not pass through the client or model context. My rule: use a form for choices and ordinary profile data; use a URL for anything that grants access or authorizes money movement.
How MCP elicitation works
The current flow is a negotiated, multi-round exchange. It looks like one interrupted tool call, but the 2026-07-28 protocol carries the question in an incomplete result and has the client retry the original request with the answer.
The protocol flow, step by step
The client must advertise support before a server asks anything. Skipping that check creates a hang or error in clients that implement tools but not elicitation.
- The client calls
tools/callor another request type that permits an input-required result. - The server returns an
InputRequiredResultcontaining anelicitation/createinput request. - The client renders it. Form mode may generate controls from
requestedSchema; URL mode shows the full destination and asks before opening it. - The user chooses
accept,decline, orcancel. Accepted form data goes incontent. - The client retries the original request with
inputResponsesand echoesrequestStatewhen supplied. The server finishes or asks again.
This is Multi Round-Trip Requests, specified in SEP-2322. It replaced the assumption that one process could wait on one live connection. Any replica can handle the retry if the request carries sufficient state—a major difference for local and remote MCP deployments.
What the schema can express
Form mode is intentionally small: a flat object with primitive strings, numbers, integers, booleans, and enum-style choices, including multi-select enums. It is not a general form language.
Nested objects, arbitrary object arrays, conditional pages, file uploads, and custom widgets do not fit. The specification permits defaults and formats such as email, URI, date, and date-time. If the interaction needs checkout, identity proof, or a complex wizard, use a secure web application through URL mode.
Worked example: changing a deployment window
A useful elicitation asks only for a decision that became necessary after execution began. Consider a release tool whose requested production window has just closed.
- The agent calls the deployment tool with
service=paymentsandenvironment=production. - The server finds the next permitted windows are 02:00 or 04:00 UTC. It has not changed production.
- It returns a form request with one required enum field for those windows and a cancel path.
- The client identifies the server, displays both choices, and lets the user inspect the pending operation.
- The user accepts 04:00 UTC. The client retries; the server rechecks policy, schedules the deployment, and returns its ID.
That recheck is non-negotiable. User input is not proof that inventory, permissions, price, or policy stayed unchanged. The Python SDK elicitation example demonstrates accept, decline, and cancel handling; production code also needs expiry, idempotency, and fresh authorization checks.
I would not ask, “What should I do?” Offer bounded, current choices and explain their consequences.
MCP elicitation vs tool approval
MCP elicitation gathers information a server needs; tool approval asks whether the client may execute a proposed call. Similar-looking dialogs sit at different layers and are not substitutes.
| Question | MCP elicitation | Tool approval |
|---|---|---|
| Who initiates it? | MCP server during processing | MCP client or host before execution |
| Main purpose | Collect missing data or a contextual choice | Enforce the client’s execution policy |
| Typical timing | After the tool starts evaluating the request | Before the tool call is sent |
| Response owner | Server interprets accept, decline, or cancel | Client decides whether the call runs |
| Good example | Choose an available delivery window | Permit a tool to delete files |
| Security status | User interaction, not authorization | Client control, not business authorization |
Do not hide a destructive operation behind a “continue?” elicitation and call it access control. Servers must bind requests to a verified user while the service still enforces authorization. The specification’s security rules also forbid secrets in form mode and require consent before a URL opens.
When elicitation matters—and when it does not
Use elicitation when new facts arise during execution and the human can answer a small, consequential question. Avoid it when input was predictable, no person is present, or the workflow needs a full application interface.
Good cases include choosing among newly discovered appointment slots, confirming a revised quote, supplying a non-secret label, or selecting the correct matched record. URL mode also fits third-party OAuth—but that is distinct from authorizing the MCP client to access the MCP server.
Bad cases include collecting every argument separately, asking for an API key in a form, or replacing clear inputs with repeated prompts. Batch automation, background agents, and CI may have nobody available to answer. Prefer explicit arguments, policy defaults, or a fail-fast result. Browse recommended MCP servers with this distinction in mind: interactive behavior is a compatibility requirement, not a bonus checkbox.
What breaks in production
The common failures are capability mismatch, stale state, timeouts, and duplicate side effects. A human-paced round trip needs an explicit failure path at every boundary.
- Unsupported clients: check the advertised mode and return an actionable fallback.
- Timeouts: align client, proxy, and server limits. The MCP Inspector documentation warns that interactive tools need an adequate timeout.
- Retries and duplicates: do not charge, deploy, or delete before the answer. After retry, use an idempotency key and revalidate mutable facts.
- Tampered or expired state: sign or server-store state, bind it to a verified user, and expire it.
- Transport assumptions: old implementations used a live session; current MRTR retries. Local stdio transport may hide problems that surface behind remote load balancers.
My preference is one elicitation round, two at most. Beyond that, latency, abandonment, and recovery logic outweigh the convenience; build a dedicated web flow.
Client support reality
Client support is uneven, and “supports MCP” does not mean “supports elicitation.” The runtime capability declaration—not a marketing page or remembered version—is the source of truth.
MCP Inspector is the clearest test client: its release history includes elicitation-form fixes and enum support. VS Code with Copilot has also handled elicitation since its June 2025 release, as recorded in a closed Python SDK compatibility issue. For Cursor, Claude Desktop, Windsurf, and other clients, support reports change faster than stable first-party documentation; do not infer it from basic MCP tool support. Form support also does not imply URL support, defaults, multi-select enums, or the newest MRTR flow.
Test the exact client version, transport, mode, and protocol revision you ship against. Then test decline, cancel, timeout, malformed content, retries, and a disconnect after the answer. My policy is progressive enhancement: elicitation improves an interactive path, while an unsupported client gets a precise error or alternative contract. Making it the only path today needlessly shrinks the usable client set.