Why does supabase MCP server list_tables RLS advisory only cover the public schema?
In @supabase/mcp-server-supabase 0.11.0 over stdio (MCP client @modelcontextprotocol/client, against a supabase start Postgres database), list_tables says schemas 'Defaults to all schemas' but its default is ["public"] and schemas is listed as required. With 4 RLS-disabled tables across public and billing, the attached rls_disabled advisory reports only '2 table(s) have RLS disabled: public.users, public.posts'. Is this a known bug, and how do I get a full-database RLS advisory?
Originally asked on GitHub: https://github.com/supabase/mcp/issues/395
4 answers
Open as of the last comment (2026-10-15); no maintainer response or fix appears in the thread. The root cause is a contract mismatch in the list_tables tool definition of @supabase/mcp-server-supabase 0.11.0: the description says schemas 'Defaults to all schemas', the JSON Schema default is ["public"], and schemas is listed in required, so a schema-honoring client cannot omit it. The reporter states that the value which actually means all schemas is the empty array [], and that it is documented nowhere. Since #251, list_tables attaches an rls_disabled advisory built only from the tables it returned, so with 4 RLS-disabled tables across public and billing, omitting schemas or passing ["public"] yields an advisory that says '2 table(s) have RLS disabled' with no scope caveat in the response.
The thread contains no tested workaround. A commenter suggested two possible fixes, neither implemented: when schemas is omitted, query information_schema.schemata or exclude system schemas to get full coverage; or change the tool's JSON Schema to explicitly declare default: ["public"] so agents do not infer full database coverage. The reporter identified [] as the undocumented value meaning all schemas, but no one in the thread confirmed that passing it produces a correct advisory.
General advice: before trusting the advisory count as a full-database result, check which schemas the tool actually returned. Security note: an RLS advisory built from a partial schema list under-reports tables exposed to the anon and authenticated roles.
Did this work for you?What a GitHub user tried on GitHub (Didn't work)
Reproduced with @supabase/mcp-server-supabase 0.11.0 over stdio against a stock supabase start database: created 4 RLS-disabled user tables across public and billing, then called list_tables omitting schemas or with ["public"]; the rls_disabled advisory reported only the 2 public tables (public.users, public.posts) instead of all 4.
Source: https://github.com/supabase/mcp/issues/395 (opens external site)
Did this work for you?What @genesiscode2026 tried on GitHub (Outcome unclear)
Suggested resolving the mismatch by having list_tables query information_schema.schemata (or filter out system schemas) when schemas is omitted, or by declaring default: ["public"] in the tool's JSON Schema; neither change was implemented in the thread.
Source: https://github.com/supabase/mcp/issues/395#issuecomment-5857634594 (opens external site)
Did this work for you?What @camerontjs-dot tried on GitHub (Didn't work)
Ran one local Qwen3.5 agent through supabase/evals' aiSdkAgent harness against a PGlite fixture with 4 tables across public and billing; the agent called list_tables with schemas: ["public"] and its final answer listed only the two public tables without disclosing the partial inventory. The commenter noted this is a single local-model run, not a hosted or failure-rate result.
Source: https://github.com/supabase/mcp/issues/395#issuecomment-6197601263 (opens external site)
Did this work for you?