Wiki · Concept · Last reviewed June 25, 2026

MCP Elicitation

MCP elicitation is the Model Context Protocol feature that lets a server ask the user for additional information through the client, while preserving explicit consent and separating user input from model inference.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Elicitation, AI Agents, User Consent, Agent Security

Definition

MCP elicitation is a client capability in the Model Context Protocol that lets an MCP server request additional information from the user during an interaction. The server sends an elicitation/create request; the client presents the request to the user; the user can accept, decline, or cancel; and the result returns through the protocol only according to the chosen mode.

This is not the same as capability elicitation in model evaluation. In MCP, elicitation is an interaction primitive: a way for a tool server to ask a human for a missing preference, identifier, confirmation detail, or authorization path without pretending the model already knows it.

How It Works

The 2025-11-25 MCP specification, the current version reviewed for this entry, defines two elicitation modes: form mode and URL mode. A client that supports elicitation declares an elicitation capability during initialization and must support at least one of those modes. Servers are not allowed to send elicitation requests for modes the client did not declare.

The lifecycle matters because elicitation is negotiated before ordinary operation. A server cannot assume that every client can render a form, handle a URL handoff, display the requesting server clearly, or preserve the consent state needed for a safe workflow.

Form Mode

Form mode is for structured in-band user input. The server supplies a human-readable message and a requestedSchema so the client can render a bounded form and validate the response. The current spec intentionally limits form schemas to flat objects with primitive properties such as strings, numbers, booleans, and enums, including single-select and multi-select options.

The security boundary is explicit: form mode must not be used to request sensitive secrets such as passwords, API keys, access tokens, or payment credentials. The client must make clear which server is asking, let the user review and modify form responses before sending, and provide decline and cancel options. That makes form mode useful for low-risk data collection, not for credential transfer.

URL Mode

URL mode was added in the 2025-11-25 specification. It is for out-of-band interactions that should not pass through the MCP client, such as external authorization, payment flows, or secure entry of sensitive credentials. In URL mode, the client receives a URL and user-facing message, but the sensitive data entered at that destination is not returned through the MCP client or language-model context.

The spec is strict about URL handling. Clients must show the full URL before consent, must not automatically prefetch the URL or metadata, and must not open it without explicit user consent. Servers must not place sensitive end-user information in the URL, must not send pre-authenticated URLs that would let a malicious client impersonate the user, and should use HTTPS outside development environments.

URL mode also separates MCP authorization from third-party authorization. If an MCP server needs access to a third-party API, it must not use the MCP client's credentials for that service, and third-party credentials must not pass through the MCP client. The server becomes responsible for securely storing any third-party tokens it obtains and binding them to the correct user identity.

Governance Requirements

A governed deployment should treat each elicitation request as an auditable consent event. Logs should record the server identity, request mode, message shown, schema or URL metadata, user action, timestamp, client version, and whether any later tool call depended on the elicited state. The log should avoid storing sensitive form contents beyond what policy permits.

Client UX is a control surface. The user should see which server is asking, why the request matters, what will be sent, and what happens if they decline. In URL mode, domain highlighting, suspicious-URI warnings, and non-shell URL opening are not cosmetic details; they are part of the security boundary.

Failure Modes

Consent laundering. A model or server can frame a request so that the user approves a broad action without understanding which server, tool, or external system benefits.

Form-mode secret capture. A malicious or careless server can ask for credentials through a form, causing secrets to pass through client UI, logs, or model-visible context.

URL phishing. URL mode can be abused if clients hide the destination, prefetch content, open URLs automatically, or fail to warn about ambiguous domains.

Identity confusion. The spec warns that servers must bind elicitation requests to the client and user identity. If a URL generated for one user is completed by another, tokens can be bound to the wrong session.

Source Discipline

Claims about MCP elicitation should name the protocol version, because the feature changed between the 2025-06-18 and 2025-11-25 specifications. The changelog identifies URL mode elicitation as a 2025-11-25 addition. Security claims should cite the elicitation page, lifecycle negotiation page, MCP security best practices, and authorization guidance rather than client marketing copy.

Spiralist Reading

MCP elicitation is a small refusal of magical automation.

Instead of allowing the agent to invent missing authority, the protocol gives the system a way to stop and ask. That pause is valuable only if the user can see who is asking, what is being requested, and where the answer will travel.

The Spiralist discipline is to preserve the pause. A consent dialog that cannot be declined is a ritual of obedience. A protocol field that records refusal is a tiny civic organ inside the machine.

Open Questions

Sources

Return to Wiki