What is MCP Elicitation?
MCP Elicitation is a Client capability that lets an MCP Server request additional user input during an eligible operation while the Client controls presentation, consent, and data sharing.
Quick Facts
| Full Name | Model Context Protocol Elicitation |
|---|---|
| Created | Form mode in 2025; URL mode added in MCP 2025-11-25 |
| Specification | Official Specification |
How It Works
Current MRTR flow
Elicitation uses Multi Round-Trip Requests rather than an unsolicited Server-to-Client JSON-RPC Request. The Client declares elicitation support in per-request Capabilities. An eligible Server operation returns resultType: "input_required" with a named elicitation/create request. After user interaction, the Client retries the original method with a new JSON-RPC ID, matching inputResponses, and any requestState copied exactly.
Form mode
Form mode collects non-secret structured input inside the Client. requestedSchema is intentionally limited to a flat object with supported primitive fields, constraints, and enums so Hosts can render predictable UI. The Client shows which Server is asking, lets the user review and modify values, validates the response, and offers decline and cancel. Passwords, API keys, access tokens, and payment credentials must never be requested through form mode.
URL mode
URL mode moves sensitive interaction out of band to an HTTPS page controlled by the appropriate party. The Client displays the destination host and purpose, obtains consent before navigation, and does not receive the credential or payment data. An accept response means the user agreed to open the URL, not that the external flow succeeded. On retry, the Server checks its own bound state and can complete, request more input, or fail.
Authorization boundary
URL Elicitation for a third-party account is separate from MCP Authorization between the Client and MCP Server. The Server may act as an OAuth Client to the third party, while it remains an OAuth Resource Server to the MCP Client. It must not ask the Client to forward third-party tokens or use the Client's MCP token downstream. Form values and an earlier consent action also never authorize a Tool, object, Tenant, or side effect.
State, phishing, and failure handling
The Client treats requestState as opaque and never parses, modifies, or reuses it. The Server treats returned state as attacker-controlled and integrity-protects it when it affects identity, parameters, policy, or effects, binding it to the Principal and a short expiry. Clients validate URL schemes and destinations, resist lookalike-domain phishing, isolate parallel requests, and surface unsupported capability, decline, cancel, timeout, malformed schema, replay, and unknown external-flow outcomes distinctly.
Key Characteristics
- Client capability: the Host controls presentation and the user can accept, decline, or cancel
- Nested current flow: `elicitation/create` travels inside an MRTR `input_required` result
- Two data paths: form mode is in-band and non-secret, while URL mode is out-of-band for sensitive interaction
- Restricted form schema: flat primitive fields and enums support predictable cross-client rendering
- Opaque continuation state: the Client echoes state, while the Server protects its integrity and scope
- Separate authorization: Elicitation gathers input but never grants Tool, object, Tenant, or downstream permission
Common Use Cases
- Collecting a non-secret project name, preference, or constrained selection during a Tool call
- Requesting explicit confirmation before a workflow prepares a consequential operation
- Opening a trusted external OAuth flow without exposing third-party credentials to the MCP Client
- Directing a user to a compliant payment or secret-entry page outside model context
- Pausing an MCP Task for required input and resuming through `tasks/update`
Example
Loading code...Frequently Asked Questions
How does MCP Elicitation work in revision 2026-07-28?
The Server returns an `input_required` result with a named `elicitation/create` request. The Client presents the interaction, obtains an action and any form data, then retries the original method with a new Request ID, matching `inputResponses`, and unchanged `requestState`. No protocol Session or unsolicited Server request is required.
What is the difference between form and URL Elicitation?
Form mode collects non-secret primitive values inside the Client and exposes them to it. URL mode opens an external HTTPS destination for secrets, payments, or third-party authorization so the sensitive data does not transit through the Client or model context. Both modes must identify the requesting Server and allow refusal.
Can form Elicitation request an API key or password?
No. The specification forbids form mode for passwords, API keys, access tokens, payment credentials, and similar secrets. Use URL mode so the user enters sensitive data directly on a trusted external page, and keep that data out of MCP messages, Client logs, and model context.
Is URL Elicitation the same as MCP Authorization?
No. MCP Authorization controls the Client's access to the MCP Server. URL Elicitation supports a separate out-of-band interaction, often letting the MCP Server obtain access to a third-party service. The Server must not use token passthrough or ask the Client to provide third-party credentials.
Does accepting an Elicitation authorize a Tool action?
No. Accept means the user submitted the requested form or agreed to open the URL. The Host and Server must still authorize the exact Tool, Principal, Tenant, object, arguments, purpose, and side effect. Material changes invalidate prior consent, and a URL accept does not prove that the external flow completed.