Advertised Connected Apps scopes are not valid

I’m working on a Remote MCP server using the Connected Apps feature for OAuth2 authentication. I’ve got it mostly working, but I’ve run into a hiccup that I believe is partially Anthropic’s fault, but perhaps also an issue with Stytch, or maybe just my Stytch project?

The advertised scopes at my project’s .well-known/oauth-authorization-server route are as follows:

...
  "scopes_supported": [
    "openid",
    "profile",
    "email",
    "phone",
    "offline_access",
    "full_access"
  ],
...

When I go to register my app as a custom connector, I’m properly redirected (after client registration) back to my app, where I have the IdentityProvider component displayed. The URL search params contain the following:

...scope=openid+profile+email+phone+offline_access+full_access...

Does Claude actually need all of those scopes? Probably not, but I don’t seem to be able to tell Claude to request fewer scopes. Regardless, you’ll note that it’s requesting all of the scopes advertised by the authorization server. However, after approving the connection request in the IdentityProvider, I’m redirected back to Claude’s callback URL with the following in the URL:

...error=invalid_scope&error_description=The+requested+scope+is+invalid...

And the integration fails to get authorized. I was able to successfully add my server by deleting the phone, offline_access, and full_access scopes from the URL before approving the request.

I noted this behavior yesterday as well with the Stytch MCP endpoint, when I tried and failed to add that to Claude. That seems to have resolved itself today, however, so I ask this:

Is there a way to restrict or alter the supported scopes advertised at my .well-known endpoints, or is there something else that I need to configure in order for the advertised scopes to be recognized as supported? Is there something else I’m missing here? I’m really not sure how to proceed.

Hello Graham !

I have a similar problem : When I add custom scopes on stytch’s dashboard, they do not appear on the .well-known/oauth-authorization-serverroute of my project. I get only the built-in ones that you showed :
“openid”, “profile”, “email”, “phone”, “offline_access”, “full_access”

Did you find a solution to your problem ?

Aymeri

Hi all,

Graham - first of all, sincerest apologies for the delayed response here. For some reason this particular Forum thread wasn’t picked up by the support software we use to centralize our support workflows. We’re investigating this to ensure it doesn’t happen again.

Scope negotiation with MCP servers varies right now depending on the client - some request the scopes they need when they navigate to the Authorization URL, others do not. There is an upcoming MCP spec due in September that should clarify scope negotiation.

In the meantime, we generally recommend setting the scopes directly in the URL query parameters from where your application hosts the Authorization URL (the <IdentityProvider /> component). This ensures that regardless of the client accessing the Authorization URL , you are setting the scopes that you want to grant.

Happy to answer any other questions about this as well, and apologies again about the delay.

Aymeri - I’ve just responded in your other thread regarding the scope bug with .well-known/oauth-authorization-server !

No worries on the delayed reply, it seems Anthropic made a change on their side and I was able to register my MCP server a couple of days after posting this thread. Regardless, your tip on setting the scopes directly is really helpful. Glad to know there’s a spec update coming to help solve this!

1 Like