Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
SB_APINoThe base URL of the Store Builder API. Defaults to http://localhost:8080.http://localhost:8080
SB_EMAILNoOptional email for account-level calls (e.g., listing sites, managing members and roles).
SB_TOKENYesThe API key for the store. Create one in the store's Apps → AI agent screen. Required to access the store API.
SB_PASSWORDNoOptional 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

Find API operations by intent (query), or get a call sheet (id): parameters, credential, body fields and handler caveats. Reaches all 574 operations.

sb_api_callA

Call an operation from sb_api_find (id), or a route the catalog lacks (method+path); dry run by default. pick selects fields, max_items caps lists, item_offset skips items. Lists over 60 KB say 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_page_repairA

Rename a page root that is not "ROOT" (sppro_1, rt_ — left by older seeds) to ROOT, for one page or, without page_id, every page on the site. Draft only; a published page is listed for re-publishing. dry_run (default true) lists what would change.

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 it does — or OMIT query to browse every type, the only way to meet one you would not have searched for. detail:true adds the AI hints, as does sb_traits_for.

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_createC

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_publishB

Compile the draft into the live page, and report which revision went live (id, publishedAt, fromVersionId). 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. verify:true then fetches the live page and says whether the origin is serving that revision yet — the storefront caches for 60s, so a reload showing the old page is that, not a failed publish.

sb_page_stateA

Which of this page's three copies is which: the DRAFT the editor canvas shows, the PUBLISHED row the storefront serves, and what this session holds. Says whether the editor will render the canvas BLANK (its hydrate gate discards a document whose root is missing and shows an empty ROOT, silently — the Go renderer has no such gate, which is how "the live page has data but the canvas is empty" happens), whether the draft has changes the live page does not, and where the recovery points are.

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 — query returns real photographs with their own descriptions, and pick uploads the one you chose, or several at once to stock a site you just built. The only way to add an image.

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_bindB

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:"checkout_sync" re-reads the store's payment and delivery methods into every existing order form and republishes the checkout page — run it after adding a shipping method or switching on a gateway, since the form keeps the options it was saved with. 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 (footer:true — footer) built on a real site menu of page/category/product references: a desktop menu, a mobile drawer, cart and account icons — the gap sb_review reports as siteChrome. action:"menu" binds a menu node on the open page to the site's menu and resolves its links, the way the editor does. action:"overlay_attach" puts a pop-up on the open page (kind:"popup") or points a list-dataset at a quick-view panel (kind:"quickview", list_id), creating either from the platform's own seed when overlay_id is omitted, and re-reads the page afterwards as the editor must. action:"cart" creates the site's cart drawer from the editor's seed when it has none — without it every open_cart control opens nothing. action:"app" installs one of the platform's built-in apps (app_key) and creates the pages it needs that installing it does not — today only "courses" has any, from the platform's own scaffold; every other key installs with nothing further to build. action:"global_attach" puts an EXISTING shared section (global_id) on the open page and action:"global_detach" takes it off, writing the reference the platform reads and placing it in the band ROOT's child order demands — the answer for a page that is missing the site's header, where action:"chrome" would wrongly build a second one. 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. colors and text_styles PATCH the saved document: what you do not name is kept. locale sets the site's language (settings.locale, what is served from) — site-wide, every other setting kept.

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_siteB

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3/5.0

Scored across 33 tools

Disambiguation3/5

Many tools target distinct resources and actions (media, page, node, API, templates), but sb_connect and sb_site_list substantially overlap, and sb_store's many named actions overlap with specialized tools like sb_add, sb_bind, sb_event, and sb_template_use. Descriptions help clarify boundaries, but selection is not always crisp.

Naming Consistency3/5

All tools use an sb_ prefix and snake_case, which is readable, but the naming grammar is mixed: pure verbs (add, set, move), noun_verb forms (media_upload, page_list, api_find), and plain nouns (event, theme, store). This is not a predictable verb_noun pattern, though it remains understandable.

Tool Count2/5

33 tools is high for one MCP surface; while the domain is broad, several tools could be consolidated (connect/site_list, import/import_site, and the sb_store mega-tool). This exceeds the 25+ threshold associated with excessive tool count.

Completeness4/5

The surface covers the main lifecycle: login/list sites, create/open/read/edit pages and nodes, media upload/list, templates, binding/events, publish, state, review, look, undo, import, and store flows via sb_store. Gaps like explicit page delete, site create/delete, and media delete are mitigated by sb_api_find/sb_api_call reaching the full API, so the surface is broadly complete with minor workarounds.

Maintenance

ActivityMaintained
ResponsivenessNo issues