You can connect Supabase to Claude with the Model Context Protocol (MCP) in a few minutes, and once it’s connected, Claude can query your database, inspect your schema, and help manage a project without you copy-pasting SQL results into the chat. This guide covers both ways to connect it — directly, or through a gateway — and the one thing worth deciding before you do: which project you actually point it at.

What the Supabase MCP server actually does

Supabase publishes a remote MCP server at mcp.supabase.com/mcp. It exposes your database and project as tools Claude can call directly, so prompts like these run against real, live data instead of a snapshot you fetched by hand:

  • “What columns does the orders table have?”
  • “Write and run a query to find users who signed up but never completed onboarding.”
  • “Explain why this query is slow and suggest an index.”
  • “List the tables in this project and how they’re related.”

Claude acts through the same permissions your Supabase account already has for the project you connect — it isn’t a read-only preview or a cached copy, it’s your account, querying and potentially modifying a real database on your behalf.

Option 1: Connect Supabase to Claude directly

Claude supports remote MCP servers natively. The short version of the setup:

  • Open Claude’s connector or MCP settings.
  • Add a remote server pointing at Supabase’s MCP endpoint.
  • Sign in with your Supabase account when prompted — this is standard OAuth, so Claude never sees your Supabase password, and you can revoke access from Supabase’s own dashboard at any time.
  • Pick which project (and, depending on the setup, which database) the connection applies to.

That’s enough if Claude is the only AI client you point at Supabase. The tradeoffs show up once you add a second tool or a second teammate: every additional AI client (ChatGPT, Cursor, an agent) needs its own copy of that same connection, its own OAuth grant, and its own place where the config can go stale.

Option 2: Connect it once, through a gateway

If you’re already juggling more than one MCP server or more than one AI client, wiring each pair directly gets old fast — that’s the connection sprawl we wrote about in what an MCP gateway is. The alternative is connecting Supabase (and everything else) to one gateway URL, then pointing every AI client at that single URL instead of reconfiguring each one.

With gate specifically, connecting Supabase looks like this: add gate’s gateway URL to Claude once, then pick Supabase from the Supabase server page in the directory and sign in with OAuth the same way you would directly. From then on, Supabase’s tools are available in every client connected to your gate URL — without a second setup step, and with a per-tool allow/ask/block rule instead of one blanket yes for the whole server. See the full list of servers set up this way on the MCP servers page.

Why the project you pick matters more than usual

A database connection isn’t like a docs or ticketing connection — the tools can run arbitrary queries, and a write-capable one can change or delete real rows. A few things worth deciding before or right after you connect:

  • Dev, not prod. Point an AI client at a development or staging project first. A model that writes a technically-valid but wrong query — a bad WHERE clause, a migration that drops a column you needed — is a very different problem in a scratch database than in the one your app runs on.
  • Read, or read and write? If the connection or the client offers a way to scope it to read-only, that’s worth using for exploration and debugging sessions where you don’t actually need Claude to change anything.
  • Is it the official endpoint? Connect Supabase’s documented server (mcp.supabase.com), not a third-party proxy claiming to sit in front of it.

You can run a quick, no-signup check on any server’s tool list with gate’s free MCP security scanner, which looks for prompt injection and hidden instructions in tool descriptions before you rely on a server day to day.

Troubleshooting the connection

A few things that commonly go wrong when connecting any remote MCP server, Supabase included:

  • OAuth loop or sign-in fails. Make sure you’re signed into the right Supabase account — and the right organization, if you belong to more than one — before authorizing, and that you select the intended project.
  • Claude can’t see a table you know exists. Supabase’s tools respect the permissions of the project and role you connected with — a table behind row-level security or a different schema may simply not be visible.
  • Tools disappear after a Supabase update. Remote servers can change their tool list without warning. If you’re connected through a gateway, that kind of change is exactly what drift detection is meant to catch — see how MCP rug pulls work for why a one-time review isn’t enough.

The bottom line

Connecting Supabase to Claude with MCP takes a few minutes either way: point Claude directly at Supabase’s server and sign in, or connect it once through a gateway if you want the same access available in every AI client you use, scoped per tool instead of all-or-nothing. The setup step is the easy part — the decision worth actually slowing down for is which project an AI client gets to query and write to, and whether that project is one you’d be fine debugging a bad query in.