fix: use supported scopes on connection

[DaleSeo]

Motivation and Context

fixes #580

The authorization URL is missing the scope parameter, even though the protected resource metadata lists some supported scopes. This PR addresses the issue by dynamically discovering supported scopes and adding them to the URL.

How Has This Been Tested?

http://127.0.0.1:5000/.well-known/oauth-protected-resource responds with the following resource metadata:

{
  "resource": "http://127.0.0.1:5000/mcp",
  "authorization_servers": [
    "https://dev-yrrjv32vzhac3vp6.us.auth0.com/"
  ],
  "scopes_supported": [
    "email",
    "openid",
    "profile"
  ],
  "bearer_methods_supported": [
    "header"
  ]
}

• Before: The scope parameter is missing

https://dev-yrrjv32vzhac3vp6.us.auth0.com/authorize?response_type=code&client_id=9TaWMPrupmMTKHueFRLQMQpG8zWNAy6l&code_challenge=Ffmi2E3RPKo_R401PHg61xb_7ABoL5X4cudlFsgwEdg&code_challenge_method=S256&redirect_uri=http%3A%2F%2Flocalhost%3A6274%2Foauth%2Fcallback&resource=http%3A%2F%2F127.0.0.1%3A5000%2Fmcp

2025-08-12.at.10.04.19.mp4

• After: The scope parameter is set to scope=email+openid+profile

https://dev-yrrjv32vzhac3vp6.us.auth0.com/authorize?response_type=code&client_id=KTiZz01EX8sdbVdlk1pwmuqTBNaQ752K&code_challenge=PdbBCQ3MZczFSIeSHAF5smFebVyOZ0ZUlotlxLl6syI&code_challenge_method=S256&redirect_uri=http%3A%2F%2Flocalhost%3A6274%2Foauth%2Fcallback&state=4f4cf6f84c9c3e45d6d4b1ec47e1b7b6451e2411bf2e0cacddb829c5ea10ea3f&scope=email+openid+profile&resource=http%3A%2F%2F127.0.0.1%3A5000%2Fmcp

2025-08-12.at.09.58.51.mp4

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[btiernay]

👋 Hi all! Just wanted to point out I have a very similar PR in progress here, which also addresses #587 adds tests and addresses @cliffhall's suggestion to centralize some of this logic better: #701

[DaleSeo]

Hi @btiernay, thanks for the heads up but #587 looks is a separate issue from what this PR is addressing. This change adds scopes when you click on Connection in the MCP inspector, while your PR removes unnecessary scopes when using the Guided OAuth Flow. Please correct me if I misunderstood. I see the benefit of centralizing some common logic, but this issue is currently blocking some of our customers so I hope we can get this fix out independently and refactor the code later on if possible.

[btiernay]

This change adds scopes when you click on Connection in the MCP inspector, while your PR removes unnecessary scopes when using the Guided OAuth Flow.

Actually this effects useConnection as well.

[cliffhall]

@DaleSeo I believe the one in #701 is the right implementation.

oauthScope is retrieved from the local storage key lastOuthScope and stored there when oauthScope changes.

This PR: Fetches resource metadata and overrides oauthScope unconditionally with the result.

#701: Only fetches resource metadata and and uses it if oauthScope is empty.

Therefore, the previously stored scope would never be used again with this PR and would always just be the full list of reported scopes, but would be respected in #701. I'm going to close this one and we'll move ahead with the other. It should be available soon.