A client receives its first 401 from a remote MCP server. The WWW-Authenticate header includes scope="files:read", and the Protected Resource Metadata lists several values in scopes_supported. Which scopes should the client request first?
Select an answer to reveal the explanation.
Short Explanation
The 401 is the server telling you exactly what it needs right now: files:read. Ask for that and nothing more. Least privilege beats grabbing every scope "just in case," and you shouldn't second-guess the challenge against the published list.
Full Explanation
The scope selection strategy says MCP servers should include a scope parameter in the WWW-Authenticate challenge to show the scopes required for the resource, and clients must treat challenged scopes as authoritative for the current operation. During initial authorization, clients should first use the scope parameter from the 401's WWW-Authenticate header if provided; if it is absent, they should use all scopes in scopes_supported from Protected Resource Metadata. scopes_supported is meant to be the minimal set for basic functionality, with more scopes requested incrementally through step-up authorization. Requesting every scope the authorization server knows fails by concept: it violates least privilege, and the authorization server's list covers many resources, not just this server. Requesting scopes_supported and keeping the challenge only if it is a subset fails because clients must not assume any set relationship between challenged scopes and scopes_supported; the challenge may be a subset, superset or neither, and it is authoritative. Requesting nothing and collecting scopes from successive 403s fails because a provided challenge scope is the first choice, and servers should put all needed scopes into one challenge rather than drip-feeding them. Exam caveat: servers should not put offline_access in challenges or scopes_supported. Operational check: inspect the first authorization request and confirm its scope equals files:read.