An MCP server's scheduling tool must create events in each user's account on a third-party calendar service that uses OAuth. How should the server obtain access to that calendar?
Select an answer to reveal the explanation.
Short Explanation
Your MCP server needs its own key to the calendar, not a copy of the key you used to get into the server. URL-mode elicitation lets you sign in to the calendar directly, and the trap is token passthrough, which is flat-out forbidden.
Full Explanation
URL-mode elicitation enables a pattern in which the MCP server acts as an OAuth client to a third-party resource server. When the tool needs calendar access, the server binds the request to the user's identity, returns a URL-mode elicitation pointing to a connect page it controls, and the user completes the calendar provider's OAuth flow in the browser. The provider redirects back to the server, which exchanges the code and stores the calendar tokens bound to that user, so later calls reuse them. This third-party authorization is separate from MCP authorization between client and server. Forwarding the MCP client's token to the calendar API is token passthrough, which is forbidden; that token was issued for the MCP server's audience and the calendar should reject it. Form mode must never request passwords, API keys, tokens or payment credentials, because the values pass through the client. Having the client obtain the calendar token and send it in tool arguments exposes third-party credentials to the client and the model's context, violating the rule that they must not transit the client. Exam caveat: the server must verify that the user completing the flow is the same user who triggered it, to prevent phishing-style account takeover. Operational check: confirm calendar tokens never appear in client logs or tool arguments.