Skip to main content
Glama
Sign In
MODX MCP

MODX MCP

by rumata-estor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

modx_make_static

Converts MODX chunks, snippets, templates, or plugins to static files under core/elements/, sets static=1 with Filesystem source, and supports single or batch conversion for direct editing.

Instructions

Convert a chunk/snippet/template/plugin to a static file under core/elements/ (writes the file, sets static=1 + source=Filesystem). One element via {type,id}, or a batch via {items:[{type,id}]}. Edit the resulting files directly afterwards. (See also the modxmcp.auto_static setting to do this automatically on every create/update.)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "modx_make_static"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNo
typeNo
itemsNoBatch: list of {type,id} to convert.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.4

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does well: it reveals the side effects explicitly (writes a file, mutates static=1 and source=Filesystem) and the workflow consequence that future editing should happen in the files rather than via the element tools. It omits overwrite semantics, permission requirements, and whether the conversion is reversible.

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 compact sentences, front-loaded with the action and result, followed by input modes, post-conversion workflow, and the automation alternative. Parentheticals are used efficiently and no sentence is redundant.

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 three-parameter mutation tool with no annotations and no output schema, the description covers what changes, where files land, how to pass inputs, and what to do afterward. Missing pieces are failure/overwrite behavior and return information, which are moderate rather than critical gaps.

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 only 33% (only items is documented), so the description must compensate, and it does by explaining the two mutually exclusive input modes: a single {type,id} pair versus a batch {items:[{type,id}]}. That clarifies how id and type relate, which the bare schema does not. It does not state that both modes are optional/which is required when, leaving a small ambiguity given required=0.

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?

The description names a specific verb (convert), specific resources (chunk/snippet/template/plugin), and the concrete outcome (a static file under core/elements/ with static=1 and source=Filesystem). No sibling tool performs this operation, so an agent can distinguish it immediately from modx_update_element or modx_edit_element_lines.

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?

It establishes the usage context clearly: use this to move an element's source of truth onto the filesystem, and afterward edit the files directly. It also names the automatic alternative (the modxmcp.auto_static setting applying on every create/update), which is genuine routing guidance. It stops short of stating preconditions such as filesystem write permissions or what happens when a static file already exists.

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