Minimize MCP Client Scopes

A first connection often asks for more authority than the first task needs. A client that only reads a project summary should not receive export, write, or administration scopes because those scopes might be useful later. The MCP authorization specification describes resource and scope handling for HTTP transports; the product must still choose a narrow initial grant.

Start with the user journey that brings a client to the server. List the first three tasks a new connection must complete. Assign only the scopes needed for those tasks. Do not infer need from every tool in the catalog, since many tools may be unavailable to this user or disabled for this launch.

Initial-scope decision record

A broad all scope hides the distinction between reading one record and changing an account. Prefer resource-specific scopes that handlers can enforce. If an upstream provider supplies only broad scopes, record that constraint and add server-side checks. Do not advertise a narrow grant if the token is still accepted by unrelated upstream routes.

Measure unused authority

In a synthetic account, complete the normal first-run task with the proposed scope set. Remove one scope at a time until the task fails. Keep the last set that still supports the legitimate workflow. Then try a protected tool and verify it is denied without side effects. Test another tenant's object as a separate authorization check.

After a period of use, compare granted scopes with actual tool calls through redacted audit events. Remove unused scopes at renewal where the provider supports it, and ask for fresh consent when access grows. Do not collect raw tokens to perform this review. A narrow initial scope reduces exposure, but it does not solve unsafe tool arguments or prompt injection. Revisit the decision whenever a new tool is exposed or the server changes its resource model.