1.1.0

Answers a full external audit of the tool surface against 1.0.2 — thank you @AmaZili, who filed issues #1 through #4 with reproductions cross-checked against the database rather than taken from tool responses, and sent two pull requests. That report found real data loss. This release closes all five issues and both PRs, plus one bug that fixing #3 uncovered.

Requires PHP 8.2

Not a new requirement so much as an honest one. The support traits declare constants, which PHP only permits in a trait from 8.2, and two of them have done so since 1.0.0 — so on PHP 8.1 those files fatal at include time and take modxmcp_search and the three generic object tools with them, while the package advertised >=8.1. If you are on 8.1, those four tools have never worked. The installer now refuses 8.1 instead of shipping tools that cannot load.

Data loss fixed

modxmcp_element_save replaces a snippet, plugin or template's default properties wholesale, and its own description told callers to "send every option you want to keep" — while nothing in the surface could say what those options were. Adding one property destroyed the others, invisibly. modxmcp_element_get and modxmcp_element_delete now return them, along with a template variable's caption, display, option list, rank and input/output configuration, and a plugin's event bindings gathered before the processor removes them. Element removal is permanent and that echo is the recovery path; a plugin rebuilt from the old one came back bound to nothing and never ran again.

Refusals now reach the caller

A refusal raised by a tool is reported as a result carrying isError, not as a JSON-RPC protocol error. Clients are entitled to render a 4xx as a transport failure, so the most useful messages in the extra — the ones that name the problem, list the valid values and say "Nothing was written" — were the ones arriving mangled as Error POSTing to endpoint: {...}, while "the details are in the error log" travelled the reliable path.

Fixing that exposed an older bug: the audit log recorded a framed failure as a success, and an unexpected exception inside a tool had been logged as a success since the registry was written. Both fixed.

Two new tools

• modxmcp_media_source_list — the media sources a site defines, with the id file_upload expects, where each is rooted, and whether the upload allowlist covers it. Credentials are never returned. Gated on MODX's own source_view permission; remote sources are not contacted unless asked, because initialising an S3 source checks the bucket over the network.
• modxmcp_category_delete — removes a category, refusing one that still holds elements or sub-categories and naming what is in it. Stricter than MODX, which deletes it regardless, resets everything inside to uncategorised, and cascades through sub-categories without saying so.

The core is discovered

The core namespace was registered like any other, but its model map sits one level shallower than an extra's, so no glob matched it and the entire MODX core was invisible to discovery — which meant ClassGuard's hard-block list, which names almost nothing but core classes, had never once run. Fixed, along with the deeper maps beside it (media sources, transport). A hard-blocked class now says so instead of answering "Unknown class", which was wrong twice over.

Also

• tools/list is filtered by the calling token's scopes. A read-only token sees thirteen tools, all of which it can call.
• modxmcp_element_delete warns when something still calls the element it removed, naming the resources and elements with their URIs and published state.
• modxmcp_element_save warns when a template variable's input_type is one nothing can render — its own description warned that "radio is not a type", then accepted radio silently.
• Deleting a template that resources still use is refused up front, naming how many. MODX rejects it anyway; the description had claimed otherwise.
• modxmcp_cache_refresh clears modxmcp's own discovery and advisory caches. It never had, so installing an extra and then clearing caches still showed the old site.
• modxmcp_resource_duplicate echoes the template variable values the copy inherited.
• Media sources and package providers are permanently blocked from generic access: both keep credentials inside a serialised column where field-name masking cannot see them.
• Documented that modxmcp.upload_path_allowlist is relative to the media source, not to assets/.

Nothing here changes any site's data. The upgrade rewrites files only, and existing system settings, tokens, the audit log and the endpoint resource are all preserved.

Full detail in the changelog.

---

modxmcp-1.1.0-pl.transport.zip — build e4198468564e, 81 source files
sha256 31f5d926121ac196b16d1176756d5ae3d55e1037ea45bb2529dd571c5bfe54cd