Apply MCP Scope Step-Up

An MCP connection may start with enough permission to read a status record but not to export data. Asking for every possible scope at connection time makes consent hard to understand and leaves a broad token in routine use. A step-up design requests a stronger scope only when a protected tool is selected. The MCP authorization specification supports scope challenges for protected resources.

Map tools to scopes before building the challenge. Keep the map in server configuration, not in model-generated descriptions. A token with a new scope still needs the right audience, user, and tenant. The tool must re-check resource ownership after the client returns.

Tool-to-scope table

A challenge should identify the required scope without exposing private record details in an error. After consent, the client retries only the intended tool call. The server checks the new token and current authorization; it must not treat a successful consent page as proof that the requested operation is allowed.

Test the transition

Use an owned lab with synthetic accounts. Connect with a read-only token and call a read tool. Then ask for an export and confirm the server issues a scope challenge without creating an export job. Grant the scope and retry; the permitted synthetic export should work. Repeat with a rejected consent, a token for another resource, and a token that has the scope but belongs to another tenant.

Record the token scopes as names only, never bearer values. Check that retries cannot replay a previously approved write or change the target object. If the client cannot handle step-up, fail closed and provide a clear operator path; do not silently ask for a broad token during initial connection. Recheck the map when tools are added. A scope says what kind of action may be attempted, while the handler decides whether this caller may act on this object now.