butterbase-skills: A Claude Code Plugin That Wraps 42+ Butterbase MCP Tools

The gap butterbase-skills fills is context, not capability

Butterbase describes itself as an AI-Native Backend-as-a-Service and exposes more than 42 MCP tools. An MCP server alone does not tell a model which tool to reach for when someone types "build me a blog with auth and comments." The model sees a list of tool names and has to guess the order of operations, the naming conventions, and the environment variables involved. The plugin exists to close that gap. It ships a CLAUDE.md file that the README describes as always-on context covering environment variables, workflows, patterns and documentation references, plus six skills that encode specific procedures. The audience is narrow and specific: developers who have already signed up at butterbase.ai and who drive their work through Claude Code. If you are evaluating backend platforms and have not picked one, this repository tells you nothing useful, because every skill in it assumes a Butterbase project already exists.

Six skills, and what each one actually encodes

The README lists the skills with example prompts, which is the clearest signal of scope. `butterbase:build-app` covers building a complete app from scratch, with "Build me a blog with auth and comments" as the sample prompt. `butterbase:schema-design` handles database schema design. `butterbase:deploy-frontend` deploys frontends to live URLs. `butterbase:debug-rls` targets Row-Level Security problems, and its example prompt is the telling one: "Users are seeing each other's data." That is a data-leak symptom, and the fact that a dedicated skill exists for it suggests RLS misconfiguration is a recurring failure mode in this stack rather than a rare edge case. `butterbase:function-dev` covers serverless functions, with a cron job for cleaning up expired sessions as the example. `butterbase:contributing` is aimed at people modifying Butterbase itself, with "How do I add a new MCP tool?" as the prompt. Note that the last skill is not about using the product. It is about extending it, which means the plugin serves two distinct audiences that the README does not separate.

How the plugin wires itself into Claude Code

Three files carry the weight. `.mcp.json` auto-configures the Butterbase MCP server connection over an HTTPS endpoint. `CLAUDE.md` supplies the always-on context. The six skills provide the guided workflows. According to the README, the plugin auto-loads its skills and CLAUDE.md context as soon as Claude Code starts, and all 42+ tools become available immediately after consent. The data flow is therefore: Claude Code starts, reads the plugin's context files, registers the MCP server from `.mcp.json`, and the model can then call Butterbase tools during a session. The skills act as routing hints layered on top of that tool surface. There is no local daemon and no build step described. That is a simple architecture, and it is also why the plugin is only as good as the MCP server behind it: if a tool is missing from the server, no skill can conjure it.

Install and setup: two commands and an OAuth consent

The README gives a short path. Install the plugin with `claude plugin add @butterbase/skills`. Then install the MCP server across every detected client with `npx @butterbase/cli mcp install`, which the README says walks Claude Code, Cursor, VS Code, JetBrains, Codex, Gemini CLI and others, printing per-client OAuth follow-up hints. Finally, trigger OAuth once per client. In Claude Code that means restarting and running `/mcp`, or `claude mcp login butterbase`. The README states that sign-in is OAuth and that no API key copy-paste is needed. If you are running the Butterbase monorepo locally, the MCP server URL defaults to `http://localhost:4000/mcp`, and you set `export CONTROL_API_URL=http://localhost:4000` in your environment. That is the only config key named in the README. Everything else about the connection is handled by the plugin's `.mcp.json`.

OAuth per client is the friction the README understates

The setup section is honest that consent is per client, but the practical consequence deserves more weight than a bullet point. The `mcp install` command detects many clients and prints hints for each, yet the README still says to trigger OAuth once per client. If you work across Claude Code and Cursor and VS Code, that is three separate consent flows, each tied to a browser round trip. The plugin itself only auto-loads in Claude Code; the other clients get the MCP server connection and whatever their own context mechanisms provide, not the six skills. So the multi-client story is really a multi-client MCP story with Claude Code as the only place the skills apply. Anyone who reads "walks Claude Code, Cursor, VS Code, JetBrains, Codex, Gemini CLI" as a promise of uniform experience will be disappointed. It is uniform connection, not uniform capability.

The limitation that matters: this is vendor lock-in by design

Every skill in this plugin drives Butterbase APIs. The `butterbase_docs` MCP tool returns Butterbase reference documentation. The environment variable points at a Butterbase control API. There is no adapter layer, no export path, and no described mechanism for pointing these skills at a different backend. If you later migrate off Butterbase, the plugin becomes dead weight in your Claude Code config and you must remove it and rebuild whatever workflow knowledge you had accumulated inside those skills. That is a real cost, and it is not mentioned in the README. The second limitation is verification. The README claims 42+ MCP tools but does not enumerate them, and the repository has no published GitHub releases, so there is no changelog to check when a tool changes shape. When a skill's assumptions drift from the server's actual tool signatures, the failure will surface as a confused agent rather than a clean error.

How this differs from a general database MCP server

A general-purpose database MCP server, such as one that connects to Postgres and exposes schema inspection and query execution, takes the opposite approach. It knows nothing about your application's intent. It will list tables and run SQL, and the model must derive the workflow itself. butterbase-skills inverts that: it hard-codes the workflow and delegates the primitives to a hosted platform. The trade-off is concrete. With a general Postgres MCP server you keep portability and pay in prompt engineering, because you must teach the model your conventions yourself. With butterbase-skills you get the conventions for free and pay in portability, because the conventions only apply to one vendor. Neither is wrong. They answer different questions. The general server answers "how do I let an agent touch my existing database." This plugin answers "how do I let an agent build on Butterbase without me writing a system prompt first."

Maintenance, licensing and what to check before adopting

The repository is MIT-licensed, which permits commercial use, modification and redistribution with the licence text retained. That covers the plugin code. It does not cover the Butterbase service, which is a separate hosted product with its own terms, and the README does not describe those terms, so treat the MIT licence as applying to the plugin only. On maintenance: the last push recorded is 2026-06-28, the repository is not archived, and it has no published GitHub releases. With no release history, there is no way to tell from this material how often the skills are updated relative to the MCP server's tool surface. That coupling is the thing to verify. Install the plugin, restart Claude Code, run `/mcp`, and confirm the Butterbase tools appear and that a skill such as `butterbase:debug-rls` can be invoked by name. If the skill list and the server's tools have drifted apart, you will see it there first.

Editorial conclusion

Adopt butterbase-skills if you have already committed to Butterbase as your backend and you work inside Claude Code, because the plugin only makes sense on top of that account. Skip it if you are backend-agnostic, if you do not use Claude Code, or if you want a tool that inspects and reasons about an existing database rather than one that drives a specific vendor's API. Before installing, verify three things: that `claude plugin add @butterbase/skills` resolves in your Claude Code version, that the OAuth consent screen shows the Butterbase account you intend to use, and that `/mcp` lists the Butterbase tools after a restart. The plugin is MIT-licensed, so the licence is not the constraint. The account is.

Frequently asked questions

Official sources

1. butterbase-ai/butterbase-skills on GitHub
2. Issues
3. License: MIT
4. README