A code review finds a client that calls a remote MCP server at https://mcp.example.com/mcp?access_token=... rather than using a header. What does the authorization specification require?
Select an answer to reveal the explanation.
Short Explanation
URLs leak everywhere: logs, browser history, proxy records. So your tokens ride in the Authorization header, on every single call. And forget "authenticate once"; MCP's stateless now, so there's no session to coast on.
Full Explanation
The authorization specification requires access token handling to follow OAuth 2.1 bearer token usage. The client must use the Authorization request header field in the form Authorization: Bearer followed by the token, authorization must be included in every HTTP request from client to server, and access tokens must not be included in the URI query string. Query strings are routinely written to server logs, proxy and gateway records, and monitoring tools, so a token placed there spreads far beyond the request that carried it. Keeping the query string because TLS encrypts it fails by concept: TLS protects the URL in transit, but the endpoints and intermediaries that terminate TLS still log full URLs, which is the exposure the rule addresses. Sending the token only once and relying on a session fails because every request must carry authorization; revision 2026-07-28 is stateless with no protocol sessions, and each request is authorized independently. Moving the token into _meta fails because _meta carries protocol metadata such as protocolVersion, clientCapabilities and clientInfo, and the specification places credentials in the HTTP Authorization header, where the server's resource-server logic validates them. Exam caveat: on a missing or invalid token the server answers 401 with a WWW-Authenticate challenge pointing to its resource metadata. Operational check: capture several requests and confirm each has the Authorization header and no token in its URL.