Skip to main content
Glama

modx_duplicate_resource

Duplicate a MODX resource and optionally copy its child resources, set a new pagetitle, and preserve, publish, or unpublish the duplicate.

Instructions

Duplicate a resource. id = source resource; optional name (new pagetitle), duplicate_children (bool), published_mode (preserve|publish|unpublish).

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": {
      "id": "<id>"
    },
    "name": "modx_duplicate_resource"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
nameNo
published_modeNo
duplicate_childrenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.4

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description carries the full burden and discloses almost nothing behavioral: it does not say whether the duplicate is published by default (beyond the enum values), whether children are copied recursively, whether aliases are auto-adjusted, what permissions are required, or whether the original is untouched. For a mutation tool with zero annotation coverage, this is a substantial gap.

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?

One front-loaded sentence stating the action, followed by a compact, scannable parameter rundown. Nothing is wasted and the purpose is stated before the parameter details.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the definition should at minimum say what is returned (e.g., the new resource ID) and the key side effects such as alias/cache handling. Neither is present, leaving real gaps an agent would need in order to call and use the result correctly.

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 description coverage is 0%, yet the description compensates well by naming all four parameters and giving real meaning: 'id' = source resource, 'name' = new pagetitle, 'duplicate_children' as a boolean, and the three published_mode values. It stops short of stating defaults or whether nested descendants are included, so it is strong but not complete.

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

Purpose4/5

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

States a specific verb and resource ('Duplicate a resource') that an agent can act on immediately. It does not, however, distinguish itself from the sibling modx_duplicate_element or clarify the resource-vs-element boundary, which matters in a toolset of 150+ similarly named tools.

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

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance is given. The description never mentions the sibling modx_duplicate_element, modx_bulk_resources, or modx_create_element, so an agent must infer on its own that this tool is for site resources rather than template elements.

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