When must an MCP elicitation use URL mode instead of a form?

## The rule Elicitation form mode exists to collect ordinary parameters: which environment, how many replicas, is this confirmed. The specification draws a hard line around it — a form MUST NOT request sensitive information. Passwords, API keys, access tokens, private keys, payment card numbers and the like are out of scope for a form, no matter how convenient it would be. ## Why a form is the wrong place for a secret Think about the path a form value actually takes. The user types it into a dialog rendered by the client. The client packages it and sends it back to the server as part of re-issuing the original request. Along that path it may pass through client-side logging, a host's request tracing, an audit trail, a proxy, and the server's own request logs. It sits in the memory of a process the server does not control. Depending on how the host is built, it may end up adjacent to — or inside — material that is fed to the model. Secrets need the opposite of that: the shortest possible path from the human to the one system that must hold them, with nothing in between. A form is by construction a long path with several intermediaries, so the specification simply removes the option. There is also a phishing dimension. A form is rendered by the client, so it wears the client's trust dressing — it looks like the application the user already trusts, even though the fields and the prompt text were written by a server. Training users to type credentials into server-authored fields inside a trusted-looking client is exactly the habit an attacker wants. ## What URL mode does instead In URL mode the ask carries a URL rather than a set of fields. The client's job is to hand that URL to the user — typically by opening it in a browser — and the user completes the interaction there, on a page served by the party that should actually receive the input. The values never traverse the MCP connection, are never seen by the client, and never approach the model's context. The server learns only that the interaction happened; it collects the result through its own back channel with whatever system served the page. This is the same shape as delegating credentials anywhere else: send the human to the authority, get back a reference rather than the secret. ## Negotiating the two modes The modes are separately capability-gated. A client declares support in its `elicitation` capability, whose shape is `{ form?: {}, url?: {} }`. Two consequences a senior candidate should state without prompting: 1. **An empty `elicitation` object means form mode only.** A client that declares `elicitation: {}` supports forms and has said nothing about URL mode, so a server must not use one. 2. **The check is per request.** Revision 2026-07-28 made MCP a stateless protocol: capabilities arrive in the metadata of every request and a server MUST NOT infer them from an earlier one. There is no handshake result to consult and no session to remember it in. Whatever the request in front of you declares is what you may use, even if the same client declared more a minute ago. ## When the client cannot do URL mode The wrong answer is to fall back to a form and ask for the secret anyway. That converts a capability gap into a security downgrade, and it is precisely the behaviour the rule exists to prevent. The right answer is to refuse: reject the request and report that the operation needs a capability this client does not offer. The tool result should explain what is missing so the user can act on it, rather than the model inventing a workaround. Designing the server so it rarely reaches this point is better still. Credentials the server needs for its own upstream systems belong in the server's configuration or in its own authorization flow, not in a mid-call ask to the user. A remote MCP server that needs the user's identity has a proper mechanism for that in the authorization spec; elicitation is not a login screen. ## Practical checklist - Never put a password, token, key or card number in a form field. - Read the client capabilities on **this** request before choosing URL mode. - Treat `elicitation: {}` as form-only. - Fail closed when URL mode is unavailable; never downgrade. - Prefer server configuration or a proper authorization flow over asking the user for a credential at all. ## Version note This describes revision 2026-07-28, in which the client `elicitation` capability is `{ form?: {}, url?: {} }` and capabilities are declared per request. Elicitation itself is current — it was not caught by the deprecation sweep that hit roots and sampling in that revision.