Skip to main content
Glama

copy_variant

Destructive

Copy a document's working version (name, slug and EVERY field) from one locale to another, server-side and atomically. USE THIS to move content that landed in the wrong language branch — re-typing it field by field loses fields.

Instructions

Copy a document's working version (name, slug and EVERY field) from one locale to another, server-side and atomically. USE THIS to move content that landed in the wrong language branch — re-typing it field by field loses fields. It REPLACES the target locale's draft (its unpublished edits are lost; its published version stays live until you publish_content the copy). The text is copied as-is: to translate it afterwards, run assist_writing {task:'translate'} and save with set_field. Returns the target locale's new draft in the get_content shape. To copy into a NEW item instead, use duplicate_content. Requires the content.update permission (Admin, Editor, Author — an Author only within their own sections).

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": {
      "documentId": "<documentId>",
      "fromLocale": "<fromLocale>",
      "toLocale": "<toLocale>"
    },
    "name": "copy_variant"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteNoSite slug or id to act in (multisite). Omit to use this server's default site. Call list_sites to see what exists — an empty tree or search usually means the wrong site, not missing content.
toLocaleYesLocale to copy TO; must differ from fromLocale.
documentIdYesThe item's documentId (stable across locales and versions), e.g. from list_tree, list_content or get_content.
fromLocaleYesLocale to copy FROM, e.g. 'en' (list_sites → locales).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.7
    • changedInput schema / properties / fromLocale / description
      Previous value: -"Locale to copy FROM"New value: +"Locale to copy FROM, e.g. 'en' (list_sites → locales)."
    • changedInput schema / properties / toLocale / description
      Previous value: -"Locale to copy TO"New value: +"Locale to copy TO; must differ from fromLocale."
  2. Changed1 schema field changedv0.1.4
    • changedInput schema / properties / documentId / description
      Previous value: -"The item's documentId (stable across locales and versions), e.g. from tree, list_pages or get_content."New value: +"The item's documentId (stable across locales and versions), e.g. from list_tree, list_content or get_content."
  3. Changed1 schema field changedv0.1.3
    • changedInput schema / properties / documentId / description
      Previous value: -"Content documentId"New value: +"The item's documentId (stable across locales and versions), e.g. from tree, list_pages or get_content."
  4. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only flag destructiveHint=true and non-idempotent; the description goes well beyond, disclosing exactly what is destroyed (the target locale's draft and its unpublished edits), what survives (published version stays live until publish_content), that the copy is verbatim text, and the auth requirement (content.update with role-scoping details). This is rich behavioral context beyond structured fields.

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?

Dense but every sentence earns its place: core action front-loaded, then destruction semantics, then translation follow-up, then return shape, then alternative tool, then permissions. No filler despite the length.

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?

No output schema exists, yet the description states the return value ('target locale's new draft in the get_content shape'). Combined with the disclosed destructive behavior, permissions, and sibling routing, an agent has everything needed to call it correctly.

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 description coverage is 100%, so all four parameters are already documented (site, toLocale, documentId, fromLocale). The description adds usage context — text copied as-is, translate via assist_writing — but no per-parameter syntax or value detail beyond the schema. Baseline 3 is appropriate when the schema carries the parameter burden.

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 (copy), resource (a document's working version) and scope (name, slug, EVERY field; locale-to-locale; server-side and atomic). It explicitly distinguishes itself from duplicate_content (new item) and contrasts with re-typing field by field, so an agent can tell it apart from siblings without opening schemas.

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?

Gives an explicit when: 'USE THIS to move content that landed in the wrong language branch'. Names alternatives with conditions — duplicate_content for a new item, assist_writing/set_field for translating the copy. When-to-use and when-to-use-something-else are both covered.

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