An MCP server needs the user's API key for a third-party service and later a card payment, and neither must ever be visible to the MCP client or the model. How should the server collect them?
Select an answer to reveal the explanation.
Short Explanation
Some things you only type at the bank's own window, never into the chat. URL-mode elicitation is that window, and the trap is form mode, which the spec forbids for passwords, keys and payment details.
Full Explanation
Elicitation has two modes. Form mode collects structured data in band, so whatever the user enters is exposed to the client; the specification states that servers must not use form mode for sensitive information such as passwords, API keys, access tokens or payment credentials, and must use URL mode for those interactions. In URL mode the server returns an elicitation request carrying a URL; the client shows the full URL, highlights the domain, gets explicit consent, and opens it without prefetching or inspecting the page. The user enters the key or card details directly on a page the server controls, and the server stores the result bound to the user's identity, so nothing transits the client or the model's context. Masking a form field does not change who receives the value, since the client still handles it. A tool argument would put the secret into model-generated parameters and conversation context, the exact exposure to avoid. Resources are read through resources/read; MCP defines no mechanism for a client to post user secrets into a resource. Exam caveat: URL mode is for the server's needs, such as third-party credentials, and never replaces MCP authorization between the client and the server. Operational check: confirm the client declares URL elicitation support and that the stored secret never appears in client logs.