Inspect before you touch
Ask for the element tree, the registered post types, the global classes or the WooCommerce setup report. Read Only makes this safe on production, and it is usually faster than opening wp-admin.
For developers
Your site, as a properly described API.
Every operation is a registered ability with a JSON schema, a permission callback and a risk class. 27 clients are documented, 53 integration families ship in Pro, and the policy that decides what runs lives on the site, not in the prompt.
The contract
Discovery is runtime, not prompt-time.
The agent asks the site what it may call. That single design decision is what makes the rest of the model hold.
typed input schemaspermission callbacksrisk classificationconfirmation contractrate limitingchange ledgerapproval queueMCP promptsskills as MarkdownOAuth 2.1 + PKCEApplication Passwordsdomain lock
A prompt that says “you may now delete plugins” changes nothing, because the ability list came from the site and the deletion ability was never registered. Instruction text found in a page, an issue, a product description or a comment gets the same treatment.
That is the difference between a permission model and a persuasion model. Everything downstream, profiles, confirmations, the approval queue, the change ledger, is only meaningful because the surface itself is fixed before the conversation starts.
Working sessions
What this looks like in Claude Code or Cursor.
Same shape as any other agentic session: read, plan, act, verify. The site just happens to be one of the tools.
Compose from real schemas
Element type schemas, field type schemas, template condition schemas. The agent reads the vocabulary of the target plugin, which is why the output opens in that plugin's editor.
Batch the boring parts
Two hundred products, forty redirects, a taxonomy migration. Paced by the rate limiter, resumable, and reported as a diff at the end rather than a wall of green ticks.
Escalate deliberately
Switch to Developer Full Access when you genuinely need WP-CLI or a PHP snippet, then switch back. The profile is a decision you make, not a default you inherit.
Enforced, not documented
Six properties worth checking in the source.
Every one of these is code, not policy language. Clone the repository and grep for it before you point anything at a site you care about.
Security model in detail- Abilities blocked by the active profile are unregistered, not refused at call time, they never appear in the agent's tool list, so a jailbreak has nothing to aim at.
- Risk is derived from the ability category and name, not from a per-install setting someone can quietly widen. Anything matching the critical set is critical everywhere.
- Destructive and critical calls require a confirm flag inside the ability parameters, enforced at both MCP dispatch and REST entry.
- Writes are rate limited to 120 per minute per credential. Reads are exempt, so inspection stays cheap and mutation stays paced.
- Content abilities refuse wp_template, wp_template_part, wp_global_styles, wp_navigation and wp_block through the generic wrapper, FSE internals are not a free-text surface.
- The plugin ships disabled and domain-locked. A cloned staging database cannot start answering for production.
Extending it
Skills are Markdown. Abilities are a filter.
If you maintain a plugin, both extension points are already the shape you would have designed.
Register your own abilities
Use the WordPress Abilities API. Anything you register inherits policy, risk classification, confirmation and rate limiting without extra work.
Ship a skill with your plugin
A skill is a Markdown file with front matter. It is injected into the discovery instructions, and the agent loads the full text on demand rather than carrying it in every context.
Expose prompts as slash commands
Prompt-mode skills register as MCP prompts, which surface as slash commands in clients that support prompts/list.
Questions
The technical ones.
How is this different from hitting the REST API myself?
The REST API describes resources; abilities describe operations with input schemas, permission callbacks, risk classification and confirmation rules. The agent discovers what it may call at runtime rather than being told by your prompt, so a prompt-injected instruction cannot widen the surface.
Does it work with the official WordPress MCP adapter?
It builds on the same foundation, the Abilities API, and registers abilities that the adapter exposes over MCP. The difference is what sits on top: safety profiles, per-ability policy, confirmation on destructive calls, rate limiting and the plugin-aware modules.
Can I run WP-CLI or PHP through it?
Under Developer Full Access, yes: run-wp-cli, execute-php, write-file and edit-file exist. They are classified critical, which means they are unregistered entirely under the default Production Safe profile and require an explicit confirm flag when they are available.
How does authentication work?
Two documented routes: OAuth 2.1 with PKCE and dynamic client registration for clients that support it, or WordPress Application Passwords over HTTPS for those that do not. The agent acts as a real WordPress user, so capabilities apply exactly as they would in wp-admin.
Can I add my own abilities?
Yes. Abilities are registered through the WordPress Abilities API, so anything you register is discoverable and inherits the same policy, risk classification and confirmation handling. Skills are Markdown with front matter, which makes bundling a workflow with your own plugin straightforward.
Is the source auditable?
WPPilot Free is GPL v2 and published on GitHub. The safety classification, the denylist, the rate limiter and the ability registrations are all readable, which is the only sensible basis for pointing an agent at a production site.
Your site · your policy · your AI client
Read the source, then point it at staging.
WPPilot Free is GPL v2 on GitHub. Clone it, read the safety classification, and decide for yourself what your agent should be allowed to do.