MCP should request minimum OAuth scopes based on active tools instead of requiring full account access

[zaniluca]

Feature request

Is your feature request related to a problem? Please describe.

When authenticating with the Supabase MCP, users are prompted to grant broad account-level OAuth permissions regardless of which tools they actually need. If I only want to use documentation tools, I still have to authorize access to my Supabase projects and organization, which I shouldn't need at all.

For example, an MCP configured with this URL

https://mcp.supabase.com/mcp?read_only=true&features=docs

Still requires me to give out a crazy amount of permissions, just to use it for the docs.

Permissions requested by the https://mcp.supabase.com/mcp?read_only=true&features=docs MCP

Describe the solution you'd like

The OAuth authentication flow should calculate the minimum set of scopes required based on the tools the MCP client is actually using, and request only those.

Tools that don't interact with the Supabase API (like get_docs) should require zero permissions and ideally bypass the auth step entirely.

Describe alternatives you've considered

• Separate MCP servers: one for docs (no auth) and one for project management (full auth).
• Manual scope selection: let users pick scopes at auth time. Better than the current state but still puts the burden on the user instead of the server.
• Using the local MCP: for docs I ended up using the local MCP server by having my local supabase instance running and doing

{
  "mcpServers": {
    // ...
    "supabase-docs": {
      "type": "http",
      "url": "http://localhost:54321/mcp?read_only=true&features=docs"
    }
  }
}

Although this works, it requires users to have a running Supabase instance, which creates unnecessary friction.

Additional context

• Issue #152 identified a similar problem in the opposite direction: list_tables was requesting database:write when it only needs database:read. This feature request generalizes that principle: each tool should declare its required scopes, and the auth flow should aggregate only what's needed
• This generalizes the approach in AI-492 (read-only mode) by making it scope-aware: enable fine-grained opt-in rather than all-or-nothing.

[ViVaLaDaniel]

Hi, I'd like to work on this if it's still open.

I've been working heavily with MCP setups, auth boundaries, and scope minimization in practice, and this issue looks like a strong fit.

My proposed approach:

1. map tools and enabled features to required OAuth scopes
2. aggregate only the minimum scopes needed for the active configuration
3. ensure docs-only mode can bypass unnecessary project or account access if that is technically feasible
4. add tests around scope calculation so the behavior stays explicit

If this direction matches your expectations, I can open a PR.