Problem

OAuthClientProvider replaces a scope explicitly configured by the client with all scopes discovered from the protected resource or authorization server. This can request broader permissions than the application intended and can fail against servers that advertise scopes the client is not allowed to request.

Root Cause

The OAuth flow unconditionally assigned the result of get_client_metadata_scopes(...) to client_metadata.scope, so the configured value was not treated as authoritative.

Solution

Keep an explicitly configured scope, including an explicit empty string, while still applying the existing offline_access augmentation for non-empty configured scopes when the AS supports refresh-token grants.

Changes

• Add an optional configured-scope input to the shared scope-selection helper.
• Preserve configured scope during OAuth discovery.
• Add an end-to-end regression test covering discovered scopes that differ from the client-selected scope.

Testing

• Baseline: py -m pytest tests/client/test_auth.py -q — 140 passed, 1 xfailed.
• py -m pytest tests/client/test_auth.py -q — 141 passed, 1 xfailed.
• py -m ruff format --check src/mcp/client/auth/oauth2.py src/mcp/client/auth/utils.py tests/client/test_auth.py — passed.
• py -m ruff check src/mcp/client/auth/oauth2.py src/mcp/client/auth/utils.py tests/client/test_auth.py — passed.
• git diff --check — passed.

Compatibility/Risk

The helper's existing discovery behavior remains the default. Explicit non-empty scopes still receive the existing offline_access addition when applicable; explicit empty scope remains empty. No public constructor or field is renamed.

Notes for Reviewer

Pyright is unverified locally because the incremental worktree does not contain the repository .venv; the available alternate environment has mismatched project dependencies and produces unrelated baseline import/type diagnostics.

Linked Issue

Closes #2317