Combine Skills and MCP to Close the Context Gap

What does an agent need to use a complex product correctly once it has tools to operate it? The debate over MCP versus skills obscures their complementary roles. Pedro Rodrigues, an AI tooling engineer at Supabase, approaches the question through the experience of writing a product skill—a document he says demanded more work than any single document since his master’s thesis. He also introduces himself as a Lisbon AI Week co-founder. The difficulty is not producing Markdown; it is deciding what guidance a complex product needs to give an agent.

A capable agent can complete routine work yet miss a feature introduced after training, omit a security requirement, or choose an awkward workflow. At Supabase, missing row-level security, or RLS, instructions can expose application data. Rodrigues also observes agents relying on stale training knowledge instead of retrieving current documentation. The missing ingredient is product-specific guidance: what must be protected, where current information lives, and how the product team expects work to proceed.

The Agent Skills format makes that guidance available progressively. A skill is a folder containing a main SKILL.md file and optional supporting resources. Its front matter supplies the name and description that help an agent decide whether to load it. The body contains instructions; bundled scripts can perform actions; reference files hold material that need not enter context immediately. This separation keeps initial context small, but it also makes later retrieval a decision the agent must actually take.

Supabase tested Claude Sonnet 4.6 with the same prompt under two conditions: access to the Supabase MCP server alone, and MCP plus the skill. The task was to create a SQL view over an existing table in a collaborative application. The table already had RLS enabled so users could see only information belonging to them. Creating a view should preserve that isolation.

The consequential detail was security_invoker = true. Under PostgreSQL view semantics, a default view uses the view owner’s permissions and RLS policies for underlying relations. A privileged owner can therefore bypass the restrictions that apply to an ordinary caller—the risk in this demonstration. Setting security_invoker = true makes the underlying checks use the caller instead. This option requires PostgreSQL 15 or later; a default view does not universally bypass every RLS policy regardless of ownership.

For a collaboration table named public.documents, the essential SQL would look like this:

CREATE VIEW public.document_summary
WITH (security_invoker = true)
AS
SELECT id, owner_id, title
FROM public.documents;

The existing table policies still determine which documents a caller can read. The view option preserves the caller’s security context rather than replacing those policies. In Rodrigues’s comparison, the skill-equipped agent included the option; the MCP-only agent omitted it and exposed data through the view. Access to a tool did not supply the knowledge needed to use it safely.

That example motivated the broader Supabase Agent Skill, which Rodrigues announced after several months of development and publicized with a live tweet on stage. Its instructions encode lessons about operating Supabase correctly. The file format provides a container, but the conventions for writing effective free-text guidance are still evolving.

The first authoring principle is to avoid duplicating product documentation. A skill should tell the agent where and how to find current information, rather than becoming a second copy that can drift. Simply providing a link may not be enough: Rodrigues found that instructions needed to insist on retrieval because agents otherwise continued from their training knowledge.

Supabase’s experimental documentation over SSH explores another way to make retrieval familiar. It exposes documentation through a virtual filesystem that agents can navigate using familiar filesystem and Linux-style tools. The premise is that an interface resembling files and directories will be easier for agents to explore. It is a documentation interface, not an unrestricted remote shell, and easier navigation remained the experiment’s premise rather than a measured result presented here.

The second principle addresses the weakness of progressive loading: optional information can remain unread. Rodrigues observes that fetching fresh information and making tool calls impose costs, encouraging agents to fall back on training data. Even loading SKILL.md does not ensure that the agent reads its references. In Supabase’s experiments, getting an agent to load two necessary reference files was difficult; expecting three or four was still less dependable.

Supabase initially placed its security checklist in a reference file and found that agents frequently missed it. Moving the checklist into SKILL.md made it part of the main instructions. This produces a useful division of responsibility:

• Current product details: Retrieve them from the authoritative documentation.
• Stable, indispensable rules: Put them directly in SKILL.md.
• Optional depth: Keep it in references when skipping it will not undermine the task.

Avoiding duplicated documentation does not mean hiding the product’s essential security rules behind another retrieval step.

The third principle is to be opinionated. A product team knows which workflows fit its system and should make that knowledge explicit. Supabase supplies a database, storage, authentication, and other backend features; an agent working with it can manipulate the database schema directly. The skill therefore needs to explain how that work should proceed, not just which commands exist.

Rodrigues describes this schema-development sequence:

1. Iterate with direct DDL on a development or staging database until the schema is satisfactory.
2. Run the advisors, which act as linters for database security and performance issues.
3. Fix the reported issues before finalizing the change.
4. Create the migration file after the schema has settled.

The development-or-staging restriction matters: this is not permission to experiment freely against production. Delaying the migration file also prevents the agent from generating a new migration for every intermediate schema edit. This is the workflow presented in the talk; the current skill has since added distinctions between declarative and imperative projects.

A skill can be evaluated through the behavior it induces. Instead of testing the Markdown as text, run an agent on a task and inspect what it does: its tool calls, reasoning, and completion of the requirements. Rodrigues treats these evaluations as analogous to CI tests, with the document supplying instructions to the system under test.

The early evaluation used six scenarios involving ongoing Supabase projects, four agent/model configurations from two vendors, and three conditions:

Task completeness was graded in Braintrust. Rodrigues describes a four-grade score, but does not define the grading levels in the talk. The design has no skill-only condition, so it tests the benefit of adding the skill to MCP rather than isolating the skill’s performance without tools.

Rodrigues reports that MCP plus the skill achieved higher task-completeness scores than either baseline or MCP alone on every tested model. The configurations were Claude Code with Claude Opus 4.6 and Claude Sonnet 4.6, and Codex with GPT-5.4 and GPT-5.4 mini. The launch article characterizes these as small-sample early results. They support the practical value of product guidance in these scenarios without establishing which particular instruction caused each improvement.

Supabase already had the MCP tools. What it needed was guidance on how to operate the product. Skills provide an agent-agnostic format with growing adoption, making the instructions reusable across supporting agents. The authoring approach follows from that: point to one documentation source of truth, prescribe the workflows that matter, and begin with a minimal skill that can expand through testing and new versions. The bottleneck here is guidance, not merely access to more context.

Rodrigues closes the main presentation by pointing to the launch post and project installation. The companion article gives the installation command:

npx skills add supabase/agent-skills

The release makes the skill available to try in a project and iterate on as its instructions evolve. Before audience questions, Rodrigues also announces a launch giveaway: scanning the displayed QR code and signing up for Supabase offered a chance to win a Mac mini.

An audience question about vector databases and RAG extends the retrieval discussion. Rodrigues reports increasing customer exploration of vectors, without giving customer counts. His particular interest is embeddings for semantic search: documentation exposed through SSH could be searched by meaning, rather than only through filesystem navigation and text matching. The proposed extension is to augment familiar Bash-style tools with semantic retrieval. It is a possibility for the SSH interface, not a capability demonstrated in this talk.

The next question is operational: how should an organization distribute its skills—directly, through repositories, or with a package manager? Rodrigues describes distribution as an unsettled part of the ecosystem. The Vercel skills CLI offers one route; plugins offer another, bundling skills with MCP servers and other components, but with packaging tied to particular agent environments.

Supabase’s internal approach is to package skills in the repositories themselves. Rodrigues gives .claude and .cursor plugin packaging as examples of making repository knowledge discoverable to an agent. The skills package can then fetch skills from public repositories or repositories the user can access. He sees other companies following the same pattern: keep the skill with the project knowledge it describes, then distribute it through the available installation mechanism. That gives teams a concrete way to ship guidance while the broader registry and plugin ecosystem continues to develop.