nipun-arora/wordpress-mcp-agent-bridge

*Agent Bridge is the safety and SEO layer for AI-edited WordPress: it proves every write, snapshots everything it touches, and refuses the writes you didn't authorize. It pairs with EMCP, which does the Elementor editing.*
What it is
Agent Bridge is a WordPress MCP for Claude Code and every other MCP client, built for self-hosted WordPress (WordPress.org installs, not WordPress.com) where an AI agent manages a site's SEO, schema, and safety net alongside, or instead of, a human editor in wp-admin. Claude Code is the primary documented client, but nothing here is Claude-specific: Cursor, Windsurf, Codex CLI, Gemini CLI, or any MCP client connects through the same official WordPress MCP Adapter endpoint, and the REST surface needs nothing beyond an Application Password. It's designed to pair with EMCP, the Elementor MCP for Claude Code most agents already reach for on layout work. EMCP edits the page. Agent Bridge never writes _elementor_data at all; what it covers is the layer builder tools consistently skip: Rank Math SEO fields, JSON-LD schema, content snapshots, and a restore that proves it converged.
Every write Agent Bridge makes is read back from the database before it's reported saved. Every page and post gets a stable content hash, so an agent can tell in one request whether anything has changed since it last looked, and a write aimed at content that predates the plugin's own activation is refused unless the caller proves it just captured a fresh snapshot of that exact post. Two kill switches, set in wp-config.php, let an operator take the whole thing offline or lock it to read-only without touching the plugin itself.
Why this exists
Most WordPress MCP servers report a write successful the moment their API returns HTTP 200. Of the safety-focused ones surveyed for this project's own competitive research, none publish a write that reads its own result back from the database before saying so, and none document a hash-verified restore, a proof that a rollback actually converged to what it claims, rather than just a note that a snapshot exists somewhere. See How Agent Bridge compares below for the specific tools, what each documents, and the sources.
A live example of what a capability gap actually costs: in 2026, the AI Engine plugin's MCP module shipped a privilege-escalation flaw that let subscriber-level WordPress accounts hijack MCP-authenticated actions, on more than 100,000 sites (gbhackers.com/over-100000-wordpress-sites-exposed). The root cause was a capability check gap on MCP-authenticated calls: a request carrying a valid credential wasn't also checked against the specific WordPress capability the action required.
Agent Bridge closes that exact class of bug in its route design, not in a promise. Every route scoped to one post checks edit_post for that exact post ID (Agent_Bridge_Auth::can_edit_post()), never the blanket edit_posts grant a lower-privilege account might also hold. Routes that affect the whole site (restore, cache purge, health, the snapshot hash backfill) require manage_options. The Abilities API layer runs the identical checks per ability, not a looser mirror of them (Agent_Bridge_Abilities::permission_*).
Verified Writes
Every SEO field write and every schema write is followed immediately by a fresh get_post_meta() read from the database. A value is only reported saved once that read-back matches what was written, accounting for WordPress's own type coercion (array order, numeric-string image IDs). A caller never has to trust an HTTP 200: if the write-back doesn't match, the route returns a 500 with the field name, the value it tried to write, and what the database actually holds (Agent_Bridge_Seo::write(), Agent_Bridge_Schema::write()).
Stable Content Hash
Every page and post gets one SHA-256 hash, recomputed automatically whenever the post itself, its Elementor data, its bridge-scope SEO fields, or its Rank Math schema meta changes (hooked on save_post and the added_post_meta / updated_post_meta / deleted_post_meta actions in Agent_Bridge_Snapshot::init_hooks()). The hash covers post_content, the verbatim Elementor blob, and the sorted SEO plus schema meta, so one call to /snapshot/manifest tells a caller, for every page and post on the site, whether anything has touched it since the last time the caller looked.
Verified Restore
Restoring a snapshot doc is not "trust this backup." The request has to clear two separate proofs before anything is written. First, the document itself has to be self-consistent: the confirm token sent with the request has to equal the doc's own stated hash, and recomputing that hash from the doc's own content, Elementor data, SEO, and schema fields has to produce the same value (proof the doc is untampered, not just plausible-looking). Second, the caller has to prove it just read the post's real live state, via the same additive-only header the Additive-Only Gate below requires. Only once both gates pass does restore converge the post (content, Elementor data, SEO, and schema) to exactly what the doc says, deleting fields the doc doesn't mention rather than merely patching over them, and it hands back the resulting document so the convergence can be checked directly instead of assumed.