Preview the action before allowing it to run
Pathak illustrates the risk with a model that, after prompt injection or confusion, calls delete_file with a path such as "../../important". He argues that the client interface is where a person should make the approval decision, while noting that servers still need a safe fallback for clients without elicitation support.
His proposed pattern gives a destructive tool two separate functions: preview explains the pending action without changing anything, while execute performs it only after approval.
The accompanying TypeScript example combines the MCP SDK with mcp-safe-actions, importing registerConfirmedTool and fileAudit. It registers delete_file as a tool for permanently deleting one file, accepts a string-valued path, and begins defining a preview summary of the deletion.
Confirmation is not the same as a security guarantee
Supabase documents a concrete use of elicitation for destructive operations. Its hosted MCP server asks users to confirm detected destructive SQL through form-mode elicitation in execute_sql and apply_migration. For execute_sql, that confirmation applies only outside read-only mode.
Supabase describes the check as a guardrail, not a security guarantee: it may miss destructive operations. Its documentation also distinguishes a server's elicitation request from the MCP client's own tool-call approval. Elicitation does not replace manual approval, and some clients have hooks or rules that can answer elicitation requests automatically.
A separate approval control is available for hosted MCP tools in the OpenAI Agents SDK. Developers can set requireApproval to "always" or supply a per-tool object assigning "never" or "always" to individual tool names. An optional onApproval callback is also supported. The default setting is "never".
How MCP carries requests for user input
The MCP specification introduced elicitation in its June 18, 2025, revision through PR #382, giving servers a way to request additional information from users during an interaction.
The protocol supports two modes. Form mode collects structured data within the interaction using a JSON schema. URL mode sends the user to an external URL for an out-of-band interaction; it was introduced in the November 25, 2025, revision.
The current draft describes elicitation within the Multi Round-Trip Requests (MRTR) pattern. An InputRequiredResult carries the elicitation request, and clients declare their elicitation capability for each request through _meta.io.modelcontextprotocol/clientCapabilities.
Approval controls and limits on sensitive data
The November 25, 2025, specification's security guidance recommends that clients provide user approval controls and let users decline elicitation requests at any time. Both provisions use the specification's SHOULD requirement level.
The rules for sensitive information are mandatory: servers MUST NOT request passwords, API keys, access tokens, or payment credentials through form-mode elicitation. Such data requires URL mode.
