Lack of re-authorization when new scopes/permissions are required.

[mindspin311]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

One thing I've noticed is that our customers need to disconnect connectors (our HubSpot integration) on the MCP client side (i.e. Claude, ChatGPT, Gemini) and reconnect from said client to our MCP server again each time we add new features.

I didn't see any mention of "reauthorization" or anything here, so apologies if a similar topic exists.

We have pretty granular scopes that limit who can access our APIs, so that when a new feature becomes available, we'll require an additional visit to our authorization_endpoint to grant the new permissions needed. Because everyone uses an OAuth state parameter, the authorization needs to be initiated from the MCP client or they won't trust the redirect back to them. So MCP servers really need a way to tell the client that new features are available.

It appears that https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#authorization-server-discovery (https://datatracker.ietf.org/doc/html/rfc9728) may allow the ability to do this, but it really depends if the MCP clients will take a 401/WWW-Authorization response to mean that they revisit the authorization_endpoint or not. If that's the case then great! It means users can more seamlessly upgrade as more features become available, but the MCP client would need to make an API call or invoke some new tool in order to get the 401 to trigger this. Having the ability to let MCP clients know of new features and try to prompt users to re-authorize when new features are available would be even better.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other