For an MCP server, start clients with a small set of low-risk scopes and ask for more only when a privileged tool is first used. The official security guidance warns that broad, wildcard or catalog-wide scopes enlarge the damage from any leaked token and make audit trails hard to read.
The failure pattern
The MCP security best practices page describes how this goes wrong. A server lists every scope it supports, the client requests them all, and the user approves a long list. Later an attacker gets the token through log leakage, memory scraping or local interception. With broad scopes such as file, database or admin wildcards, the token allows lateral access and is painful to revoke without disrupting all workflows.
The page lists further risks: audit noise when one omnibus scope hides what the user intended, privilege chaining, and consent abandonment when people decline dialogs that list too much.
The recommended model
Build progressive, least-privilege scopes:
- A minimal initial scope for discovery and read operations, for example a basic tools scope.
- Incremental elevation: when a privileged operation is first attempted, the server answers with a challenge naming the scope it needs.
- Tolerance for down-scoping: the server should accept tokens with fewer scopes, and the authorization server may grant a subset of what was requested.
The page also says servers should log elevation events, including what was requested and what was granted, with correlation IDs.
How specific should a challenge be?
The guidance gives three options. The minimum approach names only the scopes required for the failing operation. The recommended approach adds related scopes that commonly go together, to cut the number of step-up rounds. The extended approach also includes scopes the server expects the client to need soon. The choice trades user friction against exposure.
Client side
Clients should begin with baseline scopes and cache recent failures to avoid elevation loops for denied scopes. They should also combine previously requested scopes with newly challenged ones when re-authorizing, so earlier grants are not lost.
One caveat in the docs: when the first challenge carries no scope, the scope selection strategy tells clients to fall back to requesting all scopes the server lists. That is why a server's published scope list should itself be small.
Common mistakes to avoid
- Publishing all possible scopes in the supported list.
- Wildcard or all-access scopes.
- Bundling unrelated privileges to avoid future prompts.
- Returning the entire catalog in every challenge.
- Changing scope meaning silently without versioning.
- Trusting scope claims in a token without server-side authorization logic.
Pair scopes with tool design
Split read tools and write tools so they map to different scopes. A tool that both reads and deletes forces a broad scope. See MCP server authorization patterns.
Quick check
Should a server list all scopes in its metadata?
No. Listing everything leads clients to request everything. Keep the supported list small and challenge for more when needed.
Does a valid token mean the call is allowed?
No. The server must still check authorization for the operation, not just trust scope claims.
Sources
Last reviewed: 19 October 2026.
