Skip to main content
Glama
vuluu2k

sbuilder-mcp

by vuluu2k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

sb_api_call

Destructive

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.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
idNoOperation id from sb_api_find, e.g. "get:/api/sites/{siteID}/menus"
bodyNo
fileNoLocal file: multipart upload (field "file"); on a GET, saves the answer there
pathNoBare platform path, e.g. "/api/sites/{siteId}/published"; {siteId} defaults to SB_SITE
pickNo
mergeNoPUT: deep-merge body over the current record (arrays replace)
queryNo
methodNoWith path, when id is absent: GET|HEAD|POST|PUT|PATCH|DELETE
dry_runNoDefaults to true. Pass false to actually send.
site_idNo
if_matchNoIf-Match version; shipping-config reads it itself
max_itemsNo
item_offsetNoOffset within this response, after API paging. Reads only.
path_paramsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.89.0
    • addedInput schema / properties / file
      Added value: +{
+  "additionalProperties": false,
+  "description": "Local file: multipart upload (field \"file\"); on a GET, saves the answer there",
+  "properties": {
+    "field": {
+      "type": "string"
+    },
+    "path": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "path"
+  ],
+  "type": "object"
+}
    • addedInput schema / properties / if_match
      Added value: +{
+  "description": "If-Match version; shipping-config reads it itself",
+  "type": [
+    "string",
+    "number"
+  ]
+}
    • addedInput schema / properties / merge
      Added value: +{
+  "description": "PUT: deep-merge body over the current record (arrays replace)",
+  "type": "boolean"
+}
    • addedInput schema / properties / site_id
      Added value: +{
+  "type": "string"
+}
  2. Changed4 schema fields changedv0.63.0
    • addedInput schema / properties / item_offset
      Added value: +{
+  "description": "Offset within this response, after API paging. Reads only.",
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / method
      Added value: +{
+  "description": "With path, when id is absent: GET|HEAD|POST|PUT|PATCH|DELETE",
+  "type": "string"
+}
    • addedInput schema / properties / path
      Added value: +{
+  "description": "Bare platform path, e.g. \"/api/sites/{siteId}/published\"; {siteId} defaults to SB_SITE",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "id"
-]
  3. First observedv0.1.4

TDQS

A4.4/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: dry-run is on by default (a critical safety valve given destructiveHint=true), pick/max_items/item_offset shape the response, and oversized lists (>60 KB) self-report. It still omits error/failure behavior and auth prerequisites, so it stops short of full disclosure.

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

Conciseness5/5

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

Four telegraphic clauses, front-loaded with the two selection modes and the dry-run default before the result-shaping details. No sentence is redundant.

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 a 14-param, no-output-schema, open-world tool the description covers selection, safety default, and output shaping well. Remaining gaps (body vs merge interaction, query/path_params semantics, failure modes) are real but moderate given the schema carries part of the load.

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 only 57% across 14 params, and the description compensates by explaining pick (field selection), max_items (list cap) and item_offset (pagination) – none of which carry schema descriptions. Undocumented params such as body, query, site_id and path_params still rely on the schema or inference.

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?

States a specific verb (Call) and resource (an operation id from sb_api_find, or a raw method+path route), and explicitly positions itself against the sibling sb_api_find as the executor of what the finder resolves. An agent can tell this is the generic API-call proxy without opening the schema.

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

Usage Guidelines4/5

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

Gives clear selection conditions: use an id from sb_api_find, or fall back to method+path for routes the catalog lacks. It does not name other siblings (sb_set, sb_code, sb_look) as preferred alternatives for their domains, so no explicit exclusions are provided.

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