Skip to main content
Glama

MODX MCP

English · Русский · Español · Deutsch · Français · Українська · Қазақша · Nederlands · Polski

Documentation in 9 languages / Документация на 9 языках

MODX MCP is an MCP server (Model Context Protocol) and component line for MODX Revolution 2.8.x and 3.x. It lets AI agents work through MODX objects, processors, permissions and relations instead of treating a site as only a database and a set of files.

MODX MCP does not try to give AI the widest possible access to a website. It tries to give AI the right access to MODX.

The project is based on the original modxMCP, created by dampilov94. The current codebase grew out of the MODX 3 port and now uses one shared modular runtime with platform adapters for MODX 2 and MODX 3.

MODX MCP 1.2.5 · MODX Revolution 2.8.x / 3.x · 199 server actions (198 public MCP tools) · MIT

The repository name modx3-mcp, Node package name, and existing technical identifiers are retained for backward compatibility. The product name shown in documentation and the MODX manager is now MODX MCP.

MODX MCP interface

Manager UI languages: Russian, English, Spanish, German, French, Ukrainian, Kazakh (Cyrillic), Dutch and Polish (ru, en, es, de, fr, uk, kk, nl, pl).

Use the manager dashboard to review the API endpoint, manage token access, configure settings, and control available MCP capabilities. The separate dependency graph shows relationships between MODX elements, broken references, and potentially unused code.

Manager dashboard

MODX MCP manager dashboard in English

Dependency graph

MODX MCP dependency graph with English labels

Documentation illustrations rendered from the component UI and test-site graph data. The API hostname is an example and the token is fully masked. The graph screenshot uses English-localized labels for documentation; the graph uses localized strings from the selected manager language. Images are not evidence of a specific MCP client being connected.

Related MCP server: GIMS Automation MCP Server

Documentation

Additional references: development, build architecture, validation status.

The idea

Giving an AI agent normal server access means it can edit files, run SQL queries, and execute commands. For MODX, that is not enough. A large part of a MODX site lives in resources, templates, chunks, snippets, TVs, system settings, relations between objects, and data managed by installed extras.

MODX MCP gives the agent a dedicated management layer that works with these things as MODX objects. The agent can:

  • find resources, templates, chunks, snippets, plugins, and TVs;

  • Manage MODX element categories: create, rename, nest, move, safely delete, and assign to chunks, snippets, templates, TVs and plugins.

  • inspect dependencies and where elements are used;

  • create, update, and delete MODX objects through controlled operations;

  • work with system settings, media sources, and supported extras;

  • preview potentially dangerous operations before applying them;

  • create safety backups before changes;

  • keep read operations separate from write operations;

  • send information about completed changes to an external audit log.

The main goal is to make AI work with MODX more predictable, reviewable, and reversible.

Who is it for?

MODX MCP is mainly useful for:

  • MODX developers and integrators who use AI agents in daily work;

  • agencies and teams that maintain several MODX projects;

  • owners of complex MODX sites who want controlled AI access to the CMS;

  • developers of their own agent systems who need more than generic file, SSH, or database access.

Why MODX MCP is designed this way

MODX MCP was not built as a demo showing that an LLM can be connected to a CMS. It was built as a practical tool for working with real websites.

The main risk with an AI agent is not whether it can change a file or a record. The real question is whether it understands the consequences. On a live MODX site, elements rarely exist in isolation. One shared chunk may be used by dozens of resources and templates, a TV may be part of the logic of several sections, and a system setting may affect an entire component.

That is why MODX MCP focuses not only on executing commands, but also on context: dependencies, previews, backups, limits for dangerous operations, and auditing.

The goal is not to make the agent all-powerful. The goal is to give it enough context and enough limits so it is less likely to make dangerous decisions blindly.

Compatible MCP clients

The Node.js part of MODX MCP uses the standard stdio transport and works with MCP hosts that can start a local MCP server. No separate agent orchestration service is required. See Installation and setup.

Common AI mistakes when working with a CMS

Common problem

What can happen

What MODX MCP does

Changing an element without checking where it is used

A shared chunk, snippet, or TV affects several parts of the site

Lets the agent inspect dependencies and usage

Editing the database directly

MODX logic may be bypassed, relations may break, or cache state may become incorrect

Provides dedicated operations for MODX objects

Deleting an "unused" object without checking

A hidden dependency is discovered only after part of the site breaks

Helps inspect relations and possible impact before deletion

Overwriting settings during an update

API tokens or site-specific values are lost

Preserves existing settings during reinstall and upgrade

Several changes running at the same time

One process may overwrite the result of another

Uses locking for write operations

Failure during a component upgrade

The component may be left only partly updated

Prepares the new file tree separately and restores the previous one on failure

Giving the agent too much access

A mistake affects more objects than necessary

Lets you disable and restrict capability groups

No action history

It becomes difficult to understand what the agent actually changed

Supports an external operation log and audit data

How this approach is different

MODX MCP does not replace SSH, SQL, or file access. It solves a different problem: it gives AI an interface where MODX objects still keep their meaning.

Approach

What the agent gets

Main limitation

SSH and shell access

Broad access to the server and system commands

Wide permissions, but little understanding of CMS structure

Direct SQL access

Read and write access to database tables

Bypasses application logic and gives little context about object relations

Generic file MCP

Access to source code and the file system

A large part of MODX structure is not stored in files

Generic database MCP

Access to tables and queries

Tables do not explain MODX object semantics to the agent

MODX MCP

Dedicated operations for MODX entities and their relations

The agent is limited to capabilities explicitly implemented and allowed by the server

MODX MCP deliberately does not give AI arbitrary access to the whole server. Instead, it gives the agent a narrower but more meaningful interface: a resource stays a resource, a chunk stays a chunk, a TV stays a TV, and dependencies between them can be inspected before a change is made.

Example task

For example, you can ask an agent:

"Increase the price of products in a specific category by 100. First find where the price is stored, check which objects will be affected, and only then make the changes."

Instead of editing database tables directly, the agent can use MODX MCP to inspect the project structure, identify the right entities, review related objects, perform the change through available operations, and record the result.

Features

The server side of MODX MCP exposes more than 180 operations, which the client presents as specialised MCP tools.

It supports:

  • resources and the site tree;

  • templates, chunks, and snippets;

  • plugins and events;

  • TVs and TV values;

  • categories and system settings;

  • namespaces;

  • media sources and files;

  • user groups and access control;

  • property sets and contexts;

  • packages, extras, and lexicons;

  • MIGX, miniShop2, VersionX, and VirtualPage.

Individual capability groups can be disabled in the component settings.

Dependency analysis

One of the key features of MODX MCP is a dependency graph for site elements.

MODX MCP dependency graph

MODX MCP dependency graph in the MODX manager: relations between templates, chunks, snippets, TVs, and plugins, plus detected broken references and unused elements.

The agent can find:

  • which chunks and snippets are used by a template;

  • which TVs are assigned to templates;

  • which elements call other elements;

  • where a specific element is used;

  • references to elements that do not exist;

  • elements that are likely no longer used;

  • which parts of the site may be affected by a change.

The graph is available through MCP and also as a dedicated screen in the MODX manager. This is especially useful on larger projects, where changing one element may affect several different sections of the site.

Safety mechanisms

MODX MCP is designed not only for reading data, but also for real work on live websites. Depending on the operation, it supports:

  • automatic safety backups before changes;

  • previewing changes without applying them;

  • extra confirmation for destructive operations;

  • locking of parallel write operations;

  • restricting available capability groups;

  • separate permission for running arbitrary MODX processors;

  • HTTPS required for the API by default;

  • safe API-token comparison;

  • automatic selection of an active MODX user with sudo permission;

  • preservation of existing settings and API token during component upgrades.

Limits and trust model

MODX MCP does not make AI error-free. An LLM can still misunderstand a task, select the wrong object, or suggest an unwanted change.

The component reduces technical risk and gives the agent more context, but it does not replace proper backups, access control, or human review of critical changes. Extra care is recommended for bulk operations, access-control changes, system settings, custom PHP code, and operations provided by third-party extras.

On a production site, it is best to allow only the capability groups that are actually needed.

External audit hook

For integration with your own audit system, the client supports the MODX_MCP_AUDIT_HOOK environment variable.

After a successful write operation, the client can start a configured local program and send JSON to its standard input. The payload includes the MCP tool name, arguments, result, site identifier, actor information, and paths to automatically created safety backups.

The program is started directly, without a shell. If the audit hook is not configured, normal MODX MCP behaviour does not change. If the hook itself fails, an already successful site change is not reported as failed. Read-only operations do not trigger the hook.

Patch 1.2.3 (MODX 2 and MODX 3)

Package-manager installation screens now resolve documentation links on GitHub instead of relative to the MODX manager URL. README/CHANGELOG links and images are rewritten only when embedding transport metadata; the source Markdown is unchanged. The public MCP contract remains 193 server actions / 192 public tools, and normal upgrades preserve the existing API token and settings.

Patch 1.2.2 (MODX 2 and MODX 3)

Historical note about the previous v1.2.2 release.

The v1.2.2 source and its two platform packages introduced 193 server actions (192 public MCP tools), including CAS-safe TV writes and modx_update_element_property. The manager dashboard and dependency graph were redesigned with responsive layouts, larger controls, safe token reveal/copy and in-panel scrolling. MODX 2 has separate compatible manager/processor overlays. Upgrading preserves the existing modxmcp.api_token; you do not need to reconfigure clients unless you deliberately regenerate the token.

See the changelog, installation and validation history for release-specific details.

Compatibility

The shared-source platform line, introduced before v1.2.3, supports both MODX generations:

  • MODX Revolution 2.8.x — platform artifact modx2;

  • MODX Revolution 3.x — platform artifact modx3;

  • Node.js 18 or newer for the local MCP server.

The two MODX generations use the same MCP client, the same public action contract and the same modular runtime. Platform-specific bootstrap, class names and processor routing are isolated behind platform adapters and release overlays.

Version 1.2.1 status:

  • all 192/192 server actions are implemented by the modular runtime; v1.2.0 added 10 actions compared with v1.1.0: get_site_state, ClientConfig CRUD/read operations, and additional access-policy/resource-group read helpers;

  • the 192-action source contract passes the static architecture, client/server, migration, portability and release-staging checks;

  • the published v1.1.0 release was live-validated with the previous 182-action contract on MODX 3.2.4-pl and MODX 2.8.9-pl;

  • MODX 3 processor compatibility for the stable line was checked against 3.2.2-pl, 3.2.4-pl and the then-current 3.x branch;

  • v1.2.1 is the security patch release. Both platform transport packages passed installation, reinstallation, uninstall/reinstall and endpoint smoke on their MODX 2.8.9-pl and MODX 3.2.4-pl test sites. The full 14-suite MODX 3 regression and 81-action read parity were completed for v1.2.0; they are not claimed as newly rerun for 1.2.1.

See build architecture and validation status for the exact matrix.

Quick start

A minimal working setup is:

  1. Install the MODX MCP transport package.

  2. Get the automatically generated API token.

  3. Configure your MCP client to start MODX MCP.

  4. Begin with a safe read-only task, for example: "Show me the project structure and the dependencies of template X."

After that, you can move to more complex workflows and enable only the capability groups you actually need.

Install with the MODX transport package

Version-specific MODX Extras documentation: MODX 2.8.x — MODX2MCP 1.2.5 · MODX 3.x — MODX MCP 1.2.5. Russian translations: MODX 2 · MODX 3. These documents provide the platform-specific installation and release notes for the existing Extras catalog listings.

Version 1.2.5 is prepared for two platform-specific transport packages, not yet published:

  • MODX 2.8.x: modx2mcp-1.2.5-pl.transport.zip;

  • MODX 3.x: modx3mcp-1.2.5-pl.transport.zip.

Install only the package that matches the MODX major version. Both packages install the same modxmcp namespace, settings, MCP endpoint and modular action surface.

MODX 2 users upgrading from the previous modxmcp package should perform a clean reinstall. Because the MODX 2 distribution was substantially reworked and now has its own package identity, first fully uninstall the old modxmcp package in Package Manager, then install the matching transport ZIP after it is published. Do not keep both package records installed side by side. A full uninstall removes the old modxmcp.* settings and API token, so verify the new settings after installation and update the MCP client token if necessary.

For subsequent reinstalls or upgrades of the new modx2mcp package itself, existing modxmcp.* settings and the API token are preserved.

Version 1.2.5 adds MODX element-category lifecycle management for MODX 2 and 3.

Command-line installation

The source repository defaults to the MODX 3 build. For an explicit platform build, first create a clean release tree.

MODX 3:

python3 _build/prepare-release.py --platform modx3 --output /tmp/modxmcp-modx3
cd /tmp/modxmcp-modx3
MODX_CONFIG_CORE=/full/path/to/config.core.php php _build/install.headless.php

MODX 2:

python3 _build/prepare-release.py --platform modx2 --output /tmp/modxmcp-modx2
cd /tmp/modxmcp-modx2
MODX_CONFIG_CORE=/full/path/to/config.core.php php _build/install.headless.php

The prepared tree contains only the selected platform fallback/bootstrap and no source-only legacy/platform templates.

The installer creates the required settings and manager entries and generates an API token when needed. New files are staged before live directories are replaced; existing settings and tokens are preserved on upgrade.

Configure an MCP client

For production use, pin the last published transport-compatible tag (1.2.4) until 1.2.5 packages are available:

{
  "mcpServers": {
    "modx": {
      "command": "npx",
      "args": [
        "-y",
        "github:rumata-estor/modx3-mcp#v1.2.4"
      ],
      "env": {
        "MODX_MCP_SITE_URL": "https://example.com/assets/components/modxmcp/api.php",
        "MODX_MCP_TOKEN": "your-token"
      }
    }
  }
}

The Node.js client is the same for MODX 2 and MODX 3; only the server-side transport package differs.

For development or pre-release testing, use:

github:rumata-estor/modx3-mcp#main

For production sites, pin a published release tag.

Release checks

Before a release, the project checks:

  • PHP syntax and Node.js client syntax;

  • version consistency across the shared source and both platform build configs;

  • the complete client/server contract: 199 actions;

  • modular migration coverage: 83/83 reads + 116/116 mutations;

  • MODX 2 platform staging and PHP compatibility;

  • MODX 3 processor compatibility across 3.2.2-pl, 3.2.4-pl and current 3.x;

  • installation portability, secure defaults and platform-specific transport requirements;

  • install/reinstall/uninstall smoke cycles on a separate site of the matching MODX major version.

Prepare a platform tree before running a full release smoke for that platform. Never run the destructive release cycle on a production site.

Project origin

MODX MCP is based on the open-source modxMCP project, created by dampilov94.

The original work and attribution are preserved in the project history and license. MODX MCP develops that base into a shared MODX 2/3 platform for practical AI-agent work, with dependency analysis, controlled write operations, backups, auditing and platform-specific adapters.

License and release

The project is distributed under the MIT License. See LICENSE.

Current source version: 1.2.5 (transport build pending).

Latest published stable release with transport ZIPs: 1.2.4.

The 1.2.5 release targets separate MODX 2 and MODX 3 transport packages and keeps normal upgrade settings/token intact.


MODX MCP can be installed and configured independently using the documentation. In real projects, integration often needs additional work around access permissions, safe workflows, backups, auditing, third-party extras, and the structure of a particular site. This usually requires separate engineering work for the specific project.

Available Tools

192 tools
modx_add_user_to_groupC

Add a user to a user group, optionally with a role.

Inputs: user (required), usergroup (required), role.

modx_assign_property_setB

Attach a property set to an element. Identify the element with its id + either element_class (e.g. 'modSnippet') or element_type ('snippet'/'chunk'/'template'/'plugin'/'tv').

Inputs: element (required), property_set (required), element_type, element_class.

modx_assign_resource_to_groupB

Add a resource (document) to a resource group.

Inputs: resource (required), resourceGroup (required).

modx_bulk_resourcesA

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.

Inputs: operation (required), ids, limit, query, +6 more.

modx_check_integrationsA

Report which popular MODX add-ons (miniShop2, MIGX, pdoTools, Tickets, etc.) are installed on this site and what modxMCP can do with each. Read-only.

Inputs: no named parameters.

modx_clear_cacheA

Refresh the MODX cache. Pass partitions (e.g. ['resource','context_settings']) to refresh only those; omit for a full refresh.

Inputs: partitions.

modx_clear_tv_valuesA

Preview or clear every explicitly stored value for one TV. Safe by default: without confirm:true it only returns the number of stored values. Destructive; use only as part of the staged TV deletion workflow after backup.

Inputs: tv_id, confirm, tv_name.

modx_clientconfig_create_settingD

Create a ClientConfig setting.

Inputs: key (required), group, label, value, +9 more.

modx_clientconfig_delete_settingC

Delete a ClientConfig setting by id or key.

Inputs: id, key.

modx_clientconfig_get_settingC

Get a ClientConfig setting by id or key.

Inputs: id, key.

modx_clientconfig_list_settingsC

List ClientConfig settings including context-specific values.

Inputs: query.

modx_clientconfig_update_settingC

Update a ClientConfig setting by id or key.

Inputs: id, key, group, label, +10 more.

modx_create_access_policyC

Create an access policy.

Inputs: name (required), template (required), data, description.

modx_create_access_policy_templateC

Create an access policy template.

Inputs: name (required), description, template_group.

modx_create_contextC

Create a context. 'key' is the unique identifier (e.g. 'mobile').

Inputs: key (required), name, rank, description.

modx_create_context_settingB

Create a context-level setting (overrides the system setting for that context).

Inputs: key (required), context_key (required), area, value, +2 more.

modx_create_elementD

Create a new MODX element.

Inputs: name (required), type (required), new, size, +30 more.

modx_create_media_fileB

Create a file inside a media source (writes content). source = source id or name, path = target directory (relative to the source base), name = filename, content = file body.

Inputs: name (required), source (required), path, content.

modx_create_media_folderB

Create a folder inside a media source. source = id/name, parent = parent directory (default root), name = folder name.

Inputs: name (required), source (required), parent.

modx_create_media_sourceB

Create a media (file) source. class_key defaults to sources.modFileMediaSource. 'properties' is a {name:value} map of source params (e.g. {"basePath":"assets/files/","baseUrl":"assets/files/"}) merged into the source.

Inputs: name (required), class_key, properties, description.

modx_create_namespaceD

Create a namespace.

Inputs: name (required), path, assets_path.

modx_create_property_setC

Create a property set. 'properties' is a JSON object of property definitions.

Inputs: name (required), category, properties, description.

modx_create_providerB

Add a transport provider (e.g. modstore.pro). For paid providers pass username + api_key.

Inputs: name (required), service_url (required), api_key, username, +1 more.

modx_create_resource_groupD

Create a resource group.

Inputs: name (required).

modx_create_roleC

Create a role.

Inputs: name (required), authority.

modx_create_system_settingC

Create a MODX system setting.

Inputs: key (required), area, value, xtype, +1 more.

modx_create_userB

Create a user. Pass 'password' to set it explicitly; omit to auto-generate. Profile fields (email, fullname, phone…) are accepted alongside.

Inputs: username (required), email, active, fullname, +1 more.

modx_create_user_groupC

Create a user group.

Inputs: name (required), parent.

modx_delete_access_policyC

Delete an access policy by id.

Inputs: id (required).

modx_delete_access_policy_templateC

Delete an access policy template by id.

Inputs: id (required).

modx_delete_contextC

Delete a context by key.

Inputs: key (required).

modx_delete_context_settingC

Delete a context setting (by context_key + key).

Inputs: key (required), context_key (required).

modx_delete_elementA

Delete a MODX element. Run with dry_run:true FIRST — it returns what would be deleted plus where the element is still referenced (for resources: child-resource count), without deleting. Review that before the real delete.

Inputs: type (required), id, name, dry_run.

modx_delete_media_fileC

Delete a file inside a media source. source = id/name, path = file path within the source.

Inputs: path (required), source (required).

modx_delete_media_folderB

Delete a folder (and its contents) inside a media source. source = id/name, path = folder path within the source.

Inputs: path (required), source (required).

modx_delete_media_sourceC

Delete a media source by id.

Inputs: id (required).

modx_delete_namespaceB

Delete a namespace by name ('core' cannot be deleted).

Inputs: name (required).

modx_delete_property_setC

Delete a property set by id.

Inputs: id (required).

modx_delete_providerC

Delete a transport provider by id.

Inputs: id (required).

modx_delete_resource_groupC

Delete a resource group by id.

Inputs: id (required).

modx_delete_roleC

Delete a role by id.

Inputs: id (required).

modx_delete_system_settingC

Delete a MODX system setting by key.

Inputs: key (required).

modx_delete_userC

Delete a user by id.

Inputs: id (required).

modx_delete_user_groupC

Delete a user group by id.

Inputs: id (required).

modx_dependency_graphA

Map how the site's elements WIRE TOGETHER, in one call: which template pulls which chunk/snippet/TV, which snippet renders which chunk, where each TV is attached. Returns nodes (elements, with in/out reference degree) + edges ([from_index, to_index, kind]) — plus missing (tags pointing at a chunk/snippet that does NOT exist — broken references) and orphans (elements nothing references — safe-to-delete candidates). Detects references in MODX tags, &tpl=chunk`` properties, $modx->getChunk()/runSnippet() in PHP, MIGX inputTV/renderchunktpl, and template↔TV attachments. Token-safe: it scales with the number of ELEMENTS, never with content (resources are counts, not nodes). USE IT: to understand an unfamiliar site's code structure after modx_project_overview; with focus before editing or deleting an element, to see exactly what depends on it (cheaper and more precise than modx_find_usages, which is a text search); with format:"summary" as a fast health check for broken/dead elements.

Inputs: depth, focus, types, format, +4 more.

modx_describe_objectA

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.

Inputs: class (required).

modx_duplicate_elementC

Duplicate an element (chunk/snippet/template/plugin/tv). type + id; optional name for the copy.

Inputs: id (required), type (required), name.

modx_duplicate_resourceB

Duplicate a resource. id = source resource; optional name (new pagetitle), duplicate_children (bool), published_mode (preserve|publish|unpublish).

Inputs: id (required), name, published_mode, duplicate_children.

modx_edit_element_linesA

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.

Inputs: type (required), edits (required), id, name.

modx_empty_recycle_binA

Permanently purge ALL trashed (soft-deleted) resources. Irreversible — there is no further undo.

Inputs: no named parameters.

modx_find_usagesA

Find where an element is used: content matches for its name across all code, plus — if it is a template — the resources assigned to that template. Use before renaming/deleting an element.

Inputs: name (required), limit.

modx_flush_permissionsA

Flush cached access permissions (the manager's 'Flush Permissions') so ACL changes apply. ACL write tools already do this automatically; use this for a manual flush.

Inputs: no named parameters.

modx_get_access_policyC

Get an access policy by id.

Inputs: id (required).

modx_get_access_policy_templateC

Get an access policy template by id.

Inputs: id (required).

modx_get_component_filesC

List files and folders inside an installed MODX component.

Inputs: name (required), path, scope.

modx_get_contextC

Get a context by key.

Inputs: key (required).

modx_get_context_settingC

Get one context setting (by context_key + key).

Inputs: key (required), context_key (required).

modx_get_elementA

Read a MODX element (returns its fields + full code). For a large chunk/snippet/template/plugin you only need to edit, prefer modx_view_element (numbered, windowable) so you don't pull the whole body into context.

Inputs: type (required), id, name.

modx_get_media_sourceC

Get one MODX media source.

Inputs: id, name.

modx_get_property_setB

Get a property set by id (incl. its properties).

Inputs: id (required).

modx_get_resource_groupC

Get a resource group by id.

Inputs: id (required).

modx_get_resource_tvsC

Get a resource's template-variable (TV) values.

Inputs: resource_id (required).

modx_get_roleC

Get a role by id.

Inputs: id (required).

modx_get_site_stateB

Read the connector-authoritative site revision and atomic-precondition capability used by Site Agent Runtime.

Inputs: no named parameters.

modx_get_system_settingC

Get one MODX system setting by key.

Inputs: key (required).

modx_get_userC

Get a user by id.

Inputs: id (required).

modx_get_user_groupB

Get a single user group by id.

Inputs: id (required).

modx_grant_context_accessC

Grant a user group access to a context with a policy and minimum role authority.

Inputs: policy (required), target (required), principal (required), authority.

modx_grant_resourcegroup_accessB

Grant a user group access to a resource group with a policy and minimum role authority.

Inputs: policy (required), target (required), principal (required), authority.

modx_helpA

Built-in documentation. Call with no args to list topics; pass {topic} for a guide (e.g. 'tv_input_types', 'study_component', 'minishop2', 'migx', 'acl', 'getting_started'). Read the relevant topic before unfamiliar work, or to learn how to use a newly-installed component.

Inputs: topic.

modx_install_packageB

Install a transport package from a provider (default modx.com) by name, e.g. {package:'MIGX'}. Returns 'already_installed' if present.

Inputs: package (required), provider, target_signature.

modx_list_access_permissionsB

List permissions defined by a policy template (read-only catalogue).

Inputs: limit, query, start, template.

modx_list_access_policiesC

List access policies (id, name, description, template).

Inputs: limit, query, start.

modx_list_access_policy_templatesC

List access policy templates.

Inputs: limit, query, start.

modx_list_actionsA

List the action names this modxMCP server build supports, grouped by area. Use it to detect client/server version skew.

Inputs: no named parameters.

modx_list_context_accessB

List context-access ACL entries, optionally filtered by usergroup/context/policy.

Inputs: limit, start, policy, context, +1 more.

modx_list_contextsC

List contexts (modContext): key, name, description, rank.

Inputs: limit, query, start.

modx_list_context_settingsC

List settings of a context (modContextSetting).

Inputs: context_key (required), area, limit, start, +1 more.

modx_list_elementsC

List MODX elements of a type (id + name). Supports an optional name filter and pagination.

Inputs: type (required), limit, query, start.

modx_list_installed_componentsB

List installed MODX components from core/components and assets/components.

Inputs: no named parameters.

modx_list_lexicon_entriesC

List lexicon entries, filtered by namespace + topic + language (and optional search).

Inputs: limit, start, topic, search, +2 more.

modx_list_lexicon_topicsC

List lexicon topics for a namespace/language.

Inputs: query, language, namespace.

modx_list_media_source_filesC

List files and folders inside a media source.

Inputs: id, name, path.

modx_list_media_sourcesC

List MODX media sources.

Inputs: no named parameters.

modx_list_namespacesC

List namespaces (modNamespace): name, path, assets_path.

Inputs: limit, query, start.

modx_list_property_setsC

List property sets (modPropertySet): id, name, description, category.

Inputs: limit, query, start.

modx_list_providersA

List transport providers (modx.com and custom, e.g. modstore.pro): id, name, service_url.

Inputs: no named parameters.

modx_list_resourcegroup_accessC

List resource-group access ACL entries.

Inputs: limit, start, usergroup.

modx_list_resource_group_resourcesC

List resources assigned to a resource group.

Inputs: resourceGroup (required).

modx_list_resource_groupsC

List resource groups (id, name).

Inputs: limit, query, start.

modx_list_resourcesA

List resources (the content tree), optionally filtered by parent, context, deleted state, or a pagetitle/alias/uri query. Returns id, pagetitle, alias, uri, parent, template, published, deleted, isfolder, class_key, context_key.

Inputs: limit, query, start, parent, +2 more.

modx_list_rolesC

List access roles (id, name, authority).

Inputs: limit, query, start.

modx_list_system_settingsC

List MODX system settings.

Inputs: area, namespace.

modx_list_tv_input_typesA

List the TV input (widget) types available on this site. Core types come with use (when to pick each) and requires (extra create_element keys like elements/media_source) so you choose the right field_type for the task; plus any custom types other components register (e.g. MIGX adds 'migx'/'migxdb'). Use a key as field_type when creating a TV. See the tv_input_types help topic for full examples.

Inputs: no named parameters.

modx_list_tv_valuesA

List explicitly stored values for one TV across all resources, including stale values on resources whose current template may no longer use that TV. Use before deleting or restructuring a TV.

Inputs: limit, start, tv_id, tv_name.

modx_list_user_group_membersC

List members of a user group.

Inputs: usergroup (required), limit, start.

modx_list_user_groupsC

List MODX user groups (id, name, parent, rank).

Inputs: limit, query, start.

modx_list_usersC

List manager/web users (modUser).

Inputs: limit, query, start.

modx_make_staticA

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.)

Inputs: id, type, items.

modx_migx_create_configB

Create a MIGX configuration. formtabs/columns/contextmenus/actionbuttons/columnbuttons/filters are JSON strings (same format MIGX stores in the manager).

Inputs: name (required), columns, filters, category, +8 more.

modx_migx_delete_configC

Delete a MIGX configuration by id.

Inputs: id (required).

modx_migx_get_configA

Get a full MIGX configuration by id (formtabs, columns, buttons, filters, permissions — as stored JSON strings).

Inputs: id (required).

modx_migx_list_configsC

List MIGX configurations (migxConfig): id, name, category, published.

Inputs: limit, query, start, category.

modx_migx_update_configC

Update a MIGX configuration. Only the fields you pass are changed.

Inputs: id (required), name, columns, filters, +9 more.

modx_ms2_assign_option_to_categoryC

Assign an existing miniShop2 option to an msCategory.

Inputs: option_id (required), category_id (required).

modx_ms2_create_categoryC

Create a miniShop2 category (msCategory resource).

Inputs: parent (required), pagetitle (required), alias, published.

modx_ms2_create_optionC

Create a miniShop2 product option in settings options.

Inputs: key (required), type (required), caption (required), category, +4 more.

modx_ms2_get_optionC

Read one miniShop2 product option by id.

Inputs: id (required).

modx_ms2_get_orderC

Get a miniShop2 order by id (with items/customer).

Inputs: id (required).

modx_ms2_get_product_optionsC

Read miniShop2 option values assigned to a product.

Inputs: product_id (required).

modx_ms2_list_categoriesC

List miniShop2 categories (msCategory).

Inputs: limit, query, start, parent.

modx_ms2_list_optionsC

List miniShop2 product options from the settings options tab.

Inputs: limit, query, category, modcategory.

modx_ms2_list_option_typesB

List available miniShop2 product option field types.

Inputs: no named parameters.

modx_ms2_list_ordersB

List miniShop2 orders (msOrder), filterable by status/customer/context/date range.

Inputs: limit, query, start, status, +4 more.

modx_ms2_update_categoryC

Update a miniShop2 category.

Inputs: id (required), alias, parent, pagetitle, +1 more.

modx_ms2_update_optionC

Update a miniShop2 product option in settings options.

Inputs: id (required), key, type, caption, +5 more.

modx_ms2_update_orderB

Update a miniShop2 order — typically to change its status (triggers ms2 status-change logic), delivery or payment.

Inputs: id (required), status, payment, delivery.

modx_ms2_update_product_optionsC

Create, update, or remove miniShop2 option values for a product. Use null value to remove an option value.

Inputs: options (required), product_id (required).

modx_project_overviewA

Orient on the whole installed site in ONE compact, cheap call. Returns STRUCTURE + COUNTS (not content): template↔TV map, resource/product COUNTS (overall + by template + by context), a shallow resource tree (roots + child counts only), element categories, content types, contexts, installed integrations. Token-safe on huge sites (100k resources return the same small payload) — for per-item browsing use list_resources / list_elements. Call this FIRST when starting on an unfamiliar project. Optional sections to fetch only some parts; max_tree_nodes caps the tree roots.

Inputs: sections, max_tree_nodes.

modx_read_audit_logA

Read the modxMCP write-audit trail (newest last). Optionally filter to one action.

Inputs: limit, action.

modx_read_component_fileC

Read a file from an installed MODX component.

Inputs: name (required), path (required), scope.

modx_read_error_logA

Read the tail of the MODX error log (core/cache/logs/error.log) for diagnostics. Optional limit (lines, default 100).

Inputs: limit.

modx_read_media_source_fileC

Read a file inside a media source.

Inputs: path (required), id, name.

modx_refresh_urisA

Regenerate all resource URIs (run after bulk alias/structure changes that left stale URIs).

Inputs: no named parameters.

modx_regenerate_tokenA

Rotate the modxmcp.api_token to a fresh random value and return it. NOTE: this invalidates the current token — update MODX_MCP_TOKEN in your client config immediately, or the next call will be unauthorized.

Inputs: no named parameters.

modx_remove_locksA

Clear stale manager edit locks (when an element/resource is reported locked by a dead session).

Inputs: no named parameters.

modx_remove_resource_from_groupC

Remove a resource (document) from a resource group.

Inputs: resource (required), resourceGroup (required).

modx_remove_user_from_groupC

Remove a user from a user group.

Inputs: user (required), usergroup (required).

modx_rename_media_fileC

Rename a file inside a media source. source = id/name, path = current file path, new_name = new filename.

Inputs: path (required), source (required), new_name (required).

modx_reorder_resourcesC

Reorder resources in the tree by setting menuindex (and optionally parent). items = [{id, menuindex, parent?}], applied per resource.

Inputs: items (required).

modx_replace_acrossA

Site-wide search & replace across code elements (chunk/snippet/template/plugin): find every element whose CONTENT contains find and replace ALL occurrences with replacement, in ONE call (no per-element reads/writes from your side). Honours static files vs DB. SUBSTRING match — find:"foo" also matches inside footer/food; make find specific. ALWAYS run dry_run:true FIRST and review the returned preview (the exact lines that would change) before the real run. case_sensitive defaults to TRUE here. Use for renames / URL / class changes across the codebase. (Does not touch resources — edit those individually.)

Inputs: find (required), replacement (required), limit, types, +2 more.

modx_revert_lexicon_entryB

Revert a lexicon entry — remove its DB override so the file value applies.

Inputs: name (required), topic, language, namespace.

modx_revoke_context_accessC

Remove a context-access ACL entry by id.

Inputs: id (required).

modx_revoke_resourcegroup_accessC

Remove a resource-group access ACL entry by id.

Inputs: id (required).

modx_run_processorA

Run ANY MODX processor directly (escape hatch). Requires the modxmcp.allow_run_processor setting to be enabled. High privilege — prefer a dedicated tool when one exists.

Inputs: processor (required), properties, processors_path.

modx_search_codeA

Full-text search across element and resource CONTENT (and names). Finds the chunk/snippet/template/plugin/TV/resource that contains a string, including where an element is referenced or mentioned. Matches static elements by reading their static file. Use this to navigate the codebase (e.g. query 'header' finds the header chunk and everything that uses or mentions it). Each content hit returns id, line (1-based line of the match) and line_text (the exact line, verbatim) — so for a one-line change you can go straight to modx_edit_element_lines using line as start_line/end_line and line_text as expect, with no separate read. For multi-line context, open a window with modx_view_element around line.

Inputs: query (required), limit, types, case_sensitive.

modx_search_packagesA

Search a provider's catalogue (use before install_package). Defaults to modx.com.

Inputs: limit, query, start, provider.

modx_set_lexicon_entryC

Create or override a lexicon entry (DB override of the file value).

Inputs: name (required), topic (required), namespace (required), value, +1 more.

modx_suggest_tv_typeA

Unsure which TV input type fits a need? Describe it (English or Russian) and get ranked candidate field_types with reasons + a ready-to-edit create_element skeleton for the top pick (with the extra keys that type needs). Deterministic helper for picking the right TV type; then create it with modx_create_element. See also the tv_input_types help topic.

Inputs: description (required).

modx_system_infoA

Environment/diagnostic info: MODX version, modxMCP version, PHP version, db type, key paths.

Inputs: no named parameters.

modx_unassign_property_setC

Detach a property set from an element (same identification as assign).

Inputs: element (required), property_set (required), element_type, element_class.

modx_undelete_resourceA

Restore a soft-deleted resource from the trash (un-deletes it). id = resource id.

Inputs: id (required).

modx_uninstall_packageC

Uninstall a transport package by signature (e.g. 'migx-2.13.0-pl').

Inputs: signature (required).

modx_update_access_policyC

Update an access policy (e.g. its permissions map).

Inputs: id (required), name, description, permissions.

modx_update_access_policy_templateD

Update an access policy template.

Inputs: id (required), name, description.

modx_update_contextC

Update a context (name/description/rank). 'settings' may be a JSON array of context settings (advanced).

Inputs: key (required), name, rank, settings, +1 more.

modx_update_context_accessC

Update a context-access ACL entry by id.

Inputs: id (required), policy, target, authority, +1 more.

modx_update_context_settingC

Update a context setting (by context_key + key).

Inputs: key (required), context_key (required), area, value, +2 more.

modx_update_elementA

Update a MODX element by REPLACING its whole content (send the complete new content). Best for small elements or full rewrites. For a few changes inside a large chunk/snippet/template/plugin, do NOT use this — use modx_view_element + modx_edit_element_lines instead (sends only the changed lines, far fewer tokens, atomic with a safety anchor).

Inputs: type (required), id, new, name, +31 more.

modx_update_element_propertyB

Change ONLY the value of one EXISTING default property of a snippet, chunk, plugin or template. Requires expected_value (compare-and-swap); preserves other property definitions and source code, uses standard MODX update processor.

Inputs: type (required), value (required), property_name (required), expected_value (required), +3 more.

modx_update_group_memberC

Update a user's membership in a group (e.g. change role).

Inputs: user (required), usergroup (required), role.

modx_update_media_fileB

Overwrite a file's content inside a media source. source = id/name, path = file path within the source, content = new body.

Inputs: path (required), source (required), content (required).

modx_update_media_sourceB

Update a media source. 'properties' is a {name:value} map merged into the source's params (others preserved) — use it to set basePath/baseUrl/etc.

Inputs: id (required), name, properties, description.

modx_update_namespaceC

Update a namespace (by name).

Inputs: name (required), path, assets_path.

modx_update_property_setD

Update a property set.

Inputs: id (required), name, category, properties, +1 more.

modx_update_providerC

Update a transport provider.

Inputs: id (required), name, api_key, username, +2 more.

modx_update_resource_groupC

Update a resource group.

Inputs: id (required), name.

modx_update_resourcegroup_accessC

Update a resource-group access ACL entry by id.

Inputs: id (required), policy, target, authority, +1 more.

modx_update_resource_tvsC

Update a resource's template-variable (TV) values.

Inputs: tvs (required), resource_id (required), _runtime_preconditions.

modx_update_roleD

Update a role.

Inputs: id (required), name, authority.

modx_update_system_settingC

Update a MODX system setting by key.

Inputs: key (required), area, value, xtype, +1 more.

modx_update_userC

Update a user (profile fields, active state).

Inputs: id (required), email, active, fullname.

modx_update_user_groupD

Update a user group.

Inputs: id (required), name, parent.

modx_versionx_get_versionC

Read one VersionX version payload before deciding whether to revert to it.

Inputs: type (required), content_id (required), version_id (required).

modx_versionx_list_versionsB

List VersionX versions for a MODX resource, chunk, snippet, template, plugin, or TV.

Inputs: type (required), content_id (required), limit.

modx_versionx_revert_versionA

Revert a MODX object to a specific VersionX version. This changes live MODX data and requires confirm=true.

Inputs: type (required), confirm (required), content_id (required), version_id (required).

modx_view_elementA

View a chunk/snippet/template/plugin as NUMBERED lines (like cat -n), optionally windowed by start_line/end_line. Use this to find the exact line numbers to edit with modx_edit_element_lines — cheaper than pulling the whole element. Returns total_lines and the numbered window.

Inputs: type (required), id, name, end_line, +1 more.

modx_virtualpage_clear_cacheB

Clear VirtualPage route/cache files and refresh MODX cache.

Inputs: no named parameters.

modx_virtualpage_create_eventC

Create a VirtualPage event, usually OnPageNotFound or OnHandleRequest.

Inputs: name (required), rank, active, description.

modx_virtualpage_create_handlerC

Create a VirtualPage handler. type can be resource, snippet, chunk, dynamic_resource/template, or 0..3.

Inputs: name (required), rank, type, cache, +4 more.

modx_virtualpage_create_routeC

Create a VirtualPage route and bind its event plugin if needed.

Inputs: route (required), method (required), rank, event, +6 more.

modx_virtualpage_delete_eventB

Delete a VirtualPage event by id or name (removes its routes too, per the VP schema).

Inputs: id, name.

modx_virtualpage_delete_handlerC

Delete a VirtualPage handler by id or name.

Inputs: id, name.

modx_virtualpage_delete_routeC

Delete a VirtualPage route by id or name.

Inputs: id, name.

modx_virtualpage_get_eventB

Read one VirtualPage event by id or name, including its routes.

Inputs: id, name.

modx_virtualpage_get_handlerB

Read one VirtualPage handler by id or name, including routes that use it.

Inputs: id, name.

modx_virtualpage_get_routeA

Read one VirtualPage route by id, or by route plus optional method.

Inputs: id, route, method.

modx_virtualpage_list_eventsC

List VirtualPage events that bind route groups to MODX events.

Inputs: id, name, limit, start, +2 more.

modx_virtualpage_list_handlersC

List VirtualPage handlers that render resources, snippets, chunks, or dynamic resources.

Inputs: id, name, type, entry, +4 more.

modx_virtualpage_list_routesC

List VirtualPage routes with their event and handler names.

Inputs: id, event, limit, route, +6 more.

modx_virtualpage_resolve_routeC

Simulate VirtualPage route matching and return handler plus vp.* placeholders.

Inputs: uri, path, method.

modx_virtualpage_update_eventC

Update a VirtualPage event by id or name.

Inputs: id, name, rank, active, +1 more.

modx_virtualpage_update_handlerC

Update a VirtualPage handler by id or name.

Inputs: id, name, rank, type, +5 more.

modx_virtualpage_update_routeC

Update a VirtualPage route by id.

Inputs: id (required), rank, event, route, +7 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    C2.4/5.0

    Scored across 192 tools

    Disambiguation3/5

    Most tools are distinct and namespaced by domain, but several clusters overlap: get_element vs view_element, update_element vs edit_element_lines, search_code vs find_usages vs dependency_graph, and run_processor as a broad escape hatch. With 192 tools, an agent can still misselect among similar read/edit/search tools, though the detailed descriptions mitigate this.

    Naming Consistency4/5

    Names consistently use the modx_ prefix and snake_case, with clear domain prefixes such as ms2, virtualpage, migx, clientconfig, and versionx. A few names like project_overview, system_info, dependency_graph, and make_static deviate from strict verb_noun form but remain readable and predictable.

    Tool Count1/5

    192 tools is far beyond a well-scoped MCP surface; even with domain grouping, the set imposes high selection and context costs. It may mirror a full CMS admin API, but as a coherent toolset it is extremely oversized.

    Completeness3/5

    Coverage is broad across elements, settings, media, ACL, packages, and add-ons, but core resource lifecycle is notably incomplete: list/bulk/duplicate/undelete exist, yet there is no direct get/create/update resource content tool. Agents must fall back to the high-privilege run_processor for common page edits.

    Maintenance

    ActivityActive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      MCP server for WordPress content management that provides a secure interface for AI assistants to interact with WordPress sites, enabling content creation, editing, and media management without destructive operations.
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      MCP server for WordPress content management via REST API, supporting posts, pages, media, comments, and terms through natural language interfaces like Cursor, ChatGPT, Codex, and Claude.
      14 npm
      MIT