A clean staging test doesn't mean anyone approved it.
InstaWP tests changes on a disposable clone, then promotes what looks right. WP MCP Server requires a specific approval before anything reaches the live site.
execute_php off by default and adds four separate guard layers on top. Changes run first on a disposable staging clone, and you promote once it looks right. If your sites already live on InstaWP's hosting, that workflow is a natural fit.A promote step isn't an approval step.
InstaWP's table entry lists no change-approval gate beyond promoting a tested clone. Promotion confirms the copy behaved. It doesn't confirm a second, specific person signed off on the live change.
No approval gate documented
The comparison table lists InstaWP's change-approval column as no. A clone gets tested and promoted, but nothing requires a separate person to approve the live change.
Tied to one hosting environment
InstaWP's MCP layer runs through a plugin plus hosted staging. That works well if every client site already lives there — fewer agencies can say all of theirs do.
One rulebook, every host, every site.
Most agencies don't run every client site on the same host — mixed hosting is the norm. WP MCP Server reaches a site over SSH+WP-CLI or a companion plugin. Same guarded verbs, same packet approval, regardless of who hosts the site.
Works no matter who hosts it
SSH+WP-CLI or the companion plugin reach a site the same way whether it's on InstaWP, another host, or a client's own server.
Credentials stay put
No vendor holds your SSH keys or WordPress application passwords. They stay on the infrastructure you already control.
Same rules everywhere
Change packets and approval work the same way on every site in the fleet, no matter where each one happens to be hosted.
Limited to what's actually documented by each project.
| InstaWP / InstaMCP | WP MCP Server | |
|---|---|---|
| Raw PHP/eval as the default interface? | No — execute_php off by default, 4 guard layers |
No — named verbs default; raw eval gated to Tier 3, SSH-only |
| Dry-run before write? | Via staging clone (test-then-promote) | Yes — apply=False is the default on every verb |
| Backup/snapshot before write? | Via disposable staging clone | Yes — before every write, plus optional durable re-verify |
| Change-approval gate (beyond role permission)? | No | Yes — propose/approve change packet, distinct from role/token |
| Block-structural edits? | — not documented | No — raw search/replace today (block-aware verb planned) |
| Transport | Plugin + hosted staging | SSH+WP-CLI or companion plugin (plugin has no eval) |
Choose InstaWP if…
- Your sites already live on InstaWP's hosting and staging
execute_phpoff by default, with four guard layers on top, covers the caution you need- Testing on a disposable clone before promoting is the workflow you want
Choose WP MCP Server if…
- Client sites are spread across more than one host
- A specific approval step should exist beyond a clone looking right
- Credentials need to stay on your own infrastructure instead of a hosting vendor's
- InstaWP MCP server — instawp.com/wordpress-mcp-server
Pulled 2026-07-16. Verify against current docs before relying on a cell — this space moves fast.
Govern client sites no matter who hosts them.
Founding agencies get 50% off for 12 months — first 20, no setup fee.