What Is MCP Elicitation
Elicitation is a capability defined in the Model Context Protocol specification that allows an MCP server to request additional structured information from a user during an active session, rather than only at initial connection setup. The mechanism is implemented as an elicitation/create request sent from the server to the client. The client is responsible for presenting the request to the human user and returning a structured response back to the server. Elicitation requests can include a JSON schema that defines the expected structure of the requested information, allowing servers to solicit specific fields rather than open-ended text.
This distinguishes elicitation from tool-call invocation, which is typically initiated by the host or agent orchestrating a session. Elicitation is server-initiated, which introduces a second interaction channel through which an MCP server can request input from a user, separate from the tool-calling interface that security teams typically monitor most closely.
How the Request-Response Cycle Interacts With Trust Boundaries
MCP's architecture separates hosts, clients, and servers, with the client acting as the intermediary responsible for mediating and enforcing user consent for server-initiated actions, including elicitation. In a standard tool-call flow, trust boundary enforcement happens largely at session initialization, when a client authorizes a server's declared capabilities. Elicitation operates on a different timing model: because a server can trigger an elicitation/create request at any point during an already-established session, enforcement must occur continuously, per request, rather than once at connection time.
The specification's trust and safety principles reflect this by requiring clients to obtain explicit user consent before completing an elicitation exchange, rather than relying solely on prior session-level authorization. Each elicitation prompt is meant to function as a discrete consent event. If a client implementation treats session-level approval as sufficient and does not re-verify consent per request, the mid-session elicitation channel can end up operating with less oversight than the tool-call channel it sits alongside.
Security Risks Introduced by Elicitation
Three risk categories follow directly from elicitation's design and recur across the specification's own guidance and the runtime controls needed to mitigate them:
- Consent fatigue: because elicitation can be triggered repeatedly within a single session, users may approve later requests with declining scrutiny, particularly when prompts are not clearly distinguished from one another.
- Expanded data exposure: the schema-based request format allows a server to solicit specific structured fields directly from the user, through a channel that sits outside the visibility most teams apply to tool-call monitoring.
- Misattributed consent: when an elicitation prompt does not clearly disclose the requesting server's identity, a user's approval may be recorded as consent to a request whose actual source they did not fully understand.
Why These Risks Are Architectural, Not Incidental
These risks follow directly from elicitation's mid-session, server-initiated design rather than from a specific implementation defect. The specification itself anticipates part of this exposure by stating that servers must not use elicitation to request sensitive information such as passwords or credentials, and by recommending that client UIs clearly identify the requesting server and allow users to review, modify, or decline a request before submission. These are guidance provisions, not enforced runtime constraints, which means the actual risk profile of a given deployment depends heavily on how faithfully a specific client implementation applies them.
No independently confirmed public incident report or vulnerability disclosure specific to MCP elicitation exploitation has been verified within the past 12 months. The risks described here are derived primarily from the specification's own security guidance rather than documented attacks, which does not reduce their relevance but does mean enterprise risk assessment should treat them as architectural exposure to be governed proactively, not as confirmed active threats to be remediated reactively.