fix: set user specified scope in DCR

[stdevi]

Set user specified scope for dynamically registered client and authorization code retrieval.

Motivation and Context

Currently user specified scopes are ignored.
See #863.

How Has This Been Tested?

Tested with Linear MCP.

Breaking Changes

No 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

[cliffhall]

Hi @stdevi

It would be helpful if you could provide before and after screenshots showing the affected parts of the OAuth debugger when running both Quick and Guided Flows, well as the network tab when running without the OAuth debugger and just using the Connect button.

[stdevi]

@cliffhall sure, there are screenshots.

Guided Flows

Before

Scope is not included in the client registration request:

Scope is not included in the authorisation URL:

After

Scope is included in the client registration request:

Scope is included in the authorisation URL:

Quick Flows

Before

Scope is not included in the authorisation URL:

After

Running without the OAuth debugger

Before

After

[cliffhall]

@stdevi Thanks for the follow up. However, those last two screenshots (of just using the connect button) look the same. They don't reveal whether the scope was sent or not. We need to see the headers. If you open the network tab on the right instead of the bottom, we'll be able to see all the headers and you can point out the before and after showing that scope was sent.

[stdevi]

@cliffhall But "scope" parameter is not required in the Access Token Request https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3

[cliffhall]

But "scope" parameter is not required in the Access Token Request

@stdevi It was just an example to show you how to display all the headers and request data.

[stdevi]

@cliffhall but do we expect to see the "scope" header in the request to /mcp then? I assume that only Authorization Bearer header depends on the OAuth and previously specified scope, but this PR does not affect the bearer.

[cliffhall]

but do we expect to see the "scope" header in the request to /mcp then? I assume that only Authorization Bearer header depends on the OAuth and previously specified scope, but this PR does not affect the bearer.

It should be in the authorization URL as well as the returned access token. You have to select it in the network tab to see the details.

[stdevi]

Got it, here are screenshots for the authorisation request.

Before

After

---

But it's problematic to provide screenshots for the token request as MCP servers (including the example-server.modelcontextprotocol.io) often do not return the scope in the token response or return default scopes set by MCP servers, ignoring the provided one.

[cliffhall]

But it's problematic to provide screenshots for the token request as MCP servers (including the example-server.modelcontextprotocol.io) often do not return the scope in the token response or return default scopes set by MCP servers, ignoring the provided one.

In that last screenshot if you open the disclosure widget in the last step of the OAuth flow you should see the scope:

[stdevi]

Even though the client was correctly registered with a specific scope, the token response may not necessarily include it, as per RFC 6749, which states that the scope parameter in the token response is optional.

[cliffhall]

Where is this constant being used? I don't see it in any of the changes.