Comparison

We are not the most powerful option. That is the design.

The other tools in this category are faster on a site you own and can restore. SiteHelm is built for the other case: a client site, a live business, and an agent you have to be able to answer for. Everything below is a trade we made on purpose, and the column on the right is what those projects say about themselves.

Every claim in the right-hand column is something the other project says about itself, in public. Nothing here is inferred from a screenshot or written to win an argument, and a claim we could not source was left out.

How to read this

Pick the tool that matches the site you are on.

These are not competing implementations of the same idea. They are three different answers to one question: how much should an agent be allowed to do to a WordPress site without a person in the loop.

9 of the rows below are marked as the reason someone chooses SiteHelm. The rest are places where the difference is small, or where the other approach wins.

Your own site

A machine you can restore from a snapshot in ten minutes. The open shell is genuinely faster, and the risk is yours to take.

A client site

A live business, someone else’s revenue, and a phone call if it breaks. This is the case SiteHelm was built for.

Compared with

Open-shell WordPress MCP plugins

What they set out to do

Give the agent the same power a developer has over SSH — PHP execution, WP-CLI, direct SQL, and file edits — and let it build rather than suggest.

When they are the better choice

A site you own, on a machine you can restore, where you want an agent to be able to do literally anything without you writing an operation for it first. If a broken site costs you an afternoon rather than a client, the open shell is genuinely faster.

Executes arbitrary PHP why people switch

SiteHelm

No. There is no path from an agent to running code — no eval, no snippet store, no theme-file editor.

the open-shell approach

Yes, advertised as a headline capability.

Direct database access why people switch

SiteHelm

No query passthrough. Every read and write goes through a typed operation with a schema.

the open-shell approach

Yes — arbitrary SQL against the site database.

Filesystem writes why people switch

SiteHelm

None. No arbitrary file writes and no WP-CLI passthrough.

the open-shell approach

Yes, including plugin and theme files.

Preview before a write why people switch

SiteHelm

Required on every write. You read the exact field-level change and approve it with a single-use token bound to those arguments.

the open-shell approach

Calls execute immediately.

Snapshot and rollback why people switch

SiteHelm

Prior state is captured before the change, and a destructive operation must declare rollback as required.

the open-shell approach

Your own backup.

Read-back verification why people switch

SiteHelm

After a write, the site is read again and the result compared with what the preview promised. A disagreement is a refusal, not a success.

the open-shell approach

The call returns; what landed is yours to check.

Capability checks

SiteHelm

Every operation declares a WordPress capability and re-checks it inside the handler against the specific target.

the open-shell approach

Bounded by the credentials you hand it, which are usually an administrator.

Open source

SiteHelm

GPL-2.0-or-later, on GitHub, with the full test suite.

the open-shell approach

Varies.

Compared with

Breadth-first WordPress MCP toolkits

What they set out to do

Expose as much of WordPress as possible — hundreds of tools covering every corner of the API — and let the agent pick.

When they are the better choice

Reaching a corner of WordPress nothing else covers. If the single thing you need is an obscure API and you are willing to check the result yourself, breadth wins.

Surface area

SiteHelm

A deliberately closed set of named operations, each one declared in code with a schema, a capability, and preview, snapshot and rollback policies.

the toolkit approach

A large tool count, presented as the headline number.

Tools in the model context why people switch

SiteHelm

11 dispatchers. The catalogue for a dispatcher is fetched on demand, so the client tool list stays small.

the toolkit approach

A tool per operation, which is what makes the count large.

Preview before a write why people switch

SiteHelm

Required on every write.

the toolkit approach

Not part of the model.

Snapshot and rollback why people switch

SiteHelm

Before every change that overwrites something.

the toolkit approach

Not part of the model.

Per-operation switches

SiteHelm

Every operation and every module can be switched off from the WordPress admin, independently.

the toolkit approach

Typically all-or-nothing.

Activity log

SiteHelm

Every call, its arguments, its outcome, and its snapshot, in the admin.

the toolkit approach

Varies.

Deciding

The free plugin is the whole safety model.

You do not have to take any of this on trust. Install the free plugin, point an agent at a staging site, and watch what a preview actually returns before you decide anything.

Get the free plugin How the five gates work Free against Pro