sbuilder-mcp

An MCP stdio server that lets an AI agent operate a Store Builder site end to end — design its pages, fill them with real data, look at the result, and publish it — with no human clicking anything.

Tiếng Việt

Install

One command writes this server into every agent client on your machine:

npx -y sbuilder-mcp install --token wbk_… --api https://your-host

It knows Claude Code, Claude Desktop, Cursor, Windsurf, VS Code and Codex, and installs into the ones it finds. Name them with --client cursor,codex, or rehearse with --dry-run.

It merges: the servers already in those files stay, whatever it replaces is copied to <file>.sbuilder-backup, and a config it cannot parse is refused rather than overwritten — a file with a trailing comma is far likelier than one worth discarding, and it is what you need to fix it.

The store's Apps → AI agent screen hands you this command with the key already in it.

{
  "mcpServers": {
    "sbuilder": {
      "command": "npx",
      "args": ["-y", "sbuilder-mcp"],
      "env": { "SB_API": "https://api.your-host", "SB_TOKEN": "wbk_…" }
    }
  }
}

Getting the key

Open your store, go to Apps → AI agent, and press Create key. That screen hands you the config block for your client with the key already in it — this whole section is what it saves you reading.

One key is all you need. It reaches both the partner surface (/api/v1) and the private site API, including the page document and the live-edit socket, and it is bounded three ways on every request: its own scopes, the live role of the member who created it, and the single store it belongs to.

SB_EMAIL + SB_PASSWORD remain optional, and buy exactly one thing: account-level calls — listing your sites, managing members and roles — which a key deliberately cannot make, because those mean "this person's account".

SB_API defaults to http://localhost:8080. Secrets are read from the environment only.

Tools

Twenty-five tools, 412 API operations, 106 elements, 77 binding sources. sb_api_find is an index rather than a tool per endpoint, so the tool list stays short while everything the platform can do stays reachable — and operations added to the platform arrive with the next npm run codegen.

Every result is compact JSON, every directive is said once per process, and every tool carries MCP annotations — a client that honours them stops asking a person to confirm a read.

Full reference: docs/tools.md.

How it stays in sync

The platform publishes two generated, committed artifacts. A build step reads them out of a checkout and emits the catalog:

WB_REPO=/path/to/web_builder npm run codegen

So this repository vendors no platform code — it depends on two data files with a maintained contract. src/catalog/api.generated.ts is committed, so npm install needs no checkout at all.

Development

npm run build     # tsc -> dist/
npm test          # vitest
npm run smoke     # offline self-test; must print ALL GOOD

Contributor guide: CLAUDE.md. Design rationale: docs/superpowers/specs/.

Release

A push to main that touches src/** releases on its own (.github/workflows/auto-release.yml): the gate runs (build, test, smoke), the version bump is read off the commit subject — feat is minor, BREAKING CHANGE or ! is major, anything else is patch — Claude writes the changelog entry in both languages, server.json is synced, the release is committed as chore(release): vX.Y.Z and tagged, then published to npm, as a GitHub Release, and to the MCP Registry through GitHub OIDC. workflow_dispatch runs the same flow with a bump you choose. A commit whose subject contains chore(release): or release: v is skipped, so a release never triggers another.

The workflow needs two repository secrets in the prod environment: NPM_ACCESS_TOKEN and CLAUDE_CODE_OAUTH_TOKEN. The registry step needs none.

npm run release (scripts/release.mjs) is the offline path — a machine with no CI, or a release cut while a secret is being rotated. It runs the same gate and writes the same ## [x.y.z] - date changelog heading, so the two never disagree.

Designing safely

Five platform rules fail silently if a client does not know them, so they are encoded here as tested code rather than advice:

• Band order — ROOT's children must read [header][middle][footer], or the platform refuses every save.
• Site overlays (the cart drawer, pop-ups) are composed onto ROOT on read and stripped on write; they are excluded from every ROOT-level rule and cannot be edited through the page tools.
• Global sections are shared masters — editing one changes every page carrying it, and publishing cascades. Any result touching one says so.
• Responsive by default — sb_set writes per breakpoint, because a design should respond. Base is the cascade's fallback layer, not a trap.
• App blocks — a marketplace app's subtree is composed onto the page on read and reduced back to one reference node on save, so an edit inside it is lost without a word. Every write refuses the interior; the outline flags the block root app: true.

Status

All three phases shipped: authentication and full API reach; the page document, patch protocol, builder and the five traps; the live-edit socket, the yield rule, and the vision loop. Since then: a token diet across every result, and releases that cut themselves.

Requires Node ≥22 (the global WebSocket) and, for sb_look only, system Google Chrome — playwright-core bundles no browser, so installing downloads nothing.

MIT.