Supabase MCP

The 81/100 score is weighted around the server’s real job: exposing live Supabase project context to an AI agent without making that agent broader than the task requires. Database-write containment, project isolation, least-privilege configuration, authentication reliability and schema accuracy therefore matter more than raw tool count.

Supabase scores well because the official server combines broad development capability with real scope reduction. Confidence remains Moderate because recent issue evidence still shows OAuth, metadata and client-compatibility failures, and the evaluation did not benchmark the server against the CLI on the same application build.

Supabase MCP is Supabase’s official Model Context Protocol server for letting compatible AI coding agents inspect and operate Supabase projects through structured tools.

It is broader than a PostgreSQL reader. Depending on configuration, the agent can inspect schema, execute SQL, apply migrations, query logs, generate types, deploy Edge Functions, manage development branches, search Supabase documentation and perform selected account or project operations.

The critical distinction is authority. A Supabase MCP connection is not one permission; the usable surface depends on the authenticated identity, project scope, read-only setting and enabled feature groups.

Supabase organizes its MCP tools into functional groups. The useful question is not the maximum number of tools—it is which groups the agent needs for the current task.

A broad connection can reach much more than PostgreSQL rows. Depending on enabled groups, it can touch schema, SQL execution, migrations, logs, Edge Functions, project configuration, database types, branches, documentation, Storage configuration and account resources.

That is why the server should be understood as a Supabase development control plane exposed through MCP rather than as a simple database connector.

No. Supabase MCP is not read-only by default, but it can be configured in a real read-only mode.

Normal write-capable configurations can execute SQL, apply migrations, deploy Edge Functions and mutate branches or project resources. Setting read_only=true executes database queries using a read-only PostgreSQL user and removes mutating tools from the permitted surface.

This is the central safety and efficiency feature of the server. The safest configuration is not a single switch; it is a combination of scope controls.

A deliberately narrow connection can therefore look like:

https://mcp.supabase.com/mcp?project_ref=<project-ref>&read_only=true&features=database,docs

An MCP client sends a structured request to the Supabase MCP server. The server authenticates the caller, applies the selected project and feature restrictions, exposes the allowed tools, runs the requested Supabase operation and returns the result to the client as model context.

For production work, the important boundary is therefore not the model alone. It is the combination of authentication, MCP configuration and the server-side permissions that remain after those controls are applied.

The hosted server uses remote HTTP MCP and can work with modern MCP-capable coding clients. The search demand around Supabase MCP is especially strong for Cursor, Claude Code, VS Code, Codex, Antigravity and OpenCode.

Start by choosing the project and permission surface before adding the server URL.

1. Choose the Supabase project the agent actually needs.
2. Enable read_only=true when the workflow does not require writes.
3. Limit features= to the required groups.
4. Add the hosted MCP URL to the client.
5. Complete Supabase OAuth in the browser.
6. Verify that only the expected tools appear.
7. Run one narrow read test before enabling write-capable groups.

A conservative Claude Code example is:

claude mcp add --scope project --transport http supabase \
"https://mcp.supabase.com/mcp?project_ref=<project-ref>&read_only=true&features=database,docs"

Then run /mcp in Claude Code and choose the Supabase server to authenticate.

Not for normal interactive use of the hosted server. Supabase now uses browser-based OAuth with dynamic client registration for supported clients, so most users do not need to manually generate a personal access token.

PAT authentication remains useful for CI, headless automation or clients that cannot complete the normal browser flow. Manually registered OAuth applications are also supported for clients that require a client ID and secret.

Interactive hosted flow

CI / non-interactive flow

{
  "mcpServers": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp?project_ref=${SUPABASE_PROJECT_REF}",
      "headers": {
        "Authorization": "Bearer ${SUPABASE_ACCESS_TOKEN}"
      }
    }
  }
}

Manual OAuth scope granularity is still broader than ideal, so MCP-level controls remain important even after authentication succeeds.

Supabase MCP has a Grade C scan because legitimate configurations can reach privileged developer capabilities and modify live infrastructure. That grade reflects the sensitivity of the action surface, not an absence of safety controls.

Prompt injection can arrive through database content

A support ticket, comment, profile field or other customer-controlled row can contain instructions intended to manipulate the model after the data is returned through MCP. Supabase explicitly treats prompt injection as a primary LLM-specific threat.

Supabase wraps SQL results with instructions telling models not to obey commands embedded in returned data, but its own documentation says this mitigation is not foolproof. The meaningful controls remain project scope, read-only execution, restricted features, human approval and isolated branches.

Production data can become model context

Rows, logs, IDs, email addresses and other application details retrieved through tools become input to the connected AI provider. Use the narrowest query that answers the task and avoid exposing unrelated secrets or personal data.

Customer-facing use needs a different architecture

The official Supabase MCP acts with developer-level project context rather than the identity of an end user. Supabase therefore advises against giving this MCP directly to customers. Customer-facing MCPs should authenticate the user and rely on Row Level Security.

Supabase can isolate agent-generated database changes in a development branch before they reach production. That changes a migration workflow from direct mutation into a reviewable sequence.

Branching remains experimental in the MCP tool group and requires a paid Supabase plan. It improves containment, but it does not replace human review of schema and application behavior.

Supabase MCP is actively maintained, but recent issue evidence shows that authentication and metadata correctness remain important operational variables. Some failures are client-side or interoperability problems rather than core server defects; users still experience the complete chain, so those failures matter.

There are two different context costs: the fixed tool-schema surface and the variable results returned by database, logs, types, migrations and Edge Function tools.

1. Tool-schema cost

The evaluation estimates roughly 10K–18K tokens for a broad 30+ tool surface. Restricting the server to database,docs may reduce that to approximately 3K–7K tokens. These are estimates, not a captured current tools/list measurement.

2. Returned project data

Schema metadata, SQL results, logs, generated TypeScript types, migration output and function source can exceed the initial schema cost. A real debugging session can therefore add tens of thousands of tokens after the tools are loaded.

Feature groups reduce both privilege and resident context. Restricting tools is an efficiency control as well as a security control.

Model-window reference set checked Sep 27, 2026: OpenAI model docs, Anthropic model overview, Google Gemini model docs, xAI model docs, Mistral model docs and DeepSeek API docs. The 18K value is the upper end of the Supabase MCP schema estimate, not an exact tokenizer measurement.

Large context windows do not make schema overhead irrelevant. The same session also needs room for repository context, SQL results, logs, tool outputs, reasoning and generated code.

The evaluation’s representative gauntlet uses approximately 60K input + 15K output tokens: inspect schema, generate types, diagnose a failure, run read-only SQL, test write blocking, create a branch, apply a migration, inspect logs, deploy a disposable Edge Function and verify project isolation.

Supabase does not document a separate per-call MCP fee. The table below estimates only model-token cost for that workload using current public API rates. The workload stays below the long-context thresholds used by providers that charge higher rates for very large prompts.

Pricing reference checked Sep 27, 2026. OpenAI, Anthropic, Google, xAI, Mistral and DeepSeek first-party model/pricing pages. DeepSeek uses the peak cache-miss rate; Google Gemini 3.1 Pro uses its ≤200K-input tier. Provider pricing can change.

Hidden costs matter more than cents of token usage

• development branches and normal Supabase project resources;
• review time for migrations, SQL and function changes;
• production data becoming model context;
• large log or query outputs;
• retries when OAuth or client registration fails;
• operational damage from an incorrect write.

The cheapest model is not automatically the cheapest completed task. For write-capable workflows, correctness and containment matter more than saving a few cents on one run.

No dedicated MCP-specific anonymous telemetry switch was established in the evaluated Supabase MCP documentation. That is not the same as saying there is no logging.

The hosted endpoint is operated by Supabase, so authentication, request handling, abuse/rate controls and normal infrastructure observability should be expected under Supabase’s service policies.

MCP-specific anonymous telemetry: not documented. Hosted operational logging: expected; exact MCP-specific fields were not established in this evaluation.

The evaluated repository is classified as ADOPTED for the July 2026 protocol generation. Supabase migrated its published MCP packages to SDK v2 in August 2026, and its current self-hosted handler documentation describes support for the current protocol revision rather than legacy 2025-era clients.

This is a stronger protocol-currency signal than simply supporting Streamable HTTP.

Use one disposable Supabase project, scope the MCP to that project, enable read_only=true, and expose only database,docs. Then deliberately test the boundaries before adding write authority.

1. Inspect the existing schema.
2. Generate TypeScript types.
3. Run a harmless read-only query.
4. Ask the agent to perform a write and confirm that it is blocked.
5. Verify the agent cannot see another project.
6. Add one feature group only when a real workflow requires it.
7. Move migration testing to a disposable branch before production.

This sequence tests usefulness and containment without starting with the full Supabase control plane.

Supabase MCP is a strong example of a privileged developer MCP that acknowledges its own blast radius. The server is powerful enough to cause real damage, but the architecture gives operators several independent ways to make it smaller before the model acts.

The decisive strengths are project isolation (91) and least-privilege configurability (95). A project-scoped, read-only, feature-restricted connection is materially different from the unrestricted surface.

The remaining weak point is the same architectural problem that makes database MCPs valuable: real application data enters an LLM that may also have write-capable tools. Supabase documents prompt injection explicitly, but no prompt wrapper can substitute for privilege restriction and review.

Why it scores well

• first-party access to live Supabase project context;
• project scoping that removes unnecessary account reach;
• server-enforced read-only database execution;
• feature-group filtering that reduces both attack surface and context cost;
• development branches for safer agent-generated changes;
• current MCP SDK generation and active release cadence;
• modern hosted OAuth with PAT fallback for non-interactive use.

Why it does not score higher

• unrestricted mode still exposes high-impact writes;
• database content can carry prompt-injection payloads;
• recent OAuth/OIDC interoperability failures reduce reliability;
• schema and tool-metadata bugs can mislead code generation;
• manual OAuth scopes remain broader than ideal;
• exact current schema-token overhead still needs direct measurement.

Bottom line

Use Supabase MCP as a deliberately scoped development tool, not as a permanently broad production control plane. Start with one project, read-only access and only the feature groups the task needs.

The evaluated evidence set includes official documentation, current releases and 2026 operational issue reports. Negative evidence is separated from current fixed behavior where possible.

Confidence: Moderate. The documentary and issue corpus is strong; controlled benchmarking against the Supabase CLI/docs on the same real project is still missing.