Remote MCP Server Support for Dynamic or On-Demand OAuth Token Grant

[Zane-XY]

With the release of VS Code 1.101, OAuth support was introduced for the remote MCP server. Currently, when starting the MCP server, the VS Code redirects to the OAuth grant application access page. After granting access, the token is stored and used for all subsequent tool calls.

However, in my use case, different tools may require different OAuth scopes, or some tools may call APIs with dynamic scope requirements. This means I often do not know the required scopes when initially creating the OAuth token, as the needed scopes may only become apparent at runtime.

Feature Request:
Is there a way to support dynamic or on-demand OAuth token grants, allowing the application to request additional scopes as needed during operation, rather than only at startup? This would greatly improve flexibility for tools with varying or unpredictable scope requirements.

[TylerLeonhardt]

Is there a way to support dynamic or on-demand OAuth token grants, allowing the application to request additional scopes as needed during operation, rather than only at startup?

I don't think this is possible from the spec perspective so we can't really do anything about this at this time.

The discussion for what that looks like is here: https://github.com/orgs/modelcontextprotocol/discussions/381

This is what you're asking for yeah?

[Zane-XY]

@TylerLeonhardt
yes, the link seems related.
My scenario is more like:

• a MCP server has 10 tools, only 1 tool may require a OAuth token
• a MCP server has different tools and each tool has different OAuth scopes
• a MCP server has a tool, the access scope can only be known at runtime. A example would be a proxy tool to call other APIs.

[TylerLeonhardt]

The problem is that with Streamable HTTP (SSE is deprecated) you're making a single connection request and keeping that connection alive. There is no way to provide feedback that your token isn't good enough or that you need to re-mint. That means OAuth isn't the solution to the problem of a tool having different auth requirements than the server holistically.