Secure Supabase access for AI agents

Projects, database schema, migrations, SQL, edge functions, and branches via Supabase's official MCP server.

Supabase is one of the sharpest tools you can hand an agent. execute_sql runs raw SQL against your project's database; apply_migration changes its schema; deploy_edge_function ships code. All of that is genuinely useful during development and genuinely destructive by accident. Adding Supabase here puts every call through your policies and onto the audit log, so you can decide which of those tools an agent ever gets to reach.

Server URL: https://mcp.supabase.com/mcp

Setup

Navigate to Resources and click Add Resource.
Select Supabase from the catalog.
Click the Per-org dynamic registration card. Supabase is DCR-only, so this is the single option shown — and picking it installs the resource immediately.

Nothing needs registering on Supabase's side, and no client ID or secret is required. Each user then authorizes their own Supabase account the first time an agent calls a Supabase tool; manage linked accounts in Connections.

Supabase's own organization and project-level permissions still apply. The gateway never widens access beyond what the authorizing user could already do in Supabase — it only narrows it.

Dynamic client registration

Supabase's MCP server supports OAuth dynamic client registration, so the gateway registers a fresh OAuth client against Supabase's authorization server for your org during install. No SecureAuth-shared app is involved and no app registration is needed on your side.

See Credential modes for how this compares to the other modes catalog resources use.

Available tools

Supabase exposes 29 tools. They are grouped below; the resource's Overview tab shows the authoritative per-tool list under Available Tools once installed.

Tool	Description
`search_docs`	Search Supabase's documentation
`list_organizations` / `get_organization`	List organizations, or get details about a specific organization
`list_projects` / `get_project`	List projects, or get details about a specific project
`get_cost` / `confirm_cost`	Get the cost of an action before taking it, then confirm it
`create_project`	Create a new project
`pause_project` / `restore_project`	Pause a project, or restore a paused project
`list_tables`	List database tables
`list_extensions`	List installed Postgres extensions
`list_migrations` / `apply_migration`	List database migrations, or apply a new one
`execute_sql`	Run a raw SQL query against the project's database
`get_logs`	Get project logs
`get_advisors`	Get security and performance advisor recommendations
`get_project_url`	Get a project's API URL
`get_publishable_keys`	Get a project's publishable API keys
`generate_typescript_types`	Generate TypeScript types from the database schema
`list_edge_functions` / `get_edge_function`	List edge functions, or get details about a specific one
`deploy_edge_function`	Deploy an edge function
`create_branch` / `list_branches` / `delete_branch`	Create, list, or delete a development branch
`merge_branch` / `reset_branch` / `rebase_branch`	Merge a branch to production, reset it, or rebase it on production

execute_sql is not a read tool. Its name suggests a query, but it takes arbitrary SQL — an UPDATE or a DROP TABLE goes through it just as easily as a SELECT, and the gateway cannot tell them apart from the tool name alone. Treat it as a write.

Policy examples

Read-only Supabase for everyone

One deny rule blocks every tool that can change something, leaving inspection on the default path:

In Access Policies, click Add Rule and name it "Supabase: no writes."
Set the effect pill to Deny and the MCP scope pill to Supabase.
Add these tool patterns: execute_sql, apply_migration, deploy_edge_function, create_*, delete_*, merge_branch, reset_branch, rebase_branch, pause_project, restore_project.
Set the status to Active and click Create.

create_* covers create_project and create_branch; delete_* covers delete_branch. The rest are named because they don't share a prefix. Reads — list_*, get_*, search_docs, generate_typescript_types — keep working.

If you want the SQL reads too, allowing execute_sql back in is not something a tool pattern can do safely. Enforce it with a read-only Postgres role in Supabase itself, and let the connection's own permissions be the boundary.

Scope one agent to inspection and docs

An allow rule on its own restricts nothing, because every org is seeded with an Allow all rule that anything unmatched falls through to. To confine an agent, pair the allow with a deny beneath it:

Create the deny rule first: effect Deny, MCP scope Supabase, Agent scope your agent, tool pattern *.
Then create the allow rule: effect Allow, MCP scope Supabase, the same Agent scope, tool patterns search_docs, list_projects, get_project, list_tables, list_extensions, list_migrations, get_logs, get_advisors.

New rules insert at the top of the list, so creating the deny first leaves the allow above it — the order you need. Evaluation is first-match-wins: the eight inspection tools match the allow, every other Supabase call matches the deny, and neither reaches Allow all.

Scope both rules to one agent. An unscoped deny would cut Supabase off for every agent and user in the org.

Next steps

Create a policy — the full rule editor walkthrough.
Policies — how first-match-wins ordering and the default Allow all rule interact.
Data Protection — redact keys and other sensitive values out of tool responses before an agent sees them.