Supabase has become the default backend for a huge swath of modern web applications. Postgres database, row-level security, auth, file storage, edge functions, realtime subscriptions — all managed through a single dashboard and API. For developers already building on Supabase, the question was always when (not if) it would get proper MCP support.

The Supabase MCP server answers that question. It gives any MCP-compatible agent — Claude Code, Cursor, Windsurf, or anything else speaking the protocol — direct access to your Supabase project. Query tables, manage auth users, read and write storage buckets, invoke edge functions. All from inside your agent’s workflow, without switching to the dashboard or writing API wrapper code.

What It Actually Does

The Supabase MCP server connects your agent to a Supabase project through the Management API and the standard Postgres connection. It exposes tools for the core Supabase primitives:

Database. Run SQL queries against your Postgres instance. Create tables, insert rows, run joins, check schema structure. Your agent can inspect a production database to debug an issue, seed test data into a staging environment, or generate migrations based on your current schema.

Auth. List users, check authentication settings, review sign-up configurations. When your agent is building or debugging auth flows, it can verify the actual state of your Supabase Auth setup instead of guessing from code alone.

Storage. Read from and write to Supabase Storage buckets. An agent building a file upload feature can test against real storage. An agent processing documents can pull files directly from a bucket, process them, and write results back.

Edge Functions. Trigger Supabase Edge Functions from agent workflows. If your project uses edge functions for background processing, webhooks, or API endpoints, your agent can invoke them directly during development or testing.

This isn’t a wrapper around the Supabase JavaScript client. It’s an MCP server that speaks the protocol natively, which means any MCP-compatible client can use it without importing Supabase-specific SDKs.

Why This Matters for Agent Workflows

Most AI coding agents work with local files — your source code, your config, your tests. That’s powerful, but it misses half the picture. Your application doesn’t live in files alone. It lives in the database schema, the auth rules, the storage policies, the edge function logs.

Without database access, an agent writing a new API endpoint has to guess at your schema. It reads your ORM models and infers what the tables look like. Usually that’s close enough. Sometimes it’s wrong — a column was renamed, a nullable field became required, a new index changed the query plan.

With the Supabase MCP server, the agent doesn’t guess. It runs SELECT * FROM information_schema.columns WHERE table_name = 'users' and knows exactly what columns exist, what types they are, and what constraints apply. That’s a different quality of code generation.

The same logic applies to auth. An agent building a login flow can check whether your project uses email/password, magic links, OAuth providers, or some combination. It builds the UI to match the actual configuration, not a generic template.

Setup

Install through npx and point it at your Supabase project:

{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": ["-y", "@supabase/mcp-server-supabase"],
      "env": {
        "SUPABASE_ACCESS_TOKEN": "your-access-token"
      }
    }
  }
}

You’ll need a Supabase access token, which you can generate from your Supabase dashboard under Account Settings. The server connects through the Management API, so it has access to all projects under your account.

Transport: stdio Auth: API key (Supabase access token) Install: npx -y @supabase/mcp-server-supabase

Once connected, your agent can discover available tools automatically through the MCP protocol. No additional configuration needed per project — the server handles project selection and routing.

Tradeoffs

The Supabase MCP server gives your agent real database access. That’s its strength and its risk. An agent running DROP TABLE or DELETE FROM users against a production database will do exactly what you told it to do. The server doesn’t add a safety layer beyond what Supabase itself provides.

For development and staging environments, this is fine. Point the server at your dev project and let your agent experiment freely. For production access, be thoughtful about permissions. Supabase’s row-level security policies still apply, and you can scope the access token to read-only roles if you want to limit what an agent can do.

The server connects through the Management API, which means it operates at the project level rather than the application level. Your agent sees the full project — all tables, all buckets, all functions. If your Supabase project houses multiple applications or tenants, the agent sees all of them. There’s no built-in multi-tenancy scoping at the MCP layer.

Performance is generally fast for typical agent queries — schema inspection, small result sets, targeted reads and writes. If your agent tries to pull a million-row table into context, you’ll hit the same limits as any other large query. MCP servers don’t have infinite context windows to fill.

How It Compares

PostgreSQL MCP is a direct Postgres connection via connection string. It gives you raw SQL access to any Postgres database, Supabase or not. The Supabase MCP server adds the Supabase-specific layers on top: auth management, storage operations, edge function invocation, and project-level management through the Supabase API. If you only need SQL access, the generic Postgres MCP server works. If you’re building on the full Supabase platform, the dedicated server is more useful.

Neon MCP serves a similar role for Neon’s serverless Postgres. Both give agents database access. The difference is the platform layer — Neon focuses on serverless branching and scaling, Supabase bundles auth, storage, and realtime. Pick the server that matches your stack.

Firebase doesn’t have an official MCP server at the time of writing. For teams choosing between Supabase and Firebase, MCP support is one more reason to lean Supabase if agent-assisted development is part of your workflow.

Bottom Line

Supabase MCP closes the gap between what your agent can see in your codebase and what’s actually running in your backend. Schema-aware code generation is better code generation. Auth-aware UI building is more accurate UI building. The server works because it gives agents the same context that developers get from the Supabase dashboard — just delivered through a protocol the agent already speaks.

If your stack runs on Supabase, this is one of the first MCP servers to add. The difference between an agent that guesses your schema and one that reads it directly shows up in every generated query, migration, and API endpoint.

Find Supabase MCP on AgentNDX: /servers/supabase-mcp

FAQ

Is the Supabase MCP server official? It’s maintained under the supabase-community GitHub organization with official Supabase involvement. The package is published as @supabase/mcp-server-supabase on npm, which is the official Supabase scope.

Can my agent accidentally modify production data? Yes. The MCP server executes whatever SQL or API calls your agent sends. Use a development or staging project for exploratory work. For production access, scope your access token to read-only roles and rely on Supabase’s row-level security policies as guardrails.

Does it support Supabase Realtime? The server can trigger realtime events and inspect realtime configuration. Persistent subscriptions — where the agent listens for live database changes over time — are not a natural fit for the MCP request/response model, so that use case is better handled by application code.