sbuilder-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SB_API | No | The base URL of the Store Builder API. Defaults to http://localhost:8080. | http://localhost:8080 |
| SB_EMAIL | No | Optional email for account-level calls (e.g., listing sites, managing members and roles). | |
| SB_TOKEN | Yes | The API key for the store. Create one in the store's Apps → AI agent screen. Required to access the store API. | |
| SB_PASSWORD | No | Optional password for account-level calls. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sb_connectA | Log in and list the sites this account can operate. Call this first. Reads SB_EMAIL and SB_PASSWORD from the environment unless you pass them. |
| sb_site_listA | List the sites this account can operate. |
| sb_api_findA | Search platform API operations by intent (query: one line per match), or read one operation's full call sheet (id: parameter types, credential, and the body's fields with the traps their own doc comments carry, read off the handler that decodes them). Reaches all 524 operations. |
| sb_api_callA | Execute one operation from sb_api_find. Defaults to a dry run that sends nothing and shows the request. pick keeps only named fields on list items, max_items caps the list, and a list over 60 KB is cut to fit and says so. |
| sb_page_openA | Open a page for editing and return its outline. Call before any sb_add / sb_set / sb_move / sb_remove. Find page ids with sb_api_find "list pages". |
| sb_outlineA | The open page as a compressed tree — id, type, name, child count, band, and whether a node is a shared global or a site overlay. Never the raw document: a real page is hundreds of KB of JSON. |
| sb_node_readA | One node in full — style, config, specials, per-breakpoint overrides, bindings. |
| sb_catalog_searchA | Find an element type by what you want it to do. Four fields per match; pass detail:true for the platform's AI hints, or read them with sb_traits_for once you have chosen. |
| sb_traits_forA | This element's INSPECTOR, as a person sees it: tabs, groups, and every control name — with what each DECLARED control writes, and the AI hints for using the element. Read this before styling an element; pass control to read one control in full. |
| sb_addA | Add an element — or a whole NESTED subtree — under a parent. One call builds a complete section: pass children rather than calling this once per node. |
| sb_setA | Write style, config or specials keys on one node, or on many through edits (one save, one live frame). Per BREAKPOINT by default; base:true writes the fallback layer, right for a value that should not vary. |
| sb_moveA | Move a node to another parent at an index. |
| sb_removeA | Remove a node and its whole subtree. |
| sb_reviewB | What a VISITOR would meet on the open page (blank band, placeholder, dead binding) AND what stands between this store and a paid order (checkout page, gateway, delivery, a way back to the cart). Run it before calling a page finished. |
| sb_duplicateA | Copy a node and everything under it, under fresh ids, right after the original. The move a designer makes constantly — build one card, duplicate it twice. |
| sb_templatesC | The store's saved section templates — designed sections a person starts from rather than assembling one. Use sb_template_use to drop one into the open page. |
| sb_template_useA | Instantiate a section template into a page — the site's own (the server copies it) or one of the BUILT-IN layouts sb_templates lists, which are composed against this page's own tokens rather than copied. |
| sb_page_listA | Every page on the site, with its slug and whether it is live. |
| sb_page_createD | A store type (product, category, search, blog, post, complete) arrives with the document the editor gives a merchant — product carries the whole bound buy box; seed:false for blank. Any other type is empty and sb_page_open seeds its ROOT. TYPE is the route: /checkout and /products/{slug} need a PUBLISHED page of that type or they 404. |
| sb_publishA | Compile the draft into the live page. PUBLISH CASCADES: a page sharing a global section with others republishes them too, because a header edited once must not go live on one page and stay stale on the rest. |
| sb_live_joinA | Join the site's live-edit room as a visible peer: every write then appears in any open editor as it happens, with the agent shown by the API key's own name rather than a person's. Always yields, so it is safe beside a human. Works with SB_TOKEN or with SB_EMAIL / SB_PASSWORD. |
| sb_lookA | Save, render through the platform's own renderer, and return screenshots at desktop, tablet and mobile widths, measured boxes for the bands and their children, and any layout defect measured on the render (overflow, overlap, unreadable text). node_id frames one element. Judge your work from these, not from memory. |
| sb_media_listA | The site's media library. Reuse an image before adding another; search by name, filter by type, page with limit/offset. |
| sb_media_uploadA | Put an image into the media library and get its URL back, ready for sb_set. Takes a local path, a URL, or a SEARCH — |
| sb_eventA | Give a node a click action — open the cart, go to a page, open a pop-up. A purchase is not one: use sb_bind action. |
| sb_bindC | Bind a node to real store data so the page shows actual products, not placeholder text. action makes a button a purchase control. |
| sb_storeA | Run a store flow that must happen in a fixed order. action:"checkout" makes the order form, configures it, saves its fields with this store's real payment and delivery options, then creates and PUBLISHES the checkout page — /checkout 404s without all four. action:"form" seeds any of the platform's other form templates (login, register, forgot, reset, verify, contact, subscribe, booking, review and more) with its own field document, which is the part that cannot be guessed. action:"chrome" gives every page ONE shared header, built from the pages this site already has — the gap sb_review reports as siteChrome. Dry run returns the plan. |
| sb_themeA | The site's palette and type scale — the layer every element's style preset resolves from, so one token repaints every page at once. Call it with nothing to read what the site actually has. |
| sb_importA | Read a page from any public URL and add its structure and content to the OPEN page as real elements, styled with this page's own tokens. Not a clone: the source's layout and CSS are not copied. Dry run returns what was found. |
| sb_import_siteA | Read a WHOLE site from one URL — its sitemap, or the links on that page — and give each page found its own DRAFT page here, built from this site's tokens. Not a clone. Dry run returns the page list before anything is created. |
| sb_undoA | Put back what a PUT through sb_api_call replaced — settings, a product, a form, anything with a shape. IN THIS PROCESS ONLY, capped, and gone when it exits. For a PAGE the platform keeps its own: GET .../pages/{pageId}/history lists the autosave checkpoint it writes on every draft save, versions lists the labelled snapshots, and either restores. That one survives everything and is the better answer whenever the thing to recover is a page. No argument lists what is undoable here. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 31 tools
Most tools target clearly distinct operations (add vs move vs duplicate vs remove; find vs call; page_open vs page_create vs publish), and the descriptions explicitly resolve tricky pairs like sb_event vs sb_bind and sb_import vs sb_import_site. Minor overlap remains between sb_connect and sb_site_list (both list sites) and among the several content-insertion tools, but boundaries are largely legible.
Every tool shares a uniform sb_ prefix and groups cleanly into namespaces (sb_page_*, sb_media_*, sb_api_*, sb_template_*), which is easy to scan. The only deviation is mixed verb-only (sb_add, sb_set, sb_remove) versus noun_verb (sb_page_open, sb_node_read) forms, but this split is internally systematic and readable.
At 31 tools the surface is heavier than the ideal 3-15 range and pushes into the 'too many' band, though the domain (page building, media, themes, store flows, imports, raw API access) is genuinely broad. Each tool covers a distinct facet, but some (catalog/traits/api_find/api_call) could plausibly be consolidated.
Coverage is strong: pages (list/open/create/publish), nodes (add/set/move/remove/read/duplicate), media (list/upload), templates, theme tokens, bindings, store flows, imports, review/look, undo and live-join are all present. The main gaps are explicit page/media deletion or page-update tools, which an agent must fall back to sb_api_call to perform.