A remote MCP server must call a third-party calendar API on the user's behalf and therefore needs the user's authorization for that API. Which approach keeps the specification's security boundary intact?
Select an answer to reveal the explanation.
Short Explanation
The calendar credentials are the server's business, not the client's. With URL mode, you send the user to sign in directly with the calendar service, and the client never touches the keys. Forwarding the client's token is the classic trap, and it's forbidden.
Full Explanation
URL-mode elicitation lets an MCP server act as an OAuth client to a third-party service. The server returns an InputRequiredResult with a URL-mode elicitation request, the client shows the full URL and asks consent, and the user completes the authorization out of band, directly with the third party. The specification sets firm rules: third-party credentials must not transit the MCP client; the server must not use the client's credentials for the third-party service, which would be token passthrough; the user must authorize the server directly; and the server stores and manages the resulting tokens, bound to the user's identity. Collecting the API key through form mode fails because servers must not use form mode for API keys, tokens or other credentials, and masking does not change that the client sees the data. Forwarding the client's bearer token fails by concept: that token was issued for the MCP server as audience, and passing it downstream is token passthrough, which is forbidden. Having the client hold the key and send it in _meta fails because the credential would transit and be stored by the client, crossing the boundary URL mode exists to protect. Exam caveat: this third-party authorization is separate from MCP authorization; the client's bearer token for the MCP server remains unchanged. Operational check: complete the flow and confirm no calendar credential appears in client logs or messages.