Komers Sites

Build the storefront

build_shop

Destructive

Write a complete storefront for the linked Komers store into the draft: product grid with search and categories, options, a cart kept in the browser, checkout through Komers (FPX/e-wallet payment and delivery handled by Komers; follows the store opening hours: while closed it offers ordering ahead for self pickup with a pickup day and time, errors show as toasts), and a product page template served at /p//. Files: shop.html (or index.html), product.html, css/shop.css, js/shop.js. Uses css/site.css if the site has one. Then link to /shop from the home page, preview_site, check_site and publish_site. Re-running replaces those four files. Layout: so shops don't all look the same, first run shop_layout_options and ask the owner how it should look on phones and desktop (product list, product details as page/popup/bottom sheet/side panel, cart as drawer/sheet/full screen, categories, phone menu bar), then pass preset and/or desktop/mobile here; that adds css/shop-layout.css and js/shop-layout.js. Later runs keep the chosen layout.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>"
    },
    "name": "build_shop"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No	"shop" = a /shop page (keep the home page), "index" = the home page is the shop	shop
`site`	Yes	Site slug (e.g. "kopitiam-muar") or id
`intro`	No
`mobile`	No	Layout choices for phones, e.g. { "detail": "sheet", "nav": "bottom" }
`preset`	No	Layout style the owner chose (shop_layout_options): classic, app, lookbook or catalogue. Leave out to keep the last one.
`desktop`	No	Layout choices for wide screens, e.g. { "detail": "modal", "categories": "sidebar" }
`heading`	No		Shop
`layout_decided_by`	No	"owner" when the owner picked the layout (the normal case); "ai" only when the owner explicitly asked you to decide	owner

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

addedInput schema / properties / layout_decided_by

Added value: +{
+  "default": "owner",
+  "description": "\"owner\" when the owner picked the layout (the normal case); \"ai\" only when the owner explicitly asked you to decide",
+  "enum": [
+    "owner",
+    "ai"
+  ],
+  "type": "string"
+}

Changed3 schema fields changedNov 10, 2026

addedInput schema / properties / desktop

Added value: +{
+  "description": "Layout choices for wide screens, e.g. { \"detail\": \"modal\", \"categories\": \"sidebar\" }",
+  "properties": {
+    "cart": {
+      "enum": [
+        "drawer",
+        "sheet",
+        "fullscreen"
+      ],
+      "type": "string"
+    },
+    "categories": {
+      "enum": [
+        "chips",
+        "tabs",
+        "sidebar"
+      ],
+      "type": "string"
+    },
+    "detail": {
+      "enum": [
+        "page",
+        "modal",
+        "sheet",
+        "side"
+      ],
+      "type": "string"
+    },
+    "list": {
+      "enum": [
+        "grid",
+        "rows",
+        "large"
+      ],
+      "type": "string"
+    },
+    "nav": {
+      "enum": [
+        "top",
+        "bottom"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / mobile

Added value: +{
+  "description": "Layout choices for phones, e.g. { \"detail\": \"sheet\", \"nav\": \"bottom\" }",
+  "properties": {
+    "cart": {
+      "enum": [
+        "drawer",
+        "sheet",
+        "fullscreen"
+      ],
+      "type": "string"
+    },
+    "categories": {
+      "enum": [
+        "chips",
+        "tabs",
+        "sidebar"
+      ],
+      "type": "string"
+    },
+    "detail": {
+      "enum": [
+        "page",
+        "modal",
+        "sheet",
+        "side"
+      ],
+      "type": "string"
+    },
+    "list": {
+      "enum": [
+        "grid",
+        "rows",
+        "large"
+      ],
+      "type": "string"
+    },
+    "nav": {
+      "enum": [
+        "top",
+        "bottom"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / preset

Added value: +{
+  "description": "Layout style the owner chose (shop_layout_options): classic, app, lookbook or catalogue. Leave out to keep the last one.",
+  "enum": [
+    "classic",
+    "app",
+    "lookbook",
+    "catalogue"
+  ],
+  "type": "string"
+}

First observedNov 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description supplies the crucial context behind that: "Re-running replaces those four files" and that layout adds css/shop-layout.css and js/shop-layout.js while later runs keep the layout. It also discloses runtime behavior the annotations cannot: store opening hours logic, ordering-ahead self pickup, and errors shown as toasts. It does not mention permissions or draft-vs-live semantics in depth, so not a 5.

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 one dense run-on paragraph packing file lists, checkout behavior, opening hours, layout guidance, and follow-up tool calls into stacked parentheticals. Most content is substantive, but the front-loading is weak and the clause nesting makes the layout prerequisite easy to miss on a first read.

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

Completeness4/5

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

For an 8-parameter mutation with nested layout objects and no output schema, the description covers what gets written, what gets replaced, how layout is chosen on first vs later runs, and which tools to call afterward. Remaining gaps are minor: no detail on heading/intro rendering or what the draft preview looks like before publish.

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

Parameters4/5

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

Schema coverage is 75% and the description adds real meaning beyond it: which parameters drive the layout (preset and/or desktop/mobile) and when those come from shop_layout_options, plus the home-page link and preview/check/publish follow-ups. It reinforces the page enum's effect and the layout_decided_by semantics, though it doesn't clarify heading or intro usage.

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

Purpose5/5

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

The description names a specific verb and artifact ("write a complete storefront ... into the draft") and then enumerates the exact outputs: product grid with search and categories, cart in browser, Komers checkout, product page at /p/<id>/<name>, and the four generated files. It is clearly distinguishable from siblings like set_shop or build_react_shop because it states the file set and the follow-up calls (preview_site, check_site, publish_site).

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

Usage Guidelines5/5

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

It gives an explicit ordering rule: first run shop_layout_options and ask the owner how it should look, then pass preset and/or desktop/mobile; later runs keep the chosen layout. It also states the when-not condition for layout_decided_by ("ai" only when the owner explicitly asked you to decide) and the page enum behavior ("shop" keeps the home page, "index" replaces it).

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

All Komers Sites tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?