Home / Features
What it does, and what it refuses to do
Agent Abilities for MCP is a free WordPress plugin that runs a governed MCP server on your site, and the abilities are only half of it. The other half is the layer that decides whether a call is allowed to run: capability checks, an audit log, rate limits, and hard limits that hold no matter what the agent asks.
Each one is a rule the plugin holds for you, not a setting you have to remember to turn on. Green means reads, amber means guarded writes, blue means the machinery that gates everything.
The agent signs in as a real WordPress user through OAuth or an Application Password, never an admin-equivalent key, and it takes that account’s capabilities. Approve while logged in as the account you want the agent to be.
Nothing is exposed on install. You switch on one ability at a time, and an update never widens access on its own.
A connection only sees the tools its user can run, and every call re-checks that capability before it runs.
Every call is written to a log in your own database, denied attempts included, with the argument keys and a short note of the identifiers it touched (ids, slugs, statuses), never free-text content. Since 1.5.0 it covers governance too: which ability you switched on, which setting you changed. Filter it and export the result as CSV.
Writes stay conservative. Deletes go to Trash where WordPress supports it, and the last administrator can never be removed.
Read content across WordPress core, plus a single site-wide search that spans every post type.
Add a per-minute rate limit, an IP allowlist, force-to-draft mode, or a title-length cap. All off until you set them.
The plugin calls no AI provider and makes no outbound requests of its own. Your client connects in. Zero telemetry.
Runs on the WordPress 6.9 Abilities API and the official MCP Adapter. No custom transport of ours in the path.
These hold whether an agent calls one ability or a hundred. None of them depend on the agent behaving well.
The agent connects as a real WordPress user, never an admin-equivalent key. It takes the capabilities of whichever account approves the connection, so approve while logged in as the account you want the agent to be. With an Application Password you pick that account up front.
Nothing is exposed until you enable it, and updates never silently widen access.
A connection only sees the tools its user can call, and every call re-checks that capability before it runs.
Every call is recorded, denied attempts included, with the principal, the argument keys, and a short note of what it touched: identifiers only, such as ids, slugs, and statuses, never free-text content like a post body or an email address. Since 1.5.0 it records governance as well as calls: every ability switched on or off and every setting changed, each row tagged with an event type and a detail line that names what it touched. It lives in your own database, filters by result, and exports to CSV.
No arbitrary option or meta access, no remote URL fetch, no code execution. Deletes go to Trash where supported; the last administrator can never be removed.
The plugin contacts no AI provider and no external service. Your AI client connects in; the plugin never reaches out. Zero telemetry.
Discovery and execution are checked separately. Seeing a tool and being allowed to run it are two different permissions.
The tool list a connection receives is filtered to the connected user's capabilities. An agent cannot list, or even learn about, a tool it has no right to run.
Filtered at connect time
Before an ability executes, the plugin checks that user's capability again. A tool that slipped through, or a permission that changed, is caught here, not trusted from the first check.
Re-checked on every call
Why two layers: a single check at discovery is easy to work around. Re-checking at execution means the agent never gets more reach than the WordPress user you bound it to, even if it asks for it directly.
Every call is recorded, denied attempts included, with the principal, the argument keys, and a short note of what it touched: identifiers only, never free-text content. It lives in a table on your site, so nothing about it leaves.
principal=editor tool=create-post keys=[title, status] result=okThe connection signs in as a real WordPress account, through OAuth or an Application Password, and its reach is exactly that account's reach. Over OAuth that account is whichever one approves the connection in the browser, so approve while logged in as the account you want the agent to be.
Point the agent at a dedicated low-privilege user and it can only do what that user can do. Every call that follows is re-checked against that same account and written to the log.
The whole governance layer as one catalog, grouped by what it protects. Each row carries the same least-privilege badge you see in the console.
| Access | |
|---|---|
| Scoped user identityRead only | The agent authenticates as a real WordPress user you pick through OAuth or an Application Password, never an admin-equivalent key. |
| Filtered discoveryRead only | A connection only lists the tools its user is allowed to run. An agent cannot see a tool it has no right to call. |
| Per-call capability checkGuarded write | Before an ability runs, the plugin re-checks that user’s capability. Discovery and execution are gated separately. |
| Writes | |
| Guarded writesGuarded write | Writes stay conservative and every one is capability-checked. There is no arbitrary option or meta write. |
| Deletes go to TrashGuarded write | Where WordPress supports it, deletions move items to Trash rather than removing them for good. |
| Last administrator protectedDenied | The last remaining administrator account can never be removed, whatever the agent asks. |
| No code or remote fetchDenied | The plugin runs no arbitrary code and fetches no remote URLs on the agent’s behalf. |
| Data | |
| No data leaves your siteRead only | The plugin contacts no AI provider and makes no outbound calls of its own. Zero telemetry. |
| Personal-data integrations gatedGuarded write | WooCommerce and ACF can reach real personal data, so they sit behind a clear admin notice before you enable them. |
| Rate limit and IP allowlistOff until enabled | Add a per-minute rate limit or an IP allowlist. Both stay off until you set them. |
| Force-to-draft and title capOff until enabled | Force new content to draft, or cap title length. Optional guards, off until you turn them on. |
| Audit | |
| Every call loggedRead only | Each call is recorded in a table in your own database, with the principal and the argument keys. |
| Denials logged tooDenied | Refused attempts are written to the same log, so you can see what an agent tried to do and was stopped from doing. |
| No free-text storedRead only | The log keeps argument keys and the identifiers a call touched (ids, slugs, statuses), never free-text content like a post body or email, so it stays useful without hoarding sensitive data. |
| Governance changes loggedRead only | Switching an ability on or off and changing a setting are logged like calls are, with a detail line naming what changed. |
| Filter and exportRead only | Filter the log by successes, errors, or denials, and export what you are looking at as a CSV. |
On top of capability gating, you can add extra limits. They are opt-in, so nothing here narrows access without you asking for it.
One switch on the Settings tab, and nothing that writes gets registered as an MCP tool, whatever you have ticked. A blocked write is missing from the agent’s tool list rather than refused when it calls. Abilities bridged from your other plugins are covered too, each judged by that plugin’s own annotation, and anything that declares neither way counts as a write and stays out.
Turning the mode on enables nothing by itself, and turning it off enables nothing either, so your selections are where you left them when you switch back. The switch is written to the audit log. New in 1.6.0.
Nine WooCommerce abilities move money or grant authority. Enabling one is not enough on its own: they stay locked until you also switch on a separate high-risk control in Settings, and that switch is itself written to the audit log.
Covers refunds, order status, order updates, customer updates, payment gateway settings, coupon creation and updates, and tax rate creation and updates. New in 1.5.0.
153 abilities ship in the plugin, and every one of them starts off. Guardrails like these tighten the ones you do enable.
Some limits are not settings you could relax. They are missing from the plugin on purpose, so no agent and no configuration can reach past them.
There is no custom transport of ours in the path. The plugin rides on WordPress standards, and your AI client connects in.
Runs on the WordPress 6.9 Abilities API and the official MCP Adapter (no custom transport).
Free on WordPress.org, no paid tier, no API key to buy, no usage limits.
Requires WordPress 6.9+ and PHP 7.4+
The same guardrails do not stop at this plugin's own abilities. When another active plugin registers WordPress abilities, you can bring them in under the same rules.
New in 1.1.0
When another active plugin registers its own WordPress abilities, this plugin can expose them as governed MCP tools, off by default and gated like everything else. It is a dynamic set that depends on the plugins you run. Every bridged ability is off by default, scoped to the connected user, capability-checked on every call, and written to the same audit log.
See how bridging worksInstall it, keep everything off, and switch on one ability at a time as you build trust. The guardrails hold on every call, not just the first.
Least privilege by default. Every call capability-checked and logged.