Supabase MCP server

What it does

Supabase runs this server at https://mcp.supabase.com/mcp. Through it an agent can run SQL against your Postgres database, apply migrations, read logs and security advisors, deploy Edge Functions and manage development branches. Unless you scope it to one project, it also sees every organization and project the signed-in Supabase account belongs to, and can create new projects on your bill.

Tools

These 29 tools come from version 0.14.0 of the open-source server, with its default feature groups. The groups match the features URL option described under setup. Storage tools are off by default and not listed here, and Supabase's docs list a create_edge_function_secret tool that this list did not include.

Account

Database

Debugging

Development

Edge Functions

Branching

Docs

Set it up

Directly

Supabase's MCP guide gives this for Claude Code:

claude mcp add --scope project --transport http supabase "https://mcp.supabase.com/mcp"

Then run /mcp, pick supabase and authenticate. The sign-in page asks which organization to grant, so choose the one that holds your project. You don't need a personal access token. In Cursor, put the URL in .cursor/mcp.json for one project or ~/.cursor/mcp.json for all of them:

{
  "mcpServers": {
    "supabase": {
      "url": "https://mcp.supabase.com/mcp?project_ref=<project-ref>&read_only=true"
    }
  }
}

The URL takes options you can combine:

• project_ref=<ref> limits the server to one project and drops the Account tools.
• read_only=true runs every query as a read-only Postgres user. In the 0.14.0 code it also hides the write tools such as apply_migration and deploy_edge_function, and execute_sql stays available for reads.
• features=database,docs turns on only the groups you name. The group names in the code are account, database, debugging, development, functions, branching, docs and storage.

How to add MCP servers to Claude Code and How to set up MCP servers in Cursor cover the general client steps.

Through Statio

Install Supabase from the catalog and press Connect. Supabase's own sign-in page opens, and you approve access for an organization there. Statio registers itself as the OAuth client, so there is no app for you to create, and the connection is shared by the members you grant it to. Grant each tool under Permissions.

The desktop app configures Claude Code and Cursor for you. To do it by hand, Cursor's mcp.json entry points at the local proxy, http://127.0.0.1:7777/<server-name>/mcp, with the server name as your dashboard shows it, and Claude Code is set up with mcphub config claude-code. If the tools don't show, restart the session and then try How to debug an MCP server that won't connect.

What to hold back

The hard part with Supabase is that execute_sql is one tool. A SELECT and a DELETE FROM users go through the same name, so a grant on that tool is a grant on every statement the database role allows. Per-tool grants decide whether an agent gets SQL at all. For read-only SQL, connect directly with read_only=true.

A coding agent on a feature branch is well served by list_tables, list_migrations, generate_typescript_types, get_advisors, query_logs, search_docs and the function reads. Keep these back unless a person is watching each call:

• merge_branch pushes migrations and Edge Functions to production. An agent that thinks its branch is done can ship it.
• deploy_edge_function replaces a live function the moment it runs. A bad deploy to your auth webhook or payment handler breaks it for real users with no review step.
• apply_migration against a production project can drop a column your app still reads.
• reset_branch and delete_branch throw away work on a branch someone else may be using.

A support or analytics agent that answers questions from your data should not get execute_sql unless it runs in read-only mode. Supabase's docs give the reason: rows in your tables can carry text written by your users, such as a support ticket that tells the model to run a query. The server wraps SQL results with a warning to ignore instructions in the data, and Supabase says plainly this is not foolproof. An agent that reads a poisoned row and also holds a write tool is the case described in The lethal trifecta: how AI agents leak data.

Keep create_project, create_branch and pause_project from every unattended agent. The first two spend money, and the server's cost check expects a person to agree to the quoted price, which nobody does in an unattended run. Pausing a project takes your app offline. If the agent only works on one project, scoping with project_ref also removes the Account tools from its reach. MCP permissions covers how per-tool grants work.

Questions