Skip to main content
Glama
vuluu2k

sbuilder-mcp

by vuluu2k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

sb_page_create

Create and configure pages for a Store Builder site, choosing type, slug, locale, and seed data. Ensures required routes like /checkout are published to avoid 404 errors.

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

TableJSON 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 (default) or en — the complete page's wording.
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.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"
  2. 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"
  3. Changed1 schema field changedv0.25.0
    • addedInput schema / properties / chrome
      Added value: +{
+  "description": "Carry the site's header and footer, default true",
+  "type": "boolean"
+}
  4. 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"
+}
  5. 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"
+]
  6. First observedv0.1.4

TDQS

C2/5.0
Behavior2/5

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

Annotations only say it is not read-only and not destructive, but the description does not disclose mutation effects, required permissions, or side effects. The mention of 'need a PUBLISHED page' refers to routing, not to this tool's behavior on creation.

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?

The description is short but cryptic, leading with tangential context about store types and routing instead of stating the tool's purpose upfront. It is not effectively front-loaded and sacrifices clarity for brevity.

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?

With 11 parameters, nested objects, and no output schema, the description is inadequate. It does not explain return values, parameter relationships, or required conditions, leaving an agent unable to call the tool correctly.

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%, and the description fails to compensate for undocumented parameters like name, slug, settings, and is_homepage. It repeats 'seed:false for blank' which is already in the schema, adding no new meaning.

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 does not explicitly state that the tool creates a page; the verb 'create' is only in the tool name. It instead discusses store types, routing requirements, and seeding behavior, which obscures the core action. It also fails to differentiate from siblings like sb_page_open or sb_page_repair.

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?

No guidance is given on when to use this tool versus alternatives. It mentions sb_page_open for seeding, but does not explain when to use sb_page_create instead, nor does it provide conditions or prerequisites for invoking it.

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