A database MCP server needs the user's database password before it can run a query, so it returns an InputRequiredResult whose form-mode elicitation contains a password field. A security reviewer rejects the design. What should the server do instead?
Select an answer to reveal the explanation.
Short Explanation
Here's the rule you can't bend: secrets never go through a form. A form-mode answer flows straight through the client, so the password would sit right where logs and the model can see it. You send the user off to a secure web page with URL mode instead, and the client only ever sees the link.
Full Explanation
The elicitation specification states that servers MUST NOT use form-mode elicitation to request sensitive information such as passwords, API keys, access tokens or payment credentials, and MUST use URL mode for those interactions. In form mode the submitted data is exposed to the client, which means it can reach client logs, intermediaries and potentially the model's context. URL mode directs the user to an HTTPS page the server controls; the client returns only an accept action, and the credential is stored by the server and bound to the user's identity. Masking the input with a format does not change where the value travels, and the form schema's supported string formats are email, uri, date and date-time, so a password format is not even part of the restricted schema. Asking the client to scrub the value after the fact relies on cooperative behavior and still sends the secret through the client. Putting the password in a tool argument is worse, because the model would have to see and emit the secret. Exam caveat: names, email addresses and usernames are not categorically prohibited in form mode. Operational check: review every requestedSchema the server emits and confirm none asks for a secret, and that credential collection uses mode "url" with an HTTPS page.