MODX MCP
Provides a dedicated management layer for MODX Revolution sites, enabling AI agents to inspect and manage MODX objects such as resources, templates, chunks, snippets, plugins, TVs, categories, system settings, media sources, contexts, user groups, packages, and supported extras. It also supports dependency analysis, previews of dangerous operations, safety backups, write-operation locking, and audit logging.
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

Dependency graph

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
Purpose | English | Русский |
Install and connect | ||
Explore all features | ||
Build integrations | ||
Deploy safely | ||
System settings |
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 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
sudopermission;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:
Install the MODX MCP transport package.
Get the automatically generated API token.
Configure your MCP client to start MODX MCP.
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.phpMODX 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.phpThe 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#mainFor 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 toolsmodx_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_link_typeB
Create a miniShop2 link type. 'type' is the relation kind that decides how products get linked.
Inputs: name (required), type (required), description.
modx_ms2_create_optionC
Create a miniShop2 product option in settings options.
Inputs: key (required), type (required), caption (required), category, +4 more.
modx_ms2_create_product_linkB
Link two products under a link type. The link type's relation kind decides whether the reverse link is also created.
Inputs: link (required), slave (required), master (required).
modx_ms2_delete_link_typeC
Delete a miniShop2 link type by id.
Inputs: id (required).
modx_ms2_delete_product_linkC
Remove a product link (by link type + master + slave).
Inputs: link (required), slave (required), master (required).
modx_ms2_get_link_typeC
Get a miniShop2 link type by id.
Inputs: id (required).
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_link_typesC
List miniShop2 link types (msLink): id, type, name, description.
Inputs: limit, query, start.
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_list_product_linksB
List product-to-product links (msProductLink), optionally for one product. Returns link type + master/slave with pagetitles.
Inputs: limit, query, start, master.
modx_ms2_update_categoryC
Update a miniShop2 category.
Inputs: id (required), alias, parent, pagetitle, +1 more.
modx_ms2_update_link_typeD
Update a miniShop2 link type.
Inputs: id (required), name, type, description.
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
Scored across 192 tools
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.
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.
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.
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
Related MCP Connectors
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
MCP gateway and cloud hosting for MCP servers, agents and apps like RAG, managed from your agent.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP 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
- AlicenseBqualityDmaintenanceMCP server for integrating coding agents (Claude Code CLI, etc.) with the GIMS Automation system. Enables development of automation scripts, data source types, activator types, and Git synchronization.61MIT
- AlicenseNot gradedqualityCmaintenanceMCP 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 npmMIT
- AlicenseNot gradedqualityDmaintenanceA modular, security-focused MCP server that exposes enterprise-ready tools for filesystem, database, REST API, system utilities, and AI generation, with authentication, authorization, and audit logging.MIT