supabase-security-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DATABASE_URL | No | Your Supabase database connection string (use the pooler URL) | |
| SUPABASE_URL | No | Your Supabase project URL (e.g. https://YOURREF.supabase.co) | |
| SUPABASE_ANON_KEY | No | Your Supabase public anon key | |
| SUPABASE_SERVICE_ROLE_KEY | No | Your Supabase service role key |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| probe_anonA | Read-only. Uses ONLY the public anon key to check what a stranger can read: tables via REST (select * limit 1), storage buckets (list), and RPC functions (call with {}). Returns OPEN/closed per target. Never writes. |
| audit_policiesA | Connects to the database (read-only queries on pg_class, pg_policies, pg_proc, information_schema) and flags: tables with RLS off but granted to anon/authenticated, policies with using(true) / with check(true), policies without a TO clause (apply to PUBLIC), and SECURITY DEFINER functions executable by anon/authenticated. Needs a Postgres connection string. |
| two_account_testA | Creates two temporary users (needs the service role key ONLY for that and for cleanup), inserts a row as user A into each table, then tries to read/update/delete it as user B and as anon through the normal REST API. Reports which tables leak across users. Deletes the test rows and users afterwards. Give sampleRow for tables with required columns. |
| security_reportB | Runs probe_anon, audit_policies (if a database URL is available) and two_account_test (if a service role key and tables are given), then returns one Markdown report sorted by severity. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
The probes are differentiated: `probe_anon` is black-box REST exposure, `audit_policies` inspects database catalogs, `two_account_test` verifies cross-user isolation, and `security_report` orchestrates. There is some conceptual overlap between `probe_anon` and `audit_policies` around anon/RLS exposure, so an agent might briefly hesitate, but no tool duplicates another.
`probe_anon` and `audit_policies` follow a verb_noun command style, while `two_account_test` and `security_report` are noun-style names. They are all readable snake_case, but the action-first convention is not applied consistently across the set.
Four tools is appropriate for a focused Supabase security-audit server: three distinct probes plus one report aggregator. Each tool has a clear job, and none feels redundant or missing.
The set covers anon REST exposure, RLS policy misconfigurations, SECURITY DEFINER functions, and cross-user table isolation, which are the core Supabase data-security risks. Minor gaps remain, such as no dynamic storage-object cross-account test and no anonymous INSERT probe, but static policy checks partially compensate.