Blog
3 min read

The Supabase MCP Server: Let AI Work With Your Database (Safely)

Supabase's MCP server lets Claude Code, Cursor and other AI tools inspect your tables, run SQL, apply migrations and read logs. How to connect it, why you should scope it to one project in read-only mode, and the risks of giving an AI database access.

If your app runs on Supabase, the Supabase MCP server lets your AI coding tool look inside it: list tables, check the schema, run queries, apply migrations, read logs and generate TypeScript types. It's genuinely useful — and genuinely risky if set up carelessly.

What it can do

Connected to your Supabase account, the AI can:

  • Read your schema — tables, columns, relationships
  • Run SQL queries
  • Create and apply migrations (database migrations explained)
  • Read logs to debug errors
  • Check security and performance advisors (for example, tables missing row-level security)
  • Look up Supabase documentation
  • Manage edge functions and project settings

How to connect it

Supabase hosts the server at https://mcp.supabase.com/mcp. In Claude Code:

claude mcp add --transport http supabase "https://mcp.supabase.com/mcp?project_ref=YOUR_PROJECT_REF&read_only=true"

The first time you use it, you'll be asked to log in to Supabase in your browser. Run /mcp to check the connection. (Connecting MCP servers to Claude Code)

Your project ref is the ID in your Supabase dashboard URL.

The two settings that matter

project_ref — limit it to one project

Without it, the AI can see every project in your account and use account-level tools. With it, it only sees the one project you're working on.

read_only=true — no changes

Read-only mode removes every tool that can change your database. The AI can still inspect the schema, run SELECT queries and read logs — which covers most debugging. Turn writes on only when you need them, and only on a development project.

You can also limit which groups of tools are available with features=, for example features=database,docs.

Never connect it to production with write access

Supabase's own guidance is clear: use the MCP server with a development project, not production data. The reasons:

  • Mistakes happen fast. An AI that misunderstands "clean up the test users" can delete real ones. (How to stop an AI agent deleting your production database)
  • Prompt injection. If your database contains text users wrote — support messages, profile bios — that text ends up in the AI's context when it reads rows. Someone could write a "message" designed to make the AI run harmful SQL. (Prompt injection)
  • Real users' data shouldn't be flowing through tools that don't need it. (GDPR basics)

Keep Claude Code's permission prompts on for SQL tools, so you see each query before it runs.

Good uses

List all tables without row-level security enabled and explain the risk for each.

Why does this query return no rows for logged-in users? Check the RLS policies on the orders table.

Generate TypeScript types for the current schema.

Read the API logs from the last hour and find the cause of the 500 errors.

RLS problems are where it pays off most: policies are hard to reason about, and the AI can read them and test against them directly. (Supabase RLS explained, "new row violates row-level security policy")

The summary

  • The Supabase MCP server gives AI tools access to your project's schema, SQL, migrations and logs.
  • Always set project_ref and start with read_only=true.
  • Use a development project. Never production with write access.
  • Keep approvals on for SQL.

EasySpawn gives each app its own Postgres database alongside a separate development copy, so you can let Claude Code work on the database freely without production data at risk. See how it works or join the waitlist.

Related: What Is Supabase? · Supabase Row-Level Security Explained · The Best MCP Servers for Coding · Securing MCP Servers

Keep reading