SitePilot MCP for WordPress
Your coding agent can work on WordPress. Your site keeps the final say.
Inspect read-only, stage bounded changes, require a human for sensitive work, and keep the evidence needed to roll back.
No arbitrary PHP, SQL, shell, WP-CLI, secrets, or filesystem access.
- 01Agent request
sitepilot-inspect-site - 02WordPress controls
scope · capability · risk · approval · version
- 03Bounded result
site:read
Controls that remain on the WordPress side
- Read-only firstNew remote clients register with a site:read ceiling.
- Human approvalSensitive changes pause for an expiring, hash-bound approval.
- Typed operationsThe server exposes a bounded operation table, not a general runtime.
- Rollback recordSupported changes retain snapshots and ordered compensation data.
Quick-start proof
Two commands. One restart. One bounded inspection.
Use an existing SitePilot-enabled WordPress site. The credential stays outside the project configuration.
Quick start1. Authorize a read-only profile
npx -y sitepilot-mcp@0.1.6 login --url https://your-site.example --scopes site:read --profile my-site2. Configure Cursor
npx -y sitepilot-mcp@0.1.6 init --client cursor --profile my-siteReload Cursor once.
Call sitepilot-inspect-site exactly once and confirm site:read.
A bounded lifecycle
The model proposes. WordPress decides.
- 01
Inspect
Read site and builder state through Tier 0 tools.
Credential scope and WordPress capability
- 02
Plan
Turn a mutation into a typed change set with an expected version and diff.
Operation schema and risk tier
- 03
Approve
Pause Tier 2 and Tier 3 work for a human decision.
Expiring approval bound to the change hash
- 04
Execute
Recheck scope, capability, approval, and version before applying.
Server-side enforcement
- 05
Validate or roll back
Audit the result and retain supported compensations.
Snapshot and ordered rollback record
Current boundaries
Builder-aware, with the gaps left visible.
Support is stated per surface. A green label never expands an unsupported structure into a promise.
| Surface | Current boundary |
|---|---|
| Gutenberg | Inspection, staged changes, publishing approval, and rollback. |
| Elementor 3 | Classic document inspection, construction, bounded edits, approval, and rollback. |
| Elementor 4 mixed | Per-region inspection and known typed-setting updates only. |
| Enfold ALB | Calibrated inspection and bounded edits; nested global structures remain unsupported. |
| WooCommerce | Guarded product, stock, price, and order operations under scope and approval controls. |
Security boundary
General server access is not part of the product.
If an operation is outside the bounded table, the agent cannot request it through SitePilot.
SitePilot exposes
- Typed inspection
- Typed change plans
- Risk-tiered execution
- Approval and audit records
- Supported rollback operations
SitePilot refuses
- Arbitrary PHP or JavaScript
- Arbitrary SQL
- Shell or WP-CLI
- Server secrets or wp-config.php
- Arbitrary filesystem access
Limits are part of the contract
Bounded means some work stays outside SitePilot.
- Elementor 4 atomic construction, structural edits, and Global Classes or Variables writes are unsupported.
- Uncalibrated nested Enfold global structures must be changed by an administrator in Enfold.
- Visual regression baselines and whole-site durable builds require the optional cloud control plane.
- HTML and CSS compilation is best effort and does not guarantee pixel similarity.
Questions before you connect
The short answers are deliberately conservative.
Does SitePilot give an agent full WordPress access?
No. Each request must match a registered typed operation, credential scope, WordPress capability, risk rule, and any required approval.
Does a read-only connection change content?
No. The site:read scope permits bounded inspection and does not grant change execution.
Where are credentials stored?
The npm adapter stores the local profile outside project configuration. WordPress retains and enforces the server-side grant.
Can SitePilot edit every Elementor 4 document?
No. Mixed pages support per-region inspection and known typed-setting updates on existing atomic elements only.
Is the cloud service required?
No for the one-site control surface. The plugin and npm adapter provide that surface; cloud-only evidence and fleet coordination remain optional.
Released artifacts
Public adapter, versioned plugin, recorded parity.
The npm artifact is built from the public mirror with provenance and compared against the authoritative product source. Provenance identifies the build source; parity is checked separately.
- npm adapter
- 0.1.6
- WordPress plugin
- 0.4.10
- Public source mirror
- GitHub