Why does the Supabase MCP server lack dedicated tools for RLS policies, triggers, and functions?

[hasithasandunlakshan]

Hi everyone,

I noticed the Supabase MCP server has tools like list_tables and list_migrations, but doesn't have dedicated tools to fetch RLS policies, triggers, or custom functions.
Was leaving these out a deliberate design choice to avoid tool bloat, or are there plans to add native tools for them in the future?. Thanks!

[harshagarwalnyu]

This was a deliberate design decision — the MCP was built to avoid tool proliferation by providing execute_sql as a universal escape hatch.

The core philosophy: RLS policies, triggers, and functions are all queryable through standard PostgreSQL system catalogs, so adding dedicated MCP tools would create 20+ specialized tools that each do one thing. The team chose depth (SQL power) over breadth (tool per operation).

How to access each via execute_sql today:

RLS policies:

SELECT schemaname, tablename, policyname, permissive, roles, cmd, qual, with_check
FROM pg_policies
WHERE schemaname = 'public'
ORDER BY tablename, policyname;

Triggers:

SELECT trigger_name, event_manipulation, event_object_table, action_timing, action_statement
FROM information_schema.triggers
WHERE trigger_schema = 'public';

Custom functions:

SELECT routine_name, routine_type, data_type, routine_definition
FROM information_schema.routines
WHERE routine_schema = 'public'
  AND routine_type = 'FUNCTION';

Are dedicated tools planned?

There are open issues on the MCP repo requesting list_policies, list_triggers, etc. The current direction appears to be a middle ground: higher-level tools for the most common LLM-assisted operations (like apply_migration) while keeping execute_sql for everything else. No concrete timeline has been announced for dedicated RLS/trigger/function tools as of now.

If you're building something that needs these frequently, wrapping execute_sql in your own prompt template or a thin tool on top of the MCP is a viable pattern until native tools land.