Skip to main content
Glama
Sign In
MODX MCP

MODX MCP

by rumata-estor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

modx_edit_element_lines

Edit MODX chunks, snippets, templates, and plugins by line, sending only changed ranges. Use expect anchors and atomic multi-edit calls to avoid resending whole elements.

Instructions

Edit a chunk/snippet/template/plugin BY LINE, sending only the changed lines (no need to resend the whole element). Each edit replaces the inclusive range [start_line..end_line] with replacement. Conventions: delete = replacement ""; insert before a line = set end_line to start_line-1. Strongly recommended: pass expect (the current text of those lines) as a safety anchor — it is verified, and relocated to its unique match if the line numbers drifted; any mismatch aborts the WHOLE call (atomic, nothing is written). MULTI-EDIT RULES: all line numbers refer to the file exactly as you last saw it in modx_view_element (the original) — do NOT adjust them for the effect of your other edits; the server applies edits together (bottom-up) so earlier inserts/deletes never shift later ones. Ranges must not overlap. So to change several spots in one big file, send them all in ONE call with original line numbers. Read first with modx_view_element to get line numbers.

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": {
      "type": "<type>",
      "edits": "<edits>"
    },
    "name": "modx_edit_element_lines"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNo
nameNo
typeYes
editsYesList of line edits applied atomically.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.4

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so well: it declares atomicity ('any mismatch aborts the WHOLE call, nothing is written'), bottom-up application order, the non-overlap constraint, and the non-obvious behavior that `expect` is relocated to its unique match when line numbers drift.

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 purpose and conventions, then labeled MULTI-EDIT RULES, which makes it scannable despite being long. There is mild redundancy ('no need to resend the whole element' and the repeated emphasis on original line numbers) and some heavy capitalization, but nothing is filler.

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 mutation tool with no annotations and no output schema, the description covers the risky parts an agent must know: atomicity, line-number drift handling, ordering, and the read-first workflow. It omits what is returned after a successful edit and whether the element must be unlocked or permissioned, which is a modest but real gap.

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?

Adds substantial meaning beyond the schema for the core parameters: the inclusive range semantics, the insert convention (end_line = start_line-1), delete via empty replacement, and the multi-edit rule that all line numbers refer to the pre-edit original. It leaves the top-level `id` vs `name` selectors unexplained, which is the remaining gap for a 25%-coverage schema.

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 and resource ('edit a chunk/snippet/template/plugin BY LINE') and immediately names the distinguishing mechanism: only changed lines are sent, no need to resend the whole element. This lets an agent distinguish it from the sibling modx_update_element even though that sibling is never named.

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?

Gives concrete operating context: read first with modx_view_element to obtain line numbers, and for multi-spot changes, batch everything into ONE call rather than issuing sequential edits. It does not explicitly say when to prefer modx_update_element's whole-element replacement instead, so the alternative is only implied.

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