A server publishes every scope it has, including admin scopes, in scopes_supported and sends no scope in its 401 challenges, so clients request all of them up front. Which design change follows MCP's scope minimization guidance?
Select an answer to reveal the explanation.
Short Explanation
Handing out the master key on day one is convenient right up until someone copies it. You start everyone with a small key ring and add a key only when they actually walk up to a locked door. An omnibus scope is the same master key with a nicer name.
Full Explanation
The security best practices on scope minimization describe this exact failure: an attacker obtains a token carrying broad scopes that were granted up front because the server exposed every scope in scopes_supported and the client requested them all. Clients that receive no scope in the WWW-Authenticate challenge fall back to all of scopes_supported, which is why scopes_supported is meant to represent the minimal set for basic functionality. The recommended model is a minimal initial scope set for low-risk discovery and read operations, with incremental elevation through targeted WWW-Authenticate scope challenges when privileged operations are first attempted, and down-scoping tolerance on the server. Collapsing everything into one full-access scope is listed among the common mistakes; it widens the blast radius of a stolen token and makes audit trails meaningless. Having clients drop previously declined scopes is not a server design fix and leaves the admin scopes in the default request. Tool annotations are untrusted hints for user experience, not an authorization mechanism. Exam caveat: on step-up the client requests the union of previously requested and newly challenged scopes so it does not lose earlier permissions. Operational check: inspect scopes_supported and confirm no admin or write scope appears there, then trigger a privileged tool and confirm a 403 insufficient_scope challenge.