A coding agent can produce valid SQL and still make a poor Supabase change. It might create a view that bypasses Row Level Security, use an outdated CLI command, or guess its way through a migration. Giving it a live connection to your project solves only part of that problem. Giving it a checklist without a connection solves a different part.
The distinction is newly relevant because Supabase announced an MCP server for apps on October 22, 2026. That lets an app expose selected actions to a customer's agent. It is not the same connection as Supabase's developer MCP server, which lets a coding agent work with a developer's Supabase project. The names are similar, but the users and permission boundaries differ.
That is the practical difference between Supabase Agent Skills and the Supabase MCP server. One teaches an agent how to approach Supabase work. The other lets it inspect and act on a Supabase project through structured tools. They are often presented as alternatives, but they address different failure modes.
This comparison is based on Supabase’s current documentation and published evaluation, not on a hands-on test of these tools. The short version: start with skills when your problem is unreliable reasoning or stale knowledge; add MCP when the task needs live project context or action. For consequential work, combine them with a scoped, preferably read-only connection first.
The short version: instructions versus access
Agent Skills provide procedural knowledge. They are portable instruction files that an agent loads when a task calls for Supabase or Postgres expertise. They can tell the agent to check the current docs, use a particular migration workflow, or remember a security rule. They do not connect to your project by themselves.
MCP provides a live tool connection. Once configured, an agent can call tools to inspect tables and migrations, query logs, generate types, or perform other actions allowed by the connection. It does not automatically teach the agent when a tool is appropriate or which project conventions to follow.
Supabase describes the developer MCP connection as access to the project and Agent Skills as reusable, on-demand procedural knowledge. Its current AI tooling guide also offers a plugin that bundles both for supported agents. That framing is useful: skills are instructions, MCP is capability, and a plugin is a convenient package containing both.
A model with a database tool is not automatically a careful database engineer. Likewise, a model with excellent instructions cannot report what is in a live database unless it has some way to inspect it.
Two Supabase MCP servers, two different trust models
The developer MCP server is for building and debugging your project. It connects an AI coding tool to Supabase resources under the developer's account permissions. The tool can access data the developer can access, so project scoping, read-only mode, and limiting enabled tool groups matter. Supabase specifically warns against giving this developer connection to customers or end users.
The new app MCP server is for letting your customers use your product through their own agents. In Supabase's October 22 announcement, the example server uses OAuth to identify the signed-in customer. Tool calls use that customer's Supabase client, so the app's Row Level Security policies determine which rows that user's agent can reach. The server can expose product actions, not a general developer database console. Supabase's example avoids a service-role key and recommends keeping business rules in the same functions the app already uses.
That difference changes the design question. If you are building the product, Agent Skills can guide your coding agent, and developer MCP can give it scoped project context. If you want your customers to use your product from ChatGPT or Claude, the app's own MCP server is a separate product feature: define narrow tools, authenticate each user, and enforce access through the same authorization rules as the application. Do not expose the developer MCP connection as a shortcut for customer access.
What Agent Skills do well
They can correct repeated mistakes before a tool call happens. Supabase says it observed agents skipping Row Level Security policies, inventing CLI commands, and creating views without security_invoker = true. Its skill includes those kinds of rules and tells the agent to consult current documentation rather than relying on training data alone.
That distinction matters because documentation and implementation facts change. A skill should not try to copy an entire product manual into a prompt. The useful form is a compact workflow: identify the task, find current documentation, apply security rules, and verify the result.
The installation is straightforward for agents that support the Agent Skills standard:
npx skills add supabase/agent-skills --all
The repository provides Supabase-specific instructions, while the format is designed to work across several coding agents. That portability makes skills useful when a team uses more than one agent or wants its instructions checked into a project workflow.
Skills do not require project credentials. That is a meaningful advantage during early experimentation. You can test whether an agent follows updated docs and safer implementation guidance without first connecting it to a production project. The agent may still need an ordinary web or CLI route to look up documentation, but the skill itself is not a database credential.
Their limitation is that instructions are not enforcement. A skill can tell an agent to inspect a migration and preserve a security rule. It cannot guarantee that the agent follows the instruction, and it cannot make an unsafe action impossible. For stronger boundaries, use permissions, read-only access, isolated databases, and review gates outside the prompt.
What MCP does well
It supplies current project context. Instead of asking the agent to infer the schema from a few files, a live connection can expose tools to inspect tables, migrations, project settings, and logs. The agent can use actual project state to answer a question or prepare a change.
It supports work that ends in an action. Depending on the enabled tools and permissions, the agent may run SQL, apply a migration, or deploy a function. That can reduce handoffs for development and debugging tasks. Structured tools also give the model a defined interface rather than requiring it to invent terminal commands or parse arbitrary shell output.
But access is not a safety policy. Supabase’s own security documentation warns that data retrieved from a project can contain prompt-injection instructions. A support ticket, comment, or database row could contain text that tries to redirect the agent. If the agent has broad access, that untrusted text may influence what it attempts to do with the connection.
MCP therefore needs deliberate configuration. Supabase documents options to scope a connection to a project, make it read-only, and restrict enabled tool groups. Its guidance recommends keeping manual approval enabled for interactive work and treating approval prompts as a guardrail, not a security guarantee. Some clients can automate approvals, and some tool calls may not trigger a confirmation.
A sensible starting configuration for inspection is project-scoped and read-only:
https://mcp.supabase.com/mcp?project_ref=YOUR_PROJECT_REF&read_only=true
That URL is an example of the documented configuration shape, not a complete account-security plan. Use the current Supabase setup guide and your agent’s client documentation before connecting. Do not put tokens, secret values, or production credentials into prompts or source files.
The comparison that matters in practice
Choose Agent Skills when the problem is “the agent keeps getting the approach wrong.” Examples include stale API knowledge, forgotten RLS requirements, inconsistent migration conventions, or a team-specific verification checklist. Skills can improve the agent’s decision process without granting it access to the database.
Choose MCP when the problem is “the agent cannot see the facts it needs.” Examples include checking which migration reached a project, investigating recent logs, inspecting a schema, or performing a scoped development action. Without a live tool, the agent may be forced to reason from incomplete or outdated files.
Choose both when the task requires context and judgment. A debugging task may need live logs and schema inspection, plus instructions about which security checks to perform and how to propose a fix. In this arrangement, the skill guides the sequence while MCP supplies project-specific evidence.
There is a useful caveat in Supabase’s own evaluation. The company compared a baseline, MCP-only access, and MCP plus its Agent Skill across four agent/model configurations. It reported results over six Supabase scenarios per condition. MCP alone did not improve every baseline: Claude Code Opus 4.6 scored 58% at baseline and 50% with MCP only, while Codex GPT-5.4 stayed at 71% in both conditions. Adding the skill raised those reported scores to 67% and 88%, respectively. Supabase labels the sample small and the results early, so these numbers are evidence about those tested scenarios, not a universal benchmark or proof that skills always improve every agent.
The more useful takeaway is about task design. A tool connection can make more information available without making an agent use that information well. An instruction file can steer the agent toward the right checks, but it cannot supply missing live state. The two parts are complementary, though still not a substitute for tests and permissions.
A safe rollout you can actually use
Treat the first setup as an experiment in behavior, not as a production automation launch.
1. Start with the instructions. Install the skill in a disposable or development project, then give the agent a small task involving a schema change or a known Supabase pattern. Ask it to explain which documentation it consulted and which security requirements apply. Check its output rather than assuming that the skill loaded correctly.
2. Add a read-only MCP connection. Scope it to one non-production project and enable only the tool groups needed for the test. Ask the agent to inspect a table or diagnose a log event. Verify that its answer matches the dashboard or CLI, and confirm that it cannot write through that connection.
3. Test the failure cases. Try a task where a row contains misleading instructions. Ask for an action beyond the connection’s permission. Confirm that the agent reports the boundary instead of finding another path. Test what happens when a tool is unavailable, a query returns no rows, or the documentation and project state disagree.
4. Add write access only for a narrow workflow. If the use case is development, prefer a local or staging database and keep changes reviewable. Have the agent prepare a migration or pull request before considering automatic application. Production access should be an explicit exception with project scoping, the smallest practical permissions, appropriate approval, and a recovery plan.
5. Keep an evaluation record. Save the task prompt, expected result, observed tool calls, generated changes, tests, and human corrections. Compare the same scenarios with and without the skill or MCP connection. That will tell you whether either component improves your actual workflow, rather than relying on a vendor’s benchmark or a polished demo.
The decision checklist
Before choosing a setup, answer these questions:
- Does the task need live project data, or can the agent work from the repository and current documentation?
- Is the recurring failure missing knowledge, missing context, or missing permission boundaries?
- Can you begin with a project-scoped, read-only connection?
- Which tool groups are necessary, and which can stay disabled?
- Are approvals genuinely manual in your client, or can hooks and rules accept them automatically?
- Can the agent use a local or staging database instead of production?
- What tests and human review must pass before a change is applied?
If the first two questions point to knowledge, start with a skill. If they point to live context, add MCP with narrow access. If both are true, use both, but keep the actual security boundary in database permissions and infrastructure rather than in prompt wording.
Supabase's MCP and Agent Skills tools reflect a broader shift in coding agents: reliable work depends on both good instructions and the right tools, while user-facing agents need a separate identity and authorization design. The hard engineering choice is not “Which one makes the agent autonomous?” It is “What is the smallest combination that gives it enough context to help without granting more authority than the task requires?”
I write practical guides on software engineering and AI tools. Subscribe for free if you want more comparisons and implementation checklists.
Have you connected an AI coding agent to a live backend, or do you keep it limited to repository files? What boundary would you insist on before granting write access?
Save this rule of thumb: Skills guide how the agent should work; MCP determines what project information and actions it can reach. Begin with instructions, then add scoped read-only context, and grant writes only when a tested workflow truly needs them.
Sources: Supabase Agent Skills announcement and evaluation, Supabase Agent Skills documentation, Supabase MCP security documentation, Give your Supabase app its own MCP server.
Top comments (0)