No. The MCP specification says servers must not use form mode elicitation to request passwords, API keys, access tokens or payment credentials. Those requests must use URL mode, which sends the user to a web page outside the client, so the secret never passes through the client or the model context.
What elicitation is
Elicitation is the way an MCP server asks the user for more information in the middle of a tool call. Instead of guessing, the server sends a request through the client, the client shows it to the person, and the person accepts, declines or cancels.
There are two modes. Form mode collects structured data inside the client. URL mode sends the user to an external address for anything sensitive. URL mode was introduced in the 2025-11-25 revision of the spec, and the details below come from the current draft, so check the revision your client implements.
Form mode versus URL mode
| Form mode | URL mode | |
|---|---|---|
| Where the user types | Inside the MCP client | On a web page in the browser |
| Does the client see the data | Yes | No, only the URL |
| Allowed for passwords and API keys | No | Yes, this is the required path |
| Fine for | Names, emails, simple choices | Credentials, payments, third-party sign-in |
The spec describes URL mode as the right place for an API key, an OAuth flow with a third party, or a payment. Credentials entered there are stored by the server, bound to the user, and never travel through the client or the model.
What a client has to do
The draft sets firm rules for clients. They must show which server is asking, offer clear decline and cancel options, and let the user review and edit form answers before sending. For URL mode they must show the full address, ask for consent before opening it, and avoid pre-fetching it.
They must also open the page in a way that does not let the client or the model read what the user types. The spec suggests highlighting the domain to catch lookalike hostnames and warning on suspicious addresses, such as ones containing Punycode.
What a server has to do
A server must not put sensitive user data in the URL, and must not send a pre-authenticated URL that could let a different person act as the user. It must also confirm that the person who opens the link is the same person who started the request. The spec walks through a phishing case where a victim completes someone else's OAuth flow and the tokens get bound to the attacker.
A quick review for your team
- List MCP servers that prompt for input and note which ones ask for secrets.
- Reject any server that asks for a key in a plain form or in chat.
- Check that URL prompts show a domain you recognise before you click.
- Prefer environment based or vault based credentials for local servers.
Safeguard includes agent identity and policies, gates and guardrails for agent access, plus a free scan at https://gold.safeguard.sh/scan.
Quick check
Is a chat message asking for my key the same as elicitation?
No. Elicitation is a protocol feature with a visible prompt from a named server. A model asking you to paste a secret into chat is a separate risk, and you should decline it.
Does URL mode make the server trustworthy?
No. It only keeps the secret away from the client and the model. You still decide whether to trust the server that receives it.
Sources
Last reviewed: 19 October 2026.
