The Model Context Protocol that Anthropic published in November 2024 has produced one specific integration pattern that has become widely adopted across the AI tooling ecosystem in 2025 and 2026: live database access for AI agents. The pattern is straightforward in concept and operationally consequential in practice. An MCP server sits in front of a database. An AI client (Claude Desktop, Cursor, Windsurf, or any other MCP-aware tool) connects to the server. The agent the user is working with can query the database directly, inspect schemas, propose and apply migrations, and operate on the data in real time as part of the conversation. The Supabase MCP server is the most actively-used implementation of this pattern, both because Supabase has a substantial existing developer base and because the Supabase team has invested heavily in the MCP integration as a strategic surface.
This piece walks through what the Supabase MCP server actually is, the tool surface it exposes, how the authentication has evolved through 2025 and 2026, the installation and configuration patterns for the major MCP clients, the operational security considerations (including the July 2025 disclosure that meaningfully reshaped how the community thinks about MCP-database integrations), the practical agentic workflows that the integration enables, and the broader landscape of database MCP servers in case you are not on Supabase. The goal is that after reading this you can decide whether the integration is right for your team, and if so, how to configure it without creating a security exposure.
The short version is that the Supabase MCP server is the official Anthropic-style integration between Supabase Postgres databases and MCP-compatible AI agents. It is maintained by the Supabase community organization at github.com/supabase-community/supabase-mcp and published on npm as @supabase/mcp-server-supabase. It is in active development with frequent releases. The current state supports both the original stdio-and-PAT model and a newer remote-MCP-with-OAuth-2.1 model that simplifies adoption for end users. The integration is powerful, the practical workflows it enables are genuinely useful, and the security model has known and documented sharp edges that need to be understood before production deployment.
What the Supabase MCP server is
Supabase is a backend-as-a-service platform built on Postgres, covering database, authentication, storage, edge functions, and realtime subscriptions through a unified developer experience. The Supabase MCP server is the bridge between an MCP-compatible AI agent and a specific Supabase project. The agent sees the database (and several adjacent Supabase surfaces) as a set of tools it can invoke; the user sees the agent answering questions, executing changes, and synthesizing results that draw on the database content.
The server has been maintained since April 2025, when the original stdio version was released alongside Anthropic’s MCP standard reaching broad client adoption. The tagged GitHub release as of mid-2026 is v0.7.0 from March 2026; the published npm version is 0.8.1, which reflects point releases that have not been formally tagged on GitHub. The cumulative download count is approximately 832,000 as of mid-July 2026, which puts it in the top tier of MCP server adoption.
The architectural model is that the MCP server runs as a process (either locally as a stdio server, or remotely as a hosted HTTP service depending on the deployment) and exposes a set of tools through the MCP protocol. The AI client connects to the server, lists the available tools, and invokes them when the user’s intent requires database interaction. The server translates each tool invocation into a Supabase API call or a direct SQL query, returns the result to the client, and the agent uses the result in its response generation.
The tool surface
The Supabase MCP server exposes a curated set of tools rather than a single "run any SQL" interface. The curation is deliberate: it produces a tool surface that is both more useful for typical agentic workflows and (somewhat) safer than raw SQL access alone. The tools in the current version:
list_tables returns the tables in a project, with options to include or exclude columns, foreign keys, and other metadata. The verbose flag added in v0.7.0 includes additional schema detail that the agent can use for reasoning about complex queries.
list_extensions returns the Postgres extensions installed on the project (pgvector, postgis, pg_cron, and others), which lets the agent reason about what database functionality is available.
list_migrations returns the project’s tracked migration history, used by the agent when proposing or applying schema changes.
apply_migration applies a new migration, recording it in the project’s migration history. This is the recommended path for schema changes because the change is versioned and reproducible across environments.
deploy_edge_function deploys a new edge function or updates an existing one. This bridges the MCP server into Supabase’s serverless surface, letting an agent build and ship complete features rather than only the database side.
get_logs returns project logs, filterable by source (api, postgres, edge_functions, auth, storage, realtime). This is the debugging surface that lets the agent investigate issues observed in the running application.
A set of project and branch management tools handle creating branches, managing project configuration, and similar operational concerns. TypeScript type generation produces TypeScript definitions from the database schema, which lets the agent generate code that is type-safe against the actual schema.
What the surface does not include as first-class tools, as of v0.7.0: RLS policy management, auth user management, and storage object management. These are reachable through raw SQL or through the management API surface, but they are not exposed as dedicated tools. The reasoning is that these are the surfaces with the highest blast radius if misused; requiring them to be reached through more general tools makes their use more visible to the user.
The authentication evolution
The authentication model for the Supabase MCP server has gone through a meaningful evolution since the April 2025 launch.
The original stdio server required a Supabase Personal Access Token (PAT) configured in the MCP client’s configuration file. The PAT is a long-lived credential associated with the developer’s Supabase account, with broad permissions across the developer’s projects. The model worked for early adopters but had two operational frictions: getting a PAT into the right configuration file required several steps that varied by MCP client, and the PAT’s broad scope created a meaningful credential-exposure risk if the configuration file leaked or the developer’s machine was compromised.
The newer remote MCP server uses OAuth 2.1 with dynamic client registration and PKCE, the standard modern OAuth flow. When a user first connects an MCP client to the Supabase remote MCP server, the client redirects the user to a Supabase browser flow, the user authorizes the client to access their Supabase projects, and the server issues a scoped credential to the client. No PAT needs to be created or copied; the user experience is a few browser clicks rather than a configuration file edit.
The OAuth flow is what most new users are now configuring. The stdio server with PAT is still supported for backwards compatibility and for use cases (CI/CD, automation, MCP clients that do not implement dynamic client registration) where the interactive OAuth flow does not fit. PATs are also still the recommended path for headless automation where there is no human in the loop to complete a browser authorization.
The hosted remote MCP also supports additional MCP clients beyond the original stdio set. ChatGPT, Builder.io, and any other client that supports OAuth-based remote MCP can use it. The original stdio clients (Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, Cline) continue to work with both authentication paths.
Installation and configuration
The installation pattern depends on which MCP client you are using and whether you are connecting via stdio or via the remote server.
For Claude Desktop with the stdio server, the configuration goes in the Claude Desktop config file. The config snippet adds the Supabase MCP server entry with the command to launch it (typically npx @supabase/mcp-server-supabase) and the necessary environment variables (SUPABASE_ACCESS_TOKEN for the PAT, optionally a project reference if scoping to a single project).
For Claude Desktop with the remote server, the configuration is simpler: a single entry pointing at the remote MCP URL. The OAuth flow runs on first use and the credentials are stored in the client’s secure storage. Subsequent sessions reuse the stored credentials.
For Cursor, the configuration goes in the Cursor settings under the MCP section. The setup is conceptually identical to Claude Desktop but with Cursor-specific configuration paths.
For Windsurf, VS Code (with the Copilot MCP integration), and Cline, the configuration patterns are similar with client-specific configuration locations.
For ChatGPT Desktop, only the remote MCP path is supported as of mid-2026. The configuration is the same single-URL entry as Claude Desktop’s remote setup.
A common starting pattern for new users is to begin with the remote MCP plus read-only mode (described in the security section below). This gives a low-friction first experience where the agent can explore the database without the risk of accidental writes. After the user is comfortable with the agent’s behavior, they enable write capabilities for the specific workflows that need them.
The RLS bypass and why it matters
Supabase’s Row-Level Security (RLS) is the platform’s standard mechanism for controlling which rows a user can see based on the authentication context. RLS policies are enforced at the database layer using Postgres’s RLS feature, with the Supabase platform setting up the auth context based on the JWT of the authenticated user.
The Supabase MCP server authenticates as a management or service-role principal, which is the kind of credential that exists outside the normal user-authentication flow. Service-role credentials bypass RLS by design. This is intentional: many of the MCP server’s tools (migrations, project configuration, log access) operate at a level above the data-layer authentication context, and a service-role credential is the right credential for those operations.
The consequence is that an MCP-connected AI agent has access to data in your database regardless of RLS. If your database contains private user data with RLS policies that restrict per-user visibility, those policies do not protect the data from an MCP-connected agent. The agent sees everything.
This is not a bug. It is the documented design and it is the only design that lets the MCP server’s higher-level operations (migrations, deploys, log access) work correctly. But it is a property that needs to be understood explicitly, especially for teams that have built their security model around RLS and have not previously had to reason about credentials that bypass it.
The practical implication is that the MCP server must be operated as though it were the most privileged credential in your system, because effectively it is. Treat the MCP server’s connection like a database superuser session for the purposes of threat modeling.
The July 2025 incident and Supabase’s response
The community’s thinking about MCP-database integrations was meaningfully reshaped by a security disclosure in July 2025. The security firm General Analysis published a blog post titled "Supabase MCP can leak your entire SQL database" demonstrating a specific attack pattern against the Cursor-plus-service-role-MCP configuration.
The attack worked as follows. An organization was using Cursor with the Supabase MCP server configured for read-write access on a customer support workflow. The workflow involved an AI agent reading customer support tickets and using them to do research and respond. An attacker submitted a support ticket whose body contained instructions to the AI agent: a stored prompt injection. The instructions directed the agent to query the integration_tokens table (containing third-party API credentials), and to write the results into the ticket thread as if they were a normal response. The agent followed the embedded instructions, exfiltrating the credentials into a channel the attacker could read.
The disclosure does not record an actual customer-data exposure incident; it was a research demonstration of a feasible attack pattern. But the demonstration was credible enough to drive substantial industry response. Simon Willison described the attack as an instance of his "lethal trifecta" pattern: an LLM with access to private data, exposure to untrusted text, and an output channel that the attacker controls. Any system that combines all three is vulnerable to this class of attack.
Supabase responded with a blog post titled "Defense in Depth for MCP Servers" that introduced or hardened several controls. The controls that came from this response are now the standard recommendations:
Read-only mode is a flag on the MCP server that restricts it to non-mutating operations. With read-only mode enabled, the agent can query but cannot modify. For the support-workflow use case in the General Analysis demonstration, read-only mode would have prevented the exfiltration from being writable back into the ticket thread.
Project-scoped mode restricts the server to a single specified Supabase project. This prevents an attacker who has obtained MCP access from pivoting across projects to find more interesting data.
Feature groups let the operator restrict which tool families the agent can invoke. For workflows that only need data access, the migration and edge-function deploy tools can be disabled, reducing the blast radius if the agent is manipulated.
The combination of read-only mode plus project-scoping plus feature-group restriction produces a hardened configuration that is substantially safer than the default. The honest reading of the July 2025 incident is that the original "service role MCP everywhere" pattern was too permissive for many production use cases, and that the defense-in-depth controls Supabase added are the right baseline for any serious deployment.
Practical agentic workflows
The workflows that have actually emerged as common production patterns:
Schema design and migration generation. A developer uses the agent to design a new feature’s data model. The agent inspects the existing schema, proposes a migration that adds the new tables and columns, and (if the developer approves) applies the migration. The pattern is fast and produces migrations that are tracked in the project’s migration history.
Data exploration and ad-hoc queries. A developer uses the agent to explore the database content. The agent generates SQL based on natural-language questions, runs the queries, and synthesizes results. This is the workflow that the read-only mode is most appropriate for; the agent does not need write access to be useful for exploration.
Backfills and data migrations. When a schema change requires backfilling data into a new column or transforming existing data, the agent can propose the SQL for the backfill, validate it on a sample, and execute it. The migration tooling supports this directly.
Log triage and incident investigation. When something goes wrong in production, the agent can fetch logs filtered by component, identify error patterns, propose investigations, and run diagnostic queries against the database. The combination of log access and database query access is meaningfully more powerful than either alone for incident response.
RLS audit workflows. Continue.dev published a guide for using the Supabase MCP server to audit RLS policies. The agent inspects the schema, identifies tables with sensitive data, checks whether RLS is enabled and whether the policies are reasonable, and generates a report. This workflow is one of the more interesting uses of the integration because it uses the MCP server’s privileged access specifically to audit the application’s normal-user-level security model.
Type generation and code sync. The agent regenerates TypeScript types from the database schema after migrations, keeping the application code’s type definitions in sync with the actual database. This is a small but operationally meaningful workflow for TypeScript applications using Supabase.
Edge function authoring. The agent designs, implements, and deploys edge functions through the deploy_edge_function tool. This brings the MCP integration into the full Supabase stack rather than just the database side.
The broader database MCP landscape
The Supabase MCP server is the most active integration in its category but is not the only option. The major alternatives:
The official PostgreSQL MCP server in the MCP reference set offers read-write Postgres access without the Supabase-specific tools. It is the right choice if you are using vanilla Postgres rather than a Supabase project.
PlanetScale ships an official MCP server focused on PlanetScale’s branching and deploy-request workflow. The server is comparatively early in its development as of mid-2026 but covers the PlanetScale-specific operations that a generic Postgres server would not.
Neon (which was acquired by Databricks in May 2025) has an MCP server that handles Neon’s specific architecture including branches and compute scaling.
Community MongoDB MCP servers exist with varying levels of polish. The official MongoDB MCP server has been progressing toward release but is not as broadly deployed as the Supabase server.
Firebase Data Connect via MCP is the Firebase equivalent, providing similar AI-agent access to Firebase’s Postgres-backed data layer.
For non-Postgres databases (MySQL, MariaDB, MSSQL, Oracle), community MCP servers exist but vary substantially in capability and maintenance.
The choice among these is usually determined by which database platform the team is already using. If you are on Supabase, the Supabase MCP server is the right answer. If you are on Postgres outside Supabase, the reference Postgres server. If you are on something else, the platform-specific server if one exists.
When to use this versus when to skip it
The right deployment of the Supabase MCP server is for teams whose engineers regularly do database work and who would benefit from agentic acceleration of that work. The benefits are real and the productivity gains for schema design, ad-hoc queries, and migration generation are substantial in practice.
The wrong deployments are for production application paths that route untrusted user input through an agent with database access. The "lethal trifecta" pattern is a genuine risk and the defense-in-depth controls reduce but do not eliminate it. For paths where untrusted input is part of the workflow (customer support, public-facing chat surfaces, user-generated-content review), additional controls beyond what the MCP server provides are necessary, including human-in-the-loop review of any database action and constrained tool surfaces that do not permit the kinds of operations an attacker would want.
The pattern that has emerged as safe practice: developer-facing MCP integrations operate with high trust and the productivity gains are realized. End-user-facing AI features that need database access route through application-layer APIs with normal authentication and authorization, not through MCP. The MCP integration is a developer tool, not a production application architecture.
Frequently asked questions
Do I need a paid Supabase plan to use the MCP server? No. The MCP server works with any Supabase project including free-tier projects. The cost scales with your Supabase usage as normal.
Will the MCP server work with self-hosted Supabase? Yes, with some configuration adjustments. The server can be pointed at a self-hosted Supabase instance through environment variables. The OAuth-based remote MCP flow is currently specific to the hosted service.
Can I restrict the agent to specific schemas or tables? Through SQL grants on the service-role credential, yes. The MCP server’s authentication is just a Supabase credential, so any restrictions you can apply through Postgres’s normal permission system apply to it. In practice this is rare because most users want the agent to have broad access for the operations the server is designed to support.
How does the MCP server handle concurrent agents on the same project? Multiple agents can connect to the same project simultaneously through different MCP server instances. The database handles the concurrency the same way it handles any concurrent application access.
Is there an audit log of what the agent did? Yes, through Supabase’s standard logging. The get_logs tool surfaces the same logs that the Supabase dashboard shows. For high-stakes deployments, consider also logging the agent’s tool invocations at the MCP server level for end-to-end traceability.
Can the agent write malicious SQL that hurts performance? Yes, in principle. A misbehaving agent could generate inefficient queries that slow the database. The mitigation is the same as for any developer-tier access: monitoring and the ability to terminate problematic queries through normal Postgres tools.
Will the MCP server work with Anthropic’s Claude API directly, without a desktop client? The MCP server is designed for use with MCP-aware clients. Direct API integration is possible but requires implementing the MCP protocol in your client code, which is feasible but not the typical use case.
How often does the Supabase MCP server get updates? Frequent. The typical release cadence has been every few weeks through 2025 and 2026, with major version updates roughly quarterly.
Is there an enterprise tier with additional controls? Supabase has been discussing enterprise MCP features (additional access controls, on-premise deployment options, audit integration) but as of mid-2026 the public surface is the same for all customers. Specific enterprise needs are typically handled through custom deployment patterns rather than tier-gated features.
Does the MCP server interact with the Supabase realtime subscriptions? Not first-class as of v0.7.0. The realtime surface is accessible through other Supabase tools and through SQL, but there is no dedicated MCP tool for subscribing to realtime events. This is one of the areas where the tool surface is likely to expand in future versions.
