Skip to main content
Glama
vuluu2k

sbuilder-mcp

by vuluu2k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

sb_duplicate

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.

Instructions

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. to_page_id (and to_site_id) pastes the copy onto another page instead, as the editor's copy/paste does: a cross-site copy has its images copied into the target library and references that cannot travel blanked and listed; the open page becomes the target.

Input Schema

NameRequiredDescriptionDefault
idYes
forceNoOverride a render-inference guard; reported as forced
indexNo
dry_runNo
parent_idNowith to_page_id: where on that page; default ROOT, before a footer
to_page_idNo
to_site_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.89.0
    • addedInput schema / properties / index
      Added value: +{
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / parent_id
      Added value: +{
+  "description": "with to_page_id: where on that page; default ROOT, before a footer",
+  "type": "string"
+}
    • addedInput schema / properties / to_page_id
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / to_site_id
      Added value: +{
+  "type": "string"
+}
  2. Changed1 schema field changedv0.63.0
    • addedInput schema / properties / force
      Added value: +{
+  "description": "Override a render-inference guard; reported as forced",
+  "type": "boolean"
+}
  3. First observedv0.1.4

TDQS

A4.2/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations (readOnlyHint=false, destructiveHint=false): nodes get fresh ids, the copy lands right after the original, cross-site copies push images into the target library, untransportable references are blanked and listed, and the open page becomes the target. This is exactly the side-effect disclosure a mutation tool needs.

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

Conciseness4/5

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

Core behavior is front-loaded in the first sentence. The em-dash framing line ('The move a designer makes constantly') is flavor rather than functional detail, but the rest is dense and earns its place.

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

Completeness3/5

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

For a 7-param mutation tool with no output schema, the description covers the primary flow and cross-site effects well but omits what force's guard override entails, what dry_run returns, and what index does. Adequate but with visible gaps.

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

Parameters3/5

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

Schema coverage is only 29%, but the description meaningfully explains to_page_id/to_site_id (paste target, cross-site semantics), which is the highest-value pair. However, force, index, dry_run, and id remain undocumented in both schema and description, leaving real gaps.

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 concrete verb and resource ('Copy a node and everything under it, under fresh ids, right after the original') with precise scope. An agent can immediately distinguish it from siblings like sb_add and sb_move without opening any 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?

Clearly explains the two invocation modes: default in-place duplication right after the original, versus pasting elsewhere via to_page_id/to_site_id. It does not name sibling alternatives or state exclusions, but the when-to-use context is strong.

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