Skip to main content
Glama
Sign In
MODX MCP

MODX MCP

by rumata-estor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

modx_bulk_resources

Apply publish, unpublish, set-template, move, or delete operations to many MODX resources by IDs or filters; preview changes with dry-run before applying.

Instructions

Apply ONE operation to many resources at once: publish, unpublish, set_template (needs template), move (needs parent_to and/or context_to), or delete. Select targets by explicit ids OR by a parent/context/query filter. ALWAYS run dry_run:true FIRST — it reports the change per resource (and child-resource counts for delete) without applying. Changes go through the core resource processors (correct URI/events). Note: delete is a soft delete (moves resources to the MODX trash, recoverable), matching the manager.

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": {
      "operation": "<operation>"
    },
    "name": "modx_bulk_resources"
  }
}

Input Schema

NameRequiredDescriptionDefault
idsNoExplicit resource ids (preferred).
limitNoMax resources to touch (default 200).
queryNoFilter: pagetitle/alias/uri substring.
parentNoFilter: select children of this parent id.
contextNoFilter: context key.
dry_runNoPreview the change per resource without applying. Do this first.
templateNoFor set_template: the new template id. Use 0 to assign no template (MODX empty template).
operationYes
parent_toNoFor move: the new parent id.
context_toNoFor move: the new context key.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.4

TDQS

A4/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full burden. It does well on some points — delete is disclosed as a recoverable soft delete to the MODX trash, and changes are said to run through core resource processors so URIs/events stay correct. However, it says nothing about required permissions, partial-failure behavior across a batch, or what the per-resource report looks like, which are the key risks for a bulk mutation tool.

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 tight sentences, front-loaded with the operation list, then targeting, then the dry-run prerequisite, then the delete caveat. No padding; each sentence conveys a distinct operational fact.

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 10-parameter destructive-capable tool with no annotations and no output schema, the description covers operations, target selection, safety workflow, and delete semantics well. What is missing is permission requirements and batch-failure semantics, which an agent would want before applying changes.

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 already 90%, so the baseline would be 3. The description adds genuine mapping value by tying `template` to set_template and `parent_to`/`context_to` to move, and by framing ids versus filters as alternative selection strategies rather than merely listing them.

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 ("Apply ONE operation to many resources at once") and enumerates the five valid operations with the extra parameter each requires. This clearly separates it from single-resource siblings like modx_duplicate_resource or modx_list_resources.

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?

Explicitly prescribes the workflow: 'ALWAYS run dry_run:true FIRST' and explains the two mutually exclusive targeting modes (explicit ids vs. parent/context/query filter). It stops short of naming a sibling alternative for restoring deleted resources, but the when-to-use context is clear.

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