Skip to main content
Glama

wp_replicate_node

Destructive

Duplicate an element and its whole subtree N times as siblings. THE way to build a row of cards, a pricing grid, a team list, a logo strip. Build ONE to spec, screenshot it, then replicate and swap only the content. Hand-authoring six cards produces six slightly different cards — each is another chance to typo a hex or miss a radius, and nothing holds them together afterwards. A verified source copied six times cannot drift. Every id is re-issued (elements AND repeater item _ids), because Elementor keys per-element CSS off them: duplicated ids leak styling between copies and make editing one silently change another. Response returns id_maps (original id -> new id per copy) so you can patch a specific copy's insides without re-reading the page.

Input Schema

NameRequiredDescriptionDefault
countYesHow many copies to add after the source, 1-50. A 3-up row from one built card = count 2.
dry_runNoPreview without writing.
node_idYesElement id to duplicate (from wp_get_page outline). Usually the card CONTAINER, not a widget inside it.
post_idYesPage/post numeric id
site_idYesWordPress site id
overridesNoPer-copy content, keyed by the ORIGINAL descendant id: [{"kick1":{"title":"Reliable"}},{"kick1":{"title":"Secure"}}]. Vary content only — styling should stay identical by construction.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (destructive/non-idempotent already declared), it discloses a real behavioral trait: every id is re-issued, including repeater item _ids, because Elementor keys CSS per-element id, so duplicated ids would leak styling. It also describes the return payload (id_maps) and notes the dry_run preview, giving the agent operational context the annotations do not.

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?

Front-loaded with the verb+resource, then the workflow, then the id rationale, then the return value — a sensible ordering. It is verbose in the middle ('each is another chance to typo a hex or miss a radius') and the marketing cadence costs a little, but each sentence carries information.

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

Completeness5/5

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

For a 6-parameter destructive tool with no output schema, this covers everything an agent needs: what it does, when to use it, the id-collision behavior, and the return shape (id_maps). Nothing material is missing.

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 100%, so the baseline is 3; the description adds meaning on top by explaining that node_id is usually the card CONTAINER rather than a widget inside it, and by showing how id_maps let you patch a specific copy's insides via overrides without re-reading the page.

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+resource with scope: 'Duplicate an element and its whole subtree N times as siblings.' It distinguishes itself from the many page-level siblings (wp_copy_page, wp_clone_page, wp_replace_section) by making clear it operates on a single element/subtree, not a whole page.

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?

Explicitly frames when to use it ('THE way to build a row of cards, a pricing grid...') and the recommended workflow (build one, screenshot, replicate, swap only content). It also articulates the alternative it replaces (hand-authoring six cards) and why that fails, which is the strongest form of usage guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources