There is the work a client sees, and the work a client never sees. The first is mockups, copy, photographs, going live. The second is checking that nineteen sites are still up to date, properly hardened, backed up, and that not one of them is serving a stale page to a visitor. That invisible work is neither billed nor noticed, but it is what decides whether a subscription holds up over time.
For several months now we have run that fleet through Cloudways’ MCP, wired into Claude. Here is what it genuinely changes, what it does not, and the gaps we reported back to their product team.
What an MCP is, without the jargon
An MCP server is a standardized connector. It exposes the functions of a service, here the Cloudways API, in a format a conversational assistant can read and act on. The protocol itself is open: any vendor can publish one, which is why a new one turns up every week.
In practice: instead of opening a console, clicking through application after application and copying values into a spreadsheet, you ask for the state of the whole fleet in plain French, and you get it.
The shift is not one of typing speed. It lies elsewhere: a check that used to cost a day becomes cheap enough to run often. And an annual check protects nobody. It is frequency that protects, not depth, and that is exactly what separates a fleet under watch from one left to age untouched.
What it changes, with the measurements
| Task | Before | With the MCP |
|---|---|---|
| Configuration and security review across every application | A full working day | A few minutes, run often |
| Hardening checks, application by application | Tedious, therefore partial | Exhaustive, nothing slips past |
| Cache purge after a fix | Manual, therefore sometimes forgotten | Built into the sign-off loop |
| Triaging vulnerabilities across the fleet | Site by site | One session, prioritized |
Three concrete findings from those audits are worth more than any speech.
A database bloated for nothing. On one WooCommerce store, a logging table left behind by an uninstalled security plugin weighed 2.8 GB, roughly 98% of the database footprint. Nobody had read it in months. Without a fleet review it would have gone on growing, slowing the backups and swelling every restore.
An undersized opcode cache. The server’s compiled code cache was set to a fraction of what the fleet was asking for. Measurement showed the hash table saturating twice over, which reset the cache to zero and dragged its hit rate down with it. The corrected setting, measurements in hand, shows on every page, and display speed is paid back directly in rankings.
Alerts that lied. The vulnerability scanner was flagging plugins that were already up to date. Cross-checking, site by site, the version actually installed against the version announced, half the alerts turned out to be false positives. That is exactly what has to be verified before automating anything: stale data, once automated, becomes a mistake at industrial scale.
Our method: trust is built out of boredom
We never granted this tool an ounce of trust up front, and that is the reason we now use it across the whole fleet.
- Read-only first. For the first few weeks the assistant does nothing but read: servers, applications, settings, backups. Every answer is compared against the console. One false answer would have been enough to stop everything.
- Then actions with nothing at stake. Purging the cache was the first write we allowed: if it fires when it should not, the worst that happens is a page gets recalculated.
- Never a delegated decision. A major plugin update on a live store remains a human choice, preceded by a backup and followed by a check. The tool speeds up the diagnosis, not the judgment.
It is austere, and that is precisely the point. Trust did not settle in because the tool is impressive, but because every claim was checked until checking became pointless.
The gaps we reported
We sent this feedback in writing to the Cloudways product team, who put it on their quarterly roadmap. Here it is as written, because an honest field report is worth more than a pat on the back.
- Cache purging by URL. Today a purge covers a whole application. Refreshing a single corrected page therefore means emptying the entire cache of a busy store. A line of documentation is missing too: the edge cache only serves addresses without query parameters, which cost us a few hours of digging.
- Backup retention in the API. Frequency is exposed there, duration is not. We need it to write exact commitments into our contracts, and we had to go and find it by hand.
- Fresher vulnerability data. Cross-referencing against the version actually installed would make these alerts usable by an automation, which they are not yet.
- Visibility on advanced performance settings. The opcode cache file limit, or the database table cache, can only be reached through support. Exposing them, even read-only, would save a round trip on every diagnosis.
A fifth is missing, and it runs deeper: the scope of access tokens. A Cloudways API token opens the entire account. For an agency, the unit that counts is the application, not the account. Until a token can be confined to one named application, read-only if that is what you want, no third party autonomous tool will touch our production servers. That is a rule we do not negotiate, and we said so to Cloudways as plainly as we say it here.
What it does not repair
An assistant plugged into an infrastructure corrects no design flaw. A heavy site stays heavy, a plugin firing forty queries per page stays expensive, a badly built theme stays badly built. The risk is even that a well-tuned cache hides the problem, right up to the day an uncached page collapses under traffic. Our method for diagnosing the real cause of a slow site has not shifted an inch, and on the day a site goes down for real, it is the preparation that counts, not the tool.
The same holds on the security side. Seeing the hardening status of nineteen applications in a minute is valuable, but it replaces neither the groundwork in our guide to securing WordPress in depth, nor the eight essential measures we apply at every launch. A dashboard full of green has never stopped an update from breaking a site, nor a site from being hacked.
Why this looks like us
There is a reading of digital sobriety in all this, and it is not decorative. To stop recomputing the same page a thousand times, to purge a cache at the right moment rather than at random, to delete 2.8 GB of logs nobody will ever read, to extend the life of a site instead of rebuilding it: that is energy not spent. It is the same logic we apply to choosing hosting that is genuinely frugal.
Cloudways asked us about this way of working over the summer, for a case study and an agency profile due to appear on their site. We answered with the same figures as the ones in this article, and with the same reservations: we recommend a tool only if we are willing to describe its limits. We will add the links here as soon as they are published.
What we take from it
The MCP has not made our work more impressive, it has made it more honest. What we promise clients today is what we can verify in front of them, in a few seconds, on their site specifically. For an agency run by one person, that is what makes it possible to keep watch over an entire fleet without cutting into the care each site is given, and without making a promise we could not keep.
If you run several sites and the fleet review has become a chore you keep putting off, the subject is worth an hour of your time. Start by measuring honestly what a full check costs you today: it is that figure, and not the novelty of the tool, that will tell you whether it has a place with you.
More from Aloha Pixel
- Web hosting: choosing the right host for your site
- Shared, VPS or cloud hosting: the complete guide
- Securing your WordPress site: the 8 essential measures
- What a site left without maintenance really costs
- Our websites on a monthly subscription, hosting and upkeep included
- Bring the agency in on your fleet
- Talk to us about your infrastructure
