Skip to main content
Glama
Sign In
MODX MCP

MODX MCP

by rumata-estor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

modx_clientconfig_create_setting

Create a MODX ClientConfig setting with a key, label, value, group, and type to configure context-specific client settings.

Instructions

Create a ClientConfig setting.

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": {
      "key": "<key>"
    },
    "name": "modx_clientconfig_create_setting"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyYes
groupNo
labelNo
valueNo
xtypeNo
sourceNo
defaultNo
optionsNo
sortorderNo
descriptionNo
is_requiredNo
context_valuesNo
process_optionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.4

TDQS

D1.5/5.0
Behavior1/5

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

No annotations are supplied, so the description carries the full behavioral burden and delivers none of it: nothing about required permissions, key uniqueness, whether an existing key is overwritten, or what happens to the nested context_values payload. For a write operation with zero annotation coverage this is a serious gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single short sentence with no wasted words, but that brevity comes from under-specification rather than economy. There is no structure to front-load because there is only one content-free clause.

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

Completeness1/5

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

Given 13 parameters, a nested object, no annotations, and no output schema, the description is completely inadequate. An agent cannot construct a correct call or predict the result from this text alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 13 parameters with 0% description coverage, including a nested object (context_values), and the description explains none of them. An agent gets no meaning for group, source, xtype, options, process_options, or the default/value distinction beyond the bare property names.

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

Purpose2/5

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

"Create a ClientConfig setting" only restates the tool name (modx_clientconfig_create_setting) in prose. It does distinguish create from the update/delete/list siblings by the verb, but adds no scope, target, or effect information beyond the identifier itself.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The sibling list contains several plausible confusions (modx_create_system_setting, modx_create_context_setting, modx_clientconfig_update_setting) and the description gives no basis for choosing among them.

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