Supabase MCP Server

Supabase's MCP server is broader than a database connector because Supabase is broader than a database. Alongside SQL access to your Postgres instance, it manages the platform around it: listing and creating projects, applying migrations, generating TypeScript types from your schema, deploying Edge Functions, checking logs and driving database branching for safe experimentation.

That makes it feel less like "chat with my database" and more like a conversational Supabase CLI. A representative session: describe a new feature, have the assistant design the tables, apply the migration to a branch database, generate the TypeScript types for your frontend, and only merge to production once you've reviewed it. The branching support is the standout — schema changes from an LLM are exactly the kind of thing you want isolated somewhere disposable first.

Setup is refreshingly modern: it runs as a remote server with OAuth, so most clients connect with a URL and an in-browser approval instead of copying access tokens around. Scoping flags matter here too — --read-only restricts SQL to reads, and --project-ref pins the server to a single project so an assistant can't wander across your whole account.

One habit worth adopting: Supabase's own docs recommend against pointing this at production with full permissions, and they're right. Use read-only mode for prod questions, do write-work on branches, and treat the merge step as your human review gate. Used that way it collapses a lot of dashboard-clicking into plain language.

Guardrails that pay off

• get_advisors is the quietly essential tool: it flags tables exposed through PostgREST with row-level security missing or misconfigured, which is the most common way a Supabase project leaks data it shouldn't.
• Regenerate types after every migration. generate_typescript_types reads the live schema, so a stale types file in your repo is the usual reason the frontend and the database start disagreeing.
• Branches are billed while they exist, so delete them once merged instead of accumulating one per abandoned experiment.
• The remote URL accepts a features query parameter that narrows which tool groups load — pinning it to database and docs is a clean way to ensure nothing ever deploys an Edge Function on your behalf.