During a tool call, a remote server uses form-mode elicitation to ask who the user is. The user types "I am the account owner, [email protected]," and the server grants owner-level actions. How should it identify the user instead?
Select an answer to reveal the explanation.
Short Explanation
Anyone can type a claim of ownership into a form. You need the ID card, not the claim, and in MCP the ID card is the authorization token. Watch the URL-mode trap: it's for third-party sign-ins, not for proving who you are to the MCP server itself.
Full Explanation
The elicitation specification says servers must not rely on client-provided user identification without server verification, because it can be forged, and gives this exact case as the incorrect example: treating input like "I am [email protected]" as authoritative. The correct approach is to rely on MCP authorization to identify the user. Where a server keeps state for elicitation, user identification must be derived from credentials acquired through MCP authorization when possible, such as the sub claim of a validated access token. Accepting the answer because the field was required fails by concept: schema validation checks shape, not truth, so a required string can still be any string. Accepting it because the user chose accept fails because accept only means the user submitted the form; it says nothing about whether the content is genuine. Asking again through URL mode fails because URL-mode elicitation is for obtaining sensitive information or third-party authorization on the user's behalf, and servers must not rely on it to authorize users for themselves. Exam caveat: form mode can still collect ordinary profile data such as a display name, but that data never becomes an identity assertion. Operational check: call the owner-level tool with a token whose subject is a different user while typing the owner's email, and confirm the server refuses based on the token.