MCP for StageIt is a free add-on for MCP for J that drives your StageIt staging environment from your AI client. Eleven tools cover status and prechecks, the backup snapshots StageIt takes on your behalf, and the four operations that actually move things โ deploy, sync, remove and restore. Each of those four is chunked and hands back a resume token, so an operation too big to finish inside your server's PHP time limit can be driven to the end across several calls instead of stopping halfway. It's new, it's still being tested, and on a big site or a tight shared host it can still run out of time โ there's an honest section on that below, and you should read it before you point this at anything you care about.
Why this exists
StageIt's deploy and sync only exist while a browser tab is open on them. The admin screen runs them from a JavaScript loop that posts the previous response back as the next request, over and over, until the operation reports it's finished โ which works, but it means the whole thing lives in a page you have to sit and watch, and there's no way to ask for it from anywhere else. This add-on ports that same loop into PHP so an MCP client can drive it, which is a bigger job than it sounds: StageIt's code assumes it's being called from its own admin folder, and its AJAX layer ends every stage by printing a response and killing the request. Both of those had to be handled in the wrapper rather than by patching StageIt.
What Claude can do
Eleven tools. The four operations are each a pair: one to start, one to continue.
| Area | Tools | What you can do |
|---|---|---|
| Status | 3 | Whether staging exists and when it was last touched, StageIt's own precheck battery covering disk space, memory, PHP timeout, permissions and required extensions, and the list of backup snapshots you could restore from. |
| Deploy | 2 | Copy the live site into the staging mirror and clone the database into staging-prefixed tables. Start it, then continue until it reports done. |
| Sync | 2 | Promote the changes you made in staging back to live, snapshotting the current live site first so you can roll back if it goes wrong. |
| Remove staging | 2 | Delete the staging mirror and its database tables. Your backup snapshots aren't touched. |
| Restore a backup | 2 | Rebuild live from a named snapshot. This is the rollback path for a sync you regret. |
Installing it
You'll need Joomla 5 or 6, PHP 8.2 or later, MCP for J, and StageIt itself, which is a separate commercial product from PHP Web Design.
- 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.
There's no admin screen for this plugin, by design โ it adds tools to MCP for J rather than a place to click. On a site without StageIt every tool says so plainly instead of failing in a confusing way.
Using it
Ask for what you want in plain language. "Is my staging site up to date, and what did the prechecks say?" answers both in one go. "Push live to staging so I can try the template change there" starts a deploy and keeps continuing it until it's finished. "That sync was a mistake โ put back the snapshot from this morning" finds the snapshot by name and restores it.
Three of the four operations overwrite things that exist. Sync overwrites live from staging, remove deletes the staging environment outright, and restore overwrites live from a snapshot. Run the prechecks before any of them โ they're the same battery StageIt's own dashboard runs, and if they fail there, the operation will fail too. Sync takes a snapshot of live before it touches anything, so the rollback path is already there when you need it.
How the resume token works
StageIt already breaks each operation into ordered stages and keeps its own position within them, so the chunking isn't something this add-on invented. What doesn't survive is the PHP request: StageIt holds that position in memory, which is empty by the time the next call arrives. So each tool call runs stages under a time budget โ by default a little under whatever your server allows โ and if the budget runs out before the operation is done, the state is written to a file on disk and you get a resume token back with a progress figure. Passing that token to the matching continue tool restores the state and picks up at exactly the stage it stopped on.
In practice you don't manage any of that yourself. Your AI client gets a token and a "not finished" flag, calls the continue tool, and repeats until the operation reports done. On a small site the first call often finishes on its own and there's no token at all.
Experimental, and what that means
Chunking is the design response to the timeout problem. It isn't a cure for it, and it would be dishonest to sell it as one. Each individual call still runs under your server's PHP execution limit, and there are stages โ a large database clone, a big file copy โ where a single chunk can be the thing that runs long. On a large site, or on shared hosting with a tight time limit, an operation driven through MCP can still time out mid-flight, and when it does, the cause is your site size and your host's configuration rather than anything this add-on can fix.
The recovery path is the one you'd want anyway: open StageIt's own admin screen on the site and finish or roll back the operation from there. StageIt's state is StageIt's state: the tools drive its machine rather than keeping a private copy of it, so its admin UI picks up a half-finished operation the same way it always would.
Test it on a non-production site first, or on a small site where timing out wouldn't cost you anything. If you do hit a timeout, a report is genuinely useful: github.com/cybersalt/cs-mcp-for-j-addons-free/issues.
One more thing worth knowing about version 1.0.0: it covers status and the four operations, and nothing else yet. StageIt's settings, its logs, and deleting individual backup snapshots are all still admin-screen jobs. Those are planned, but the priority was getting the long-runners tested before adding more surface around them.
Open source
GPL-2.0-or-later, the same license as Joomla itself. Source lives on GitHub.
Add comment