Keep agent mode fast. Keep client WordPress sites safe.
WP MCP Server lets Cursor move at full speed everywhere — except the exact moment a write would hit a live client site.
Runs on your own infrastructure. WP MCP Cloud never holds SSH keys or site credentials.
Agent mode moves fast on your codebase. A live WordPress site can't git revert.
Let agent mode run against a client's WordPress site the way it runs against your repo. One autonomous step can change a live option before you've even seen it happen.
Three steps, and the exact walkthrough lives in the docs.
docker compose up -d) or pip install -e .. It comes up on 127.0.0.1:8642, bound to loopback — nothing outside your machine can reach it.site_register at a site over SSH+WP-CLI, or install the companion plugin for sites where you only have plugin access..cursor/mcp.json — global (~/.cursor/mcp.json) or per-project, whichever your team already uses.{
"mcpServers": {
"wpguard": {
"url": "http://127.0.0.1:8642/mcp",
"headers": {
"Authorization": "Bearer <TOKEN>"
}
}
}
}Agent mode keeps moving. Writes are the only thing that pause.
Full-speed investigation
Cursor can inspect core version, active plugins/theme, options, and post meta with no added latency. No packet, no approval step — nothing here slows agent mode down.
One pause, right before impact
Option updates, post-meta edits, and content search/replace all preview first with apply=False. Cursor only stops moving at the exact moment a write would hit the live site.
Deliberately hard to reach
Raw PHP execution still exists for edge cases most agents never hit. It's SSH-only, admin-scoped, and deliberately slower to reach than anything agent mode uses by default.
Cursor can draft the change in seconds. WP MCP still waits for a second signature.
Let Cursor's agent mode take a change from idea to ready-to-ship on its own. A second person still reviews the exact preview and approves it before it goes live.
packet_open(summary="Update tagline for spring promo",
risk="low", verb="wp_mutate_option", …)
→ status: proposed
packet_approve(packet_id="a1b2c3", approver="connor")
→ status: approved
// the proposer and the approver can be different peopleEven a stale write gets refused, automatically.
If someone else changes the live value after Cursor previewed a change, the write fails at execution. It never silently overwrites what changed underneath it. Pass the dry-run's etag back as expected_etag, and a stale write fails closed automatically.
The same digest binding refuses execution if a packet's arguments were tampered with after approval. An approval that no longer matches what's about to run simply doesn't count.
Before you connect Cursor, you'll probably ask
-
"Agent mode is fast because nothing stops it mid-task."
Nothing still stops it — reads, drafts, and cache-busts all run at full speed. The only pause is the instant a write would hit the live site.
-
"I don't want to leave Cursor to approve something."
Approval is just another MCP call. Grant it from Cursor, the CLI, or wherever your approver already works.
-
"I don't want a vendor holding my client's SSH keys."
wpguard-mcp runs on your own infrastructure. WP MCP Cloud never touches customer sites or holds SSH keys or credentials.
Also using Claude or Codex?
Same guard, same packets, same evidence trail — whichever MCP client your team standardizes on.