MCP Elicitation: Requesting User Input Safely

Core idea: elicitation gives an MCP server a structured way to pause and ask the user for missing information without pretending that model-generated guesses are user consent.

Tools often discover that required information is missing only after work begins. A booking tool needs a date; a deployment tool needs an environment; a third-party integration needs the user to complete an external authorization flow. Elicitation represents this as an explicit input-required interaction.

TL;DR

• Form mode collects non-sensitive structured values inside the client.
• URL mode sends the user to an external secure interaction with explicit consent.
• Form mode must not collect passwords, API keys, or other sensitive credentials.
• Users can accept, decline, or cancel; servers must handle every outcome.
• Elicitation state must be bound to a verified user and client, not a forgeable identifier.

Two modes, different trust boundaries

Form mode presents a schema-driven form for ordinary inputs such as a project name, date, choice, or confirmation. The client renders the fields and validates the response; the server validates again. Defaults may improve usability but must not hide consequential choices.

URL mode directs the user to an external page for sensitive or secure interaction, including certain authorization and payment flows. The credentials and sensitive inputs must not pass through the MCP client. The client displays the full URL and target domain, obtains consent, and opens it securely without inspecting the interaction.

Servers can use only modes declared by the client. A client declaring elicitation must support at least one. This negotiation lets hosts decline interface patterns they cannot safely present.

The interaction flow

During a client request, the server returns an input-required result containing an elicitation/create request. The client identifies the requesting server, explains what is needed, and presents the form or URL. The user may accept, decline, or cancel. The client returns that action, and the server either resumes, offers a safe alternative, or ends clearly.

Never interpret no response as consent. Timeouts, closed dialogs, and failed navigation need explicit handling. An action may also become invalid while waiting, so authorization and business conditions must be rechecked when execution resumes.

A form example

A report tool learns that “last quarter” is ambiguous because the organization uses a custom fiscal calendar. It requests a form with a bounded quarter choice and an optional report label. The client shows which analytics server is asking and why. After acceptance, the server validates the choice and builds the report.

This is better than asking the model to infer a period and silently acting. It creates a typed value and a visible user decision.

A URL example

A calendar MCP server needs permission to access a third-party calendar account. It sends a URL elicitation request. The client shows the complete HTTPS URL and emphasizes the domain. After user consent, the browser opens an authorization flow between the user, the MCP server, and the third-party provider.

The third-party credential never travels through the MCP client. It is also distinct from the credential used by the client to access the MCP server. The server stores and protects its third-party tokens and securely binds completion to the correct verified user.

Security boundaries

Form mode must not request passwords, API keys, access tokens, or similarly sensitive values. URL mode must not contain personal data or credentials in the URL, and must not use a pre-authenticated URL that another person could replay. Clients must not prefetch the URL or open it automatically.

The server must not trust a user identifier supplied by the client without verification. Remote deployments should derive identity from MCP authorization credentials where possible. Stored request state needs access controls, expiry, anti-replay protection, and binding to user, client, request, and intended action.

Design a good request

A good elicitation request says who is asking, why the input is needed, how it affects the operation, and whether the action can be changed later. Keep forms minimal. Use enums and bounds where possible. Avoid manipulative language, preselected dangerous options, or a generic “continue” button that hides consequences.

Elicitation is not a replacement for ordinary conversation. Use it when structured input, explicit consent, or an out-of-band secure flow materially improves correctness.

Common mistakes

• Asking for credentials in form mode.
• Opening external URLs without explicit consent.
• Hiding or shortening the destination domain.
• Treating cancellation as acceptance.
• Failing to recheck authorization after a long pause.
• Mixing third-party tokens with MCP server credentials.
• Saving state under a client-provided, unverified user ID.

My Take

Elicitation is strongest when it makes uncertainty visible. Agents should not guess values that belong to users, and servers should not disguise external authorization as a chat response. A good elicitation UI turns an implicit assumption into an explicit, reviewable decision.

Sources

• Model Context Protocol specification (2026-07-28): Elicitation
• Model Context Protocol security best practices: identity binding and token passthrough