Supabase MCP: your agent finally talks to the database itself

At a glance

The eight feature groups: database (tables, extensions, migrations, SQL execution), debugging (service logs, security/performance advisors), development (project URLs, API keys, TypeScript type generation), Edge Functions, account management, docs search, branching (paid plans), and storage (off by default). Everything except storage is enabled out of the box, and any subset can be selected per connection.

The security model is the story

Connecting an LLM to a database is the single scariest integration most developers will set up, and Supabase treats it that way. Control lives in the server URL itself:

1. ?read_only=true — restricts the session to read-only Postgres operations; no writes, no DDL, no exceptions
2. ?project_ref=<id> — scopes access to one project and automatically disables account-level tools
3. ?features=database,docs — allowlists tool groups, so a debugging session doesn't need Edge Function deployment rights

Layered on top: browser OAuth (you grant access explicitly, no personal access token sitting in a config file) and your MCP client's per-tool approval prompts as the final gate. Supabase's own best-practices doc is blunt — develop against non-production projects, keep read-only on when touching real data, and use database branches for isolated experiments.

Installation

In Claude Code, add the hosted server (project-scoped here so your team gets it from .mcp.json):

claude mcp add --scope project --transport http supabase \
  "https://mcp.supabase.com/mcp?project_ref=YOUR_PROJECT&read_only=true"

Then authenticate: run /mcp inside Claude Code, select the supabase server, and choose Authenticate — a browser OAuth flow grants access to your organization. The JSON equivalent for other clients:

{
  "mcpServers": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp"
    }
  }
}

Drop the URL parameters only when you consciously want broader access; adding them back is the two-second undo.

Using it day to day

The debugging loop is where it pays for itself. "Users report signups failing" becomes: the agent reads the auth service logs, finds the failing constraint, inspects the table, checks the security advisors (which flag things like missing row-level security policies), and proposes a migration — all in one session, all from evidence rather than your paraphrase of it.

The development group quietly removes a whole category of busywork too: generate TypeScript types after every schema change, fetch the project URL and keys when scaffolding, search Supabase docs without leaving the session. And schema changes done via apply_migration are tracked as real migrations, not untraceable ad-hoc SQL.

Pricing

The server is free and Apache 2.0; the hosted endpoint is included with any Supabase account, free tier included. The only gated feature is the branching tool group, which requires a paid Supabase plan because database branching itself does.

My take

If your stack includes Supabase, this is not optional — the difference between an agent that reasons about your database from a stale schema dump and one that reads the live state is enormous, and the URL-parameter security model means you can start with a posture (dev project, read-only, database+docs only) you'd defend in a code review.

My rule: OAuth once, scope to a dev project, keep read_only=true in the committed .mcp.json, and lift restrictions per-session when there's a reason. What I wouldn't do is hand any agent unscoped write access to a production database — and to their credit, Supabase's own docs say the same thing.

Frequently asked questions