Your agent needs to work with Supabase. It might spin up a project, run a migration, deploy an edge function, or pull a report from a customer's database. Supabase ships an official MCP server and a full REST surface, and they are not the same object. They cover different operations, sit on different auth models, and one of them is explicitly scoped to development only. Here is how to pick.
There are three surfaces in play, not two, and getting them straight is the whole decision. Two of them are control plane. One of them, the one most production agents actually need, is neither.
Supabase launched its official MCP server in April 2025. The hosted version runs at https://mcp.supabase.com/mcp over HTTP, and the package @supabase/mcp-server-supabase covers local and self-hosted use. It exposes roughly 30 tools across eight feature groups: docs, account, database, debugging, development, functions, branching, and storage. Every group except Storage is on by default.
The MCP server is a build-time assistant for tools like Cursor, Claude Code, and Windsurf. It wraps management operations and SQL execution behind natural language. Supabase is direct about its intended use: it is designed for development and testing, you should not connect it to production data, and you should not give it to your customers, because it runs under your developer permissions rather than any end user's.
The Management API is the control plane at https://api.supabase.com/v1. It manages organizations, projects, database branches, migrations, edge functions, secrets, API keys, custom domains, network restrictions, and SSO providers. Every non-SQL MCP tool is a thin wrapper over an endpoint that already exists here. Rate limits default to 120 requests per minute, isolated per user and scope.
Neither surface reads or writes your application's rows on behalf of an end user. That is the auto-generated Data API at https://<project-ref>.supabase.co/rest/v1/, authenticated with a publishable key (sb_publishable_), a secret key (sb_secret_), or a user's Supabase JWT, with Row Level Security gating every row. If your agent's job is to act on user data, this is the surface, and the MCP-versus-API debate above is the wrong debate.
On the control plane, the MCP server and the Management API overlap heavily but not completely. The gap is real and predictable: the MCP server covers the common developer loop, and the Management API covers the long tail of platform operations.
The MCP server can read a project's publishable keys through get_publishable_keys, but it cannot create or rotate secret keys, manage Edge Function secrets, or configure custom domains and network restrictions. Those operations only exist on the Management API. If your agent's job touches key rotation, domain setup, or org-level governance, the MCP tool surface is missing the tools by design.
This is the point that a straight capability comparison hides. The MCP server's execute_sql runs under your developer connection, not under the identity of the person the agent is helping. It does not evaluate Row Level Security per end user. An agent that needs to answer "show me my orders" for a specific customer cannot get correct, isolated results from either the MCP server or the Management API. That is a Data API job, with a user JWT and RLS, and Supabase publishes a separate @supabase/mcp-server-postgrest package for exposing it to your own users.
Both control-plane surfaces authenticate against your Supabase account. The difference is in how the credential is obtained, how narrowly it can be scoped, and whether a background agent can use it at all.
By default the hosted MCP server uses OAuth 2.1 with dynamic client registration, so a browser login grants the client access to your organization without a manually created app. For CI, you pass a personal access token (sbp_) in the Authorization header. One constraint matters for security review: the MCP server has no fine-grained scopes yet, so an OAuth app you create for it is granted write access to every available scope.
The Management API takes the same personal access token, or an OAuth 2.0 authorization code flow with PKCE that returns short-lived access tokens and refresh tokens on behalf of a user. OAuth apps are published in your organization's settings, and tokens are tied to specific scopes. For an agent that should hold narrow, revocable, per-user authority, this is the surface that expresses it.
For a B2B agent serving 40 developers across 8 customer organizations, either path produces one credential per user. The MCP path gives you an account-level token per user; the Management API gives you a scoped OAuth token per user. In neither case does Supabase store, refresh, or revoke those credentials for you. That is infrastructure you build or buy, and it is the same problem on both paths. See access control for multi-tenant agents for why shared credentials break on the second user.
The MCP server offloads hosting and schema maintenance. The Management API gives you version control and headless execution. What you own with each is different, and it changes what breaks.
Supabase manages the hosted endpoint, scaling, and tool schemas. You own token storage per user, the choice of feature groups and read-only mode, and the fact that tool definitions can change when Supabase ships a server update, with no versioning contract to pin against. You also own the prompt-injection surface: SQL results can carry instructions, and Supabase wraps results with defensive text but calls it out as not foolproof.
You own endpoint selection, request construction, retries, pagination, and the full token lifecycle. You also inherit two specific constraints: applying migrations is limited to approved partner OAuth apps, and daily rate limits are consumed by every call your agent makes. The tradeoff is stability. Endpoints are versioned and change on a deprecation schedule, which a deterministic pipeline can depend on.
MCP tool calls route through the same Management API and SQL execution underneath, so they draw down the same 120-requests-per-minute budget. An agentic workflow issues several sequential calls per user action, so the math moves faster than a traditional integration. Monitor usage from day one, and treat an unexpected MCP schema change as an incident risk that direct, versioned endpoints do not carry. For more on why MCP can be unexpectedly costly, see MCP is up to 32× more expensive than CLI.
Both are legitimate. The deciding factor is whether a human is driving an interactive session or an unattended service is running against Supabase on a schedule.
Scalekit's Supabase connector is built on the Management API and ships over 160 tools with LLM-ready schemas. It runs the per-user OAuth flow, vaults and refreshes tokens, and scopes each agent to the tools the current user authorized. The connection name is supabase, created once in the dashboard.
Before any agent code, the important call is discovery. list_scoped_tools does not return a flat catalog of Supabase operations. It returns only the tools the current user's connected account is authorized to call, which is what separates a per-user agent from a shared-credential one. Giving an LLM all 160 tools degrades tool selection and burns tokens; scoping to the handful this user needs fixes both. What the user cannot do, the agent cannot do.
This runs the standard Anthropic tool-use loop. Scalekit returns tool definitions in Anthropic's native format, resolves the current user's Supabase token from the vault, and makes each call as that user.
The Node SDK returns LangChain-ready tools from listScopedTools. Filtering by toolNames narrows the surface further, so this agent sees only branching, migration, and type-generation tools rather than the full connector.
If your client speaks MCP, you do not have to run the official server or host your own. A Virtual MCP Server gives you one server definition, per-user credential isolation, and least-privilege tool access. The agent sees only the tools you explicitly allow, not everything the connector exposes. One definition serves all users; before each run, a short-lived session token is minted scoped to that user's connected accounts. There is no MCP server to deploy, host, or maintain. For the decision on when this fits, see when to use a Virtual MCP server.
Supabase's own MCP guidance recommends logging every tool call for auditing, and this is where a shared token leaves you blind. Scalekit records each downstream call the agent makes: which user, which tool, which connected account, and the result. Those agent tool observability logs are queryable, so a cross-tenant call or a revoked grant surfaces in your records rather than in an incident.
The auth divergence between MCP and the Management API is real, but it sits on top of a problem both paths share and neither fixes.
Both paths give you a token per user. The MCP OAuth flow gives you an account-level token; the Management API gives you a scoped OAuth token. Both are correct starting points, and both expire. What Supabase hands you is a credential, not a lifecycle.
For 40 users across 8 customer orgs, that is 40 tokens to store encrypted, 40 to refresh before they expire, and 40 to revoke when someone leaves. The MCP path adds the all-scopes grant to the risk; the Management API path adds refresh-token rotation. The token lifecycle is identical work whichever surface you choose.
Scalekit's Supabase connector runs the per-user OAuth flow, vaults and refreshes tokens, and scopes each agent to what the user authorized, for both direct tool calls and a Virtual MCP endpoint. Credentials never touch the agent runtime. The MCP-versus-API decision no longer changes your credential infrastructure. For the underlying model, see OAuth for AI agents.
If your agent is an interactive assistant a developer drives inside an IDE, against a non-production project, the Supabase MCP server is the fast path; keep read-only and project scoping on. If your agent is headless, multi-tenant, or touches key management, domains, or governance, use the Management API directly, or through Scalekit, for scoped OAuth and versioned endpoints. And if your agent acts on application data for a specific end user, neither is the answer: that is the Data API with RLS. Most production Supabase agents will use more than one plane. The credential management problem is the same across all of them, and that is what needs production-grade infrastructure.
Browse the Scalekit Supabase connector, read the connector docs, or explore the full connector catalog. Templates like the DevOps assistant agent and the incident response agent are good starting points, and pricing is usage-based with every feature unlocked.
Building a Supabase agent and want a second set of eyes on the auth model? Join the Scalekit Slack community, or talk to an engineer for immediate help.
