Add configuration option to control which tools are exposed to MCP clients

[aneym]

Additional context

When using multiple MCP servers together (Supabase plus others), the combined number of tools can exceed Cursor's 40-tool limit. This feature would help users prioritize which tools are most important for their workflow.

Benefits:

• Ensures critical tools are available to the agent when using multiple MCP servers
• • Reduces confusion when tools appear in the list but aren't actually available
• • • Allows users to customize their MCP experience based on their specific needs References:
• Cursor MCP Documentation
• • Current limitation: "Cursor will only send the first 40 tools to the Agent"

[gregnr]

Thanks for the suggestion @afneyman. Agreed - I've given this one a little bit of thought previously and am leaning towards grouping tools into "feature groups" where related tools are grouped together and you can optionally enable specific groups. Eg.

npx -y @supabase/mcp-server-supabase --features=['database', 'project', 'branching']

Another thing we're looking into is a "scoped" mode, where the MCP server is scoped only to a single project at a time. If we were to introduce this mode, we would likely strip out up to 9 tools that are project management related (if you were to choose this mode).

Would love to hear any other opinions/ideas too.

[pgroth]

We would very much like a scoped mode only for a single project and all not having to provide an access token. Maybe using the api tokens already provided by Supabase. This would let us more safely provide access to the "data" parts of our database in a read only mode. Thanks!

[gregnr]

@pgroth I should have updated this thread - we've supported project scoped mode since 0.4.0! Docs can be found here: https://github.com/supabase-community/supabase-mcp#project-scoped-mode

Read only mode is also supported, docs here: https://github.com/supabase-community/supabase-mcp#read-only-mode

[pgroth]

Thanks @gregnr . I've actually using that but I guess I want it in the hosted supabase service. Providing the access token seems a bit unsafe. But maybe I should bring that up with the service.

[gregnr]

@pgroth Can you clarify what you mean by wanting it in the hosted supabase service? Currently personal access tokens provide account level access - do you mean you wish for PATs to offer more fine-grain scoping?

[pgroth]

@gregnr the use case I was thinking about is to provide our customers direct MCP access to our database through some sort of token. I would only want them to have read access to particular tables.

This is not the use case that I think PAT and the current Supabase MCP is aimed at supporting as far as I understand. But maybe that's not for this issue or even this library?

[dticson]

I typically use supabase with data that i would prefer not to send to ai tools, but the table definitions and other things like functions are fair game. I'd love to see a mode that limits access to data universally or on specific tables.

[gregnr]

We now support controlling which tools are exposed via feature groups.

For discussions on fine-grain scoping on the token level, see https://github.com/supabase-community/supabase-mcp/issues/93.

[pgroth]

That's great on both fronts. Thank you!