Supabase MCP Server

The Supabase MCP server is the official integration from the Supabase community, giving AI agents access to Supabase project management, Postgres queries, storage operations, edge function deployment, and auth user management. It connects through the Supabase Management API and exposes a wide tool surface that goes well beyond raw database access, making it the most capable backend-as-a-service MCP integration available.

Supabase bundles a lot of what you'd otherwise stitch together yourself: a Postgres database, an auth system, file storage, edge functions, and a REST and real-time API layer. The Supabase MCP server exposes all of it. Not just the database, the whole backend management surface. That makes it one of the more capable MCP servers if you're building on Supabase, and also one that deserves careful thought about what you give an agent permission to do.

What the server exposes

The tool surface is broader than most database MCP servers. It breaks into four areas:

Project and organization management. The agent can list your Supabase organizations and projects, retrieve project configuration, and fetch API keys. This is the management plane you'd normally interact with through the Supabase dashboard. The agent can use this context to configure itself for subsequent operations rather than requiring you to manually pass project references.

Database operations. The server exposes tools for running SQL queries against your project's Postgres database. Unlike the Postgres MCP server which enforces read-only access, the Supabase server allows full read and write operations. You can SELECT, INSERT, UPDATE, DELETE, run migrations, and inspect schemas. The agent also has access to table definitions, foreign key relationships, and index information, which gives it accurate schema context before writing queries.

Storage. List storage buckets, upload objects, download objects, and manage bucket configuration. If your app stores user uploads or generated assets in Supabase Storage, the agent can interact with that layer directly. This opens up workflows like the agent generating a file, uploading it to storage, and returning a URL.

Edge Functions. The server can list deployed edge functions, deploy new functions or updates to existing ones, and retrieve function logs. Edge functions are Deno-based serverless functions that run close to the user. Having an agent able to deploy them means a workflow like "write a function, test it, deploy it" can happen in a single conversation without switching to the CLI.

Auth management. The agent can list auth users, inspect user metadata, and review auth provider configuration. For debugging ("why can't this user log in") or administration ("show me users who signed up in the last week"), this is genuinely useful without having to navigate the dashboard.

Setup

The simplest path is npx, which runs the server without a global install:

npx -y @supabase/mcp-server-supabase

Before that works, you need a personal access token. Go to supabase.com/dashboard/account/tokens, create a new token, and copy it. Store it somewhere safe; you cannot retrieve it after the creation screen.

Add the server to your Claude Desktop config at ~/Library/Application Support/Claude/claude_desktop_config.json:

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

To scope the server to a single project (recommended for day-to-day development):

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

Your project ref is the string in your Supabase project URL: https://app.supabase.com/project/abcdefghijklmnopqrst. Scoping to a project prevents the agent from accidentally switching to a different project in the same organization.

For Claude Code, the config lives at ~/.claude/mcp.json with the same structure.

Real use cases

Schema-first development. The agent can read your existing table definitions, understand the foreign key relationships, and help you write or generate new migrations that fit the existing structure. This is faster than looking up the schema in the dashboard and less error-prone than describing the schema from memory.

Data exploration and debugging. When something unexpected is in your database, the agent can run targeted queries to understand the state. "Show me all users who signed up in the last 24 hours but don't have a profile row" is a query you can describe in plain language. The agent writes the SQL, runs it, and reports back.

Edge function iteration. Describe the logic you want, the agent writes the TypeScript Deno function, you review it, and the agent deploys it. The logs tool lets the agent check whether the deployment succeeded and what errors occurred. This loop is significantly faster than the typical edit-commit-push-check-logs cycle.

Auth debugging. When a user reports they cannot log in, the agent can look them up by email, check their auth provider and metadata, and identify obvious problems (unverified email, missing provider, blocked account) without you navigating the dashboard.

Storage housekeeping. List all objects in a bucket older than a given date, check for orphaned files that no longer have corresponding database records, or count objects by prefix to understand usage patterns. These are the kinds of maintenance queries that are easy in SQL but require cross-referencing storage and database, which the agent can handle in one session.

Automated setup for new projects. The agent can execute a sequence of SQL migrations to set up a schema, configure row-level security policies, create storage buckets, and confirm the setup against a checklist. This is particularly useful for spinning up development or staging environments consistently.

The write access question

The Supabase MCP server is more permissive than the reference Postgres server. That is a deliberate choice: it is designed for development workflows where an agent needs to do more than read. Migrations, schema changes, edge function deployments, these require write access.

The practical implication is that the agent can do damage if given ambiguous instructions or if a prompt goes wrong. This is worth taking seriously:

Scope to development databases. Point the server at your development or staging Supabase project, not production. If the project ref in your config is the production project, the agent is operating on live data. Keep production credentials separate and never include them in a day-to-day development config.

Use specific instructions. Broad instructions like "clean up old data" give the agent wide latitude. Specific instructions like "delete rows from the sessions table where created_at < '2025-01-01' and return the count before deleting" give the agent a clear, auditable task.

Review migrations before running. If you're asking the agent to help write database migrations, have it write the SQL first and show it to you before running. A migration that drops a column is hard to reverse.

Row-level security and the agent's view

Supabase's row-level security (RLS) policies run at the database level and apply to queries the agent makes the same way they apply to your application code. If RLS is enabled on a table, the agent's queries are subject to the same restrictions as any other Postgres connection.

The gotcha: the personal access token connects to your project via the Management API, which may bypass RLS depending on how the connection is established. For the database query tools specifically, the server typically uses the service role key internally, which does bypass RLS. This means the agent can see data that end users cannot, which is appropriate for admin workflows but worth being aware of.

If you want the agent to experience the same RLS restrictions as your application users, you would need a server configured to use an anon or user-scoped key rather than the service role. That is not the current default; it would require a custom setup.

Comparing to the plain Postgres MCP server

If you're on Supabase, the dedicated server is the better choice over the generic Postgres MCP server. The reasons:

The Postgres server gives you read-only SQL access. The Supabase server gives you read-write SQL access plus the management operations that Supabase adds on top.

The Postgres server works against any PostgreSQL database. The Supabase server understands Supabase's project structure, can fetch your API keys, and knows how to deploy edge functions. That context is not available through a generic Postgres connection.

For teams not on Supabase, the Postgres server is the right choice. The Supabase server is specifically for Supabase deployments and does not make sense otherwise.

The SQLite MCP server is the right choice for local development without any cloud dependency, and the MongoDB MCP server covers the NoSQL equivalent.

Pairing with other servers

Supabase MCP pairs well with code-focused servers. Combined with GitHub MCP, the agent can read code from a repository, understand the Supabase schema it uses, and suggest changes that keep both in sync. Combined with Filesystem MCP, the agent can write migration files to your local repo and execute them against the Supabase project in the same session.

For issue tracking, combining Supabase MCP with Linear MCP or Jira MCP lets the agent move from a bug report to the database query that investigates it in one step.

Bottom line

The Supabase MCP server is the most capable backend MCP server available if you're building on Supabase. The combination of database access, project management, edge function deployment, and auth management covers almost everything you'd do in the Supabase dashboard, surfaced through a conversation with your agent.

The setup is about as frictionless as an MCP server gets: a personal access token, an npx command, and a config entry. You're up in under 10 minutes.

The responsibility that comes with the wide tool surface is real. Keep the project ref scoped to development, use specific prompts rather than broad instructions for anything destructive, and treat production credentials as off-limits for agent use. Within those constraints, this is a genuinely useful integration for Supabase-based projects.

Features

• Query and modify Postgres tables via natural language or SQL
• List, create, and manage Supabase projects and organizations
• Deploy and manage Supabase Edge Functions
• Manage storage buckets and objects
• List and manage auth users, providers, and settings
• Run database migrations and inspect schemas
• Retrieve project API keys and configuration
• Compatible with Claude Desktop and Claude Code via stdio transport
• Authenticates via Supabase Management API access token

How to set up the Supabase MCP Server MCP server

1. Generate a personal access token at supabase.com/dashboard/account/tokens
2. Run npx -y @supabase/mcp-server-supabase to test connectivity
3. Add the server block to your Claude Desktop or Claude Code MCP config file
4. Set the SUPABASE_ACCESS_TOKEN environment variable with your personal access token
5. Optionally set SUPABASE_PROJECT_REF to scope the server to a single project
6. Restart your MCP client and verify the Supabase tools appear in the tool list