MCP server
What you get insteadTwo transports
A Node MCP server over stdio, and a native HTTP endpoint in the plugin. Same catalog, same safety model.
Developers and technical leads
A WordPress MCP server that writes in the builder's own format.
The REST API stops where page builders begin. This reads and writes their real structures, validates before it injects, and snapshots before it writes.
- 250+ tools and abilities
- on every core plan, WooCommerce as an add-on
- 17 page builders
- with their schemas, not guesses
- 90 days of rollback
- snapshot per write, per page or per session
What a write actually does
You type
Change the hero heading on /pricing to "Simple pricing". It is Divi 5, so target it by path, not by id.
- 1Resolves that path to exactly one element and validates the payload against Divi 5's element schema
- 2Snapshots the page, then writes through respira_update_element in Divi's own block structure, not HTML
- 3Reads the page back and compares, so a write that did not land comes back as an error rather than a success
What you get
A typed result with the before and after, the snapshot id, and a collateral report if anything outside the target moved.
A write that reports success while the value never changed is the failure mode this is built against.
What you hit without it
- The REST API has no idea what a Divi module is
- Every builder stores content differently and documents none of it
- No safe write path for an agent, so everything is manual
- WordPress sits outside the MCP stack you already run
What you get instead
- One MCP server, typed tools, real schemas per builder
- Duplicate-first by default, explicit confirmation for live writes
- Snapshots, audit log, and a read-back check on every write
- Composes with the GitHub, Linear and Figma servers you already have
Everything on this page ships today.
WebMCP
Browser agents get the abilities surface through the WordPress Abilities API, registered by the same plugin.
Schemas
Element schemas per builder, validated before injection, so a malformed write is refused rather than saved.
Collateral guard
After a targeted write it compares the whole page and refuses if something nobody addressed lost content.
Idempotency
A call id makes a retry replay the original result instead of writing twice.
Telemetry you own
Metadata only: tool, duration, success. No prompts, no arguments, no content. One env var turns it off.
The MCP server
Two transports, one catalog, one safety model.
A Node server over stdio and a native HTTP endpoint inside the plugin, exposing the same tools with the same guards. The page that explains the wiring, the auth, and what a client actually sees on connect.
- Per-site context filtering, so a block site is not offered Divi tools
- WebMCP abilities registered through the WordPress Abilities API
- Tokens scoped per site, revocable, and never in the prompt
The CLI
The same tools, without a conversation in the way.
For CI, migrations and anything you would rather express as a command than a sentence. It calls the same catalog through the same safety model.
- Scriptable, so a thirty-site pass is a loop and not a chat
- Snapshots and approvals still apply
- Useful when the agent is the wrong tool for the job
Each of these has a page of its own.
What it costs
Maker is €9 a month for one site, Builder €19 a month for five, Studio €57 for 25. The trial is 7 days and takes no card.
The questions people actually ask
How does it connect?
npx @respira/wordpress-mcp-server with a site token, or point an MCP client at the plugin's own HTTP endpoint. Both expose the same catalog.
What happens on a failed or partial write?
The page is read back and compared. A write that did not land is returned as an error with the value the site actually reports, not as a success.
Can I run it against staging only?
Yes. A licence covers a number of sites and nothing says which. Point it at staging, keep production off the list.
Is the source available?
The MCP server is published on npm and the documentation is public. The plugin ships as a licensed product.
