MCP for Cybersalt Release Manager is a free add-on for MCP for J with a narrow audience: people who distribute their own Joomla extensions and run Cybersalt Release Manager to do it. If that's not you, there's nothing here โ it's a wrapper around one specific distribution backend, not a general release tool. If it is you, fifteen tools cover the packages you publish, the versions under each one, the customer sites registered against them, and the activity log that records every download and update check. Writes go through Release Manager's own models, so the audit entries and the on-disk file moves happen exactly as they would if you'd clicked Save yourself โ with one deliberate exception, which is the most interesting thing on this page.
Why this exists
Publishing an extension is mostly record-keeping, and record-keeping is the part that gets done badly at eleven at night. A release means a package record, a version row with the right minimum Joomla and PHP values, the latest-version flag moved, release notes written โ and every one of those steps lived in an admin form you had to open, fill in and save. None of it is hard and all of it is fiddly, which is exactly the shape of work worth handing to something that doesn't get bored. There's a pleasing circularity to it too: the add-on catalog inside MCP for J is served by Release Manager, so the same MCP connection that lists the available add-ons can now publish new ones.
What Claude can do
Fifteen tools across four record types.
| Area | Tools | What you can do |
|---|---|---|
| Packages | 5 | List, read, create, update and delete the distribution records โ one per extension you publish, carrying its element, type, visibility and state. |
| Package versions | 5 | The same five operations for each release under a package, including which one is flagged latest and stable, its minimum Joomla and PHP versions, and its release notes. |
| Installations | 4 | The customer-site records: list, read, update and delete. This is where you look when someone's site insists it isn't entitled to an update. |
| Activity log | 1 | Downloads, update checks and refusals, newest first, filtered by event type, result, package, IP address or installation. |
Installing it
You'll need Joomla 5 or 6, PHP 8.2 or later, MCP for J, and Cybersalt Release Manager itself on the same site.
- Open Components โ MCP for Joomla โ Browse MCP Add-Ons and click Install on this add-on. You can also download the ZIP above and install it through System โ Install โ Extensions.
- That's the whole install. The plugin enables itself, and the tools show up in your connected AI client the next time it lists them.
The plugin loads cleanly on a site without Release Manager โ each tool notices the component is missing and says so, rather than throwing. There's no admin screen for it either, by design: it adds tools to MCP for J rather than a place to click.
Using it
Ask for what you want in plain language. "What's the latest published version of each of my packages?" is one call. "Which sites checked for an update to this extension in the last week and got refused?" reads the activity log with two filters applied. "Create the 1.2.0 version row for that package, mark it latest and stable, minimum PHP 8.2" does exactly that.
Writes go through the component's own models rather than touching tables, which matters more than it sounds. Saving through the model is what writes the activity-log entry, and it's what moves the file on disk when you rename a package's extension element. A direct database write would leave you with a record that looks right and a file that's no longer where the download endpoint goes looking for it.
The one write that deliberately skips the model
Updating an installation record is the exception, and the reason is worth understanding, because it's the difference between fixing a customer's problem and making it worse.
An installation row holds a customer's email address twice: once in plain text and once as a hash. Those two columns are checked at different points and for different purposes โ the hash is compared against what the customer's site sends, and the plain-text address is used separately to look up the Joomla account behind it. They're independent, and that independence is what makes the repair possible. When someone's entitlement check fails because the row points at the wrong account, you fix it by changing the plain-text address and leaving the hash alone.
Release Manager's own save routine recomputes the hash from the address every time, unconditionally. That's correct for a form the customer's site filled in, and wrong for a repair: it replaces the hash the customer's site is still sending, so the check that was failing for one reason starts failing for a worse one, and now they can't recover without reconfiguring their installation. So this one tool goes round the model on purpose. Recomputing the hash is an explicit option that defaults to off, and every response comes back with both columns and a flag saying whether they currently agree โ so a mismatch is something you can see rather than something you find out about later from a customer.
That repair should be rare now, since Release Manager gained a fallback that finds these customers on its own. What the installation tools are still good for is looking at rows and clearing out orphans without having to open an SSH session to do it.
Open source
GPL-2.0-or-later, the same license as Joomla itself. Source lives on GitHub.
Add comment