Skip to main content
Glama
vuluu2k

sbuilder-mcp

by vuluu2k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

sb_page_create

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.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
nameYes
seedNoDefault true; false creates a blank page.
slugNo
typeNoomit: inferred from the name (about/contact/policy/faq), else page; sb_page_list lists every type
chromeNoCarry the site's header and footer, default true
localeNovi or en — a store seed's wording; defaults to the site's language, else vi.
dry_runNo
site_idNo
headlineNoThe complete page's thank-you line.
settingsNo
is_homepageNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.89.0
    • changedInput schema / properties / locale / description
      Previous value: -"vi (default) or en — the complete page's wording."New value: +"vi or en — a store seed's wording; defaults to the site's language, else vi."
  2. Changed1 schema field changedv0.69.0
    • changedInput schema / properties / type / description
      Previous value: -"page (default); sb_page_list lists every type and where each is served"New value: +"omit: inferred from the name (about/contact/policy/faq), else page; sb_page_list lists every type"
  3. Changed1 schema field changedv0.60.1
    • changedInput schema / properties / type / description
      Previous value: -"page (default), checkout, product, category, post, course"New value: +"page (default); sb_page_list lists every type and where each is served"
  4. Changed1 schema field changedv0.25.0
    • addedInput schema / properties / chrome
      Added value: +{
+  "description": "Carry the site's header and footer, default true",
+  "type": "boolean"
+}
  5. Changed3 schema fields changedv0.16.0
    • addedInput schema / properties / headline
      Added value: +{
+  "description": "The complete page's thank-you line.",
+  "type": "string"
+}
    • addedInput schema / properties / locale
      Added value: +{
+  "description": "vi (default) or en — the complete page's wording.",
+  "type": "string"
+}
    • addedInput schema / properties / seed
      Added value: +{
+  "description": "Default true; false creates a blank page.",
+  "type": "boolean"
+}
  6. Changed4 schema fields changedv0.12.0
    • addedInput schema / properties / is_homepage
      Added value: +{
+  "type": "boolean"
+}
    • addedInput schema / properties / slug
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / type
      Added value: +{
+  "description": "page (default), checkout, product, category, post, course",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "site_id",
-  "name"
-]New value: +[
+  "name"
+]
  7. First observedv0.1.4

TDQS

C2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is partly covered. The description adds scoping facts (store types carry bound content, seed default true vs blank, chrome default true, locale default), which is some useful context, but it is impenetrable and omits auth requirements, idempotency, and slug-collision behavior for a write tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short but poorly structured and jargon-dense; the lead clause dangles and the key action is buried. Sentences mix seeding rules, routing, and type semantics without a clear front-loaded statement, so length is not the issue — clarity and ordering are.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter write tool with nested settings, no output schema, and 45% schema coverage, the description is far too thin and muddled. It should explain the create semantics, type branching, and the undocumented parameters but does not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 45% with 11 parameters, so the description must compensate. It touches seed, type, and slug context but leaves name, dry_run, site_id, settings, is_homepage, and locale largely unexplained, and its phrasing adds confusion rather than meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description never states the primary action (creating a page) in a clear verb+resource form; instead it opens with a list of store types and route behavior. An agent has to infer 'create' from the name and the scattered hints about types and seeding. It distinguishes few siblings and even pulls in routing facts unrelated to the create action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There are fragments of guidance ('seed:false for blank', type inference, sb_page_open seeds its ROOT), but no clear statement of when to use this tool versus sb_page_open, sb_page_update, or sb_page_list. The routing remark about /checkout and /products/{slug} does not tell the caller when this tool is the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools