Skip to main content
Glama
Sign In
MODX MCP

MODX MCP

by rumata-estor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

modx_describe_object

Inspect an xPDO class’s fields, PHP/DB types, null/default values, and primary key to get real field names before creating or updating unfamiliar MODX objects.

Instructions

Schema introspection: list an xPDO class's fields (name + php/db type, null, default) and its primary key, so you use REAL field names instead of guessing. Accepts a class name (e.g. modResource) or an alias (resource/chunk/snippet/template/plugin/tv/category/user/context/setting). Use before create/update on an unfamiliar object.

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": {
      "class": "<class>"
    },
    "name": "modx_describe_object"
  }
}

Input Schema

NameRequiredDescriptionDefault
classYesxPDO class or alias, e.g. 'modResource' or 'resource'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.4

TDQS

A4.2/5.0
Behavior4/5

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

No annotations, so the description carries the full burden, and it does disclose the operation's read-only nature ('Schema introspection') plus the exact return fields including primary key. It omits error behavior for an unknown class name and any permission requirements, which is the remaining 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?

Three sentences, front-loaded with the verb and purpose, then accepted input forms, then the usage trigger. Dense with no filler or restatement of the tool name.

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?

Simple one-parameter tool with no output schema, and the description compensates by enumerating the return fields and primary key, so the agent knows what it gets back. Only minor omissions: behavior on an invalid class name and whether aliases cover custom classes.

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 coverage is 100% and the schema already documents 'xPDO class or alias, e.g. modResource or resource'. The description's added value is the enumerable alias list (resource/chunk/snippet/template/plugin/tv/category/user/context/setting), which is genuinely not in the schema since there are no enums. That's real but narrow added meaning.

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?

Specific verb+resource: 'list an xPDO class's fields ... and its primary key'. It also states the payload shape (name + php/db type, null, default) and explains the motivating purpose ('use REAL field names instead of guessing'). No sibling tool does schema introspection, so differentiation is implicit but evident.

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?

Explicit when-to-use: 'Use before create/update on an unfamiliar object' — a clear trigger condition that routes the agent. It gives no when-not guidance or named alternatives, but no sibling competes for this job, and the accepted alias list lowers selection risk.

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