Permission to act isn't the same as approval to act.
The official Adapter checks whether an AI agent is allowed to run an ability. WP MCP Server checks whether someone approved this specific change.
A permission check answers a different question than approval.
The Adapter's permission_callback confirms an agent is allowed to invoke a registered ability. That's a role check, tied to WordPress capabilities. It doesn't confirm that anyone reviewed this specific change before it ran.
Answers a different question
permission_callback checks WordPress capabilities — the same role-based gate the Abilities API always uses. It isn't a distinct step where someone signs off on this exact change.
No documented pre-write backup
Nothing in the Adapter's docs describes a pre-write snapshot. If an applied ability writes a bad value, there's no built-in undo captured beforehand.
Treat the Abilities API as an execution layer, govern on top.
Concretely, an adapter for WordPress's own Abilities API is on the roadmap. It's governance that can sit on core's execution layer as it matures, alongside WP MCP's SSH and companion-plugin transports.
Limited to what's actually documented by each project.
| WordPress MCP Adapter (official) | WP MCP Server | |
|---|---|---|
| Raw PHP/eval as the default interface? | No — invokes registered abilities | No — named verbs default; raw eval gated to Tier 3, SSH-only |
| Dry-run before write? | Per-ability — depends on how each ability is built | Yes — apply=False is the default on every verb |
| Backup/snapshot before write? | No | Yes — before every write, plus optional durable re-verify |
| Change-approval gate (beyond role permission)? | No1 — per-ability permission_callback (WordPress capability check) |
Yes — propose/approve change packet, distinct from role/token |
| Block-structural edits? | Depends on registered abilities | No — raw search/replace today (block-aware verb planned) |
| Transport | Plugin (HTTP/STDIO, Abilities API) | SSH+WP-CLI or companion plugin (plugin has no eval) |
permission_callback confirms the caller is allowed to invoke a registered ability — a role/permission check. It stops short of a distinct "someone reviewed and approved this exact change" step.The Adapter alone may be enough if…
- A single trusted operator manages a low-risk site
- Basic, standard connectivity between an agent and WordPress Abilities is all you need
- You're comfortable with anyone holding the right capability being able to act without an extra review step
You need WP MCP Server on top if…
- A compromised session or a second operator could otherwise change production alone
- Client production risk means someone other than the requester needs to approve
- You need audit evidence you can hand to a client or a security reviewer
- Official WordPress MCP Adapter — developer.wordpress.org/news/2026/02/from-abilities-to-ai-agents-introducing-the-wordpress-mcp-adapter
- Adapter project — github.com/WordPress/mcp-adapter
Pulled 2026-07-16. Verify against current docs before relying on a cell — this space moves fast.
Add a review step the Adapter doesn't have.
Founding agencies get 50% off for 12 months — first 20, no setup fee.