MCP Abilities Guard – Allow, reject, or hold for approval — or undo — any MCP action

How it decides what an ability does

Most tools guess from an ability’s name, or trust whatever its author declared. Both are wrong often enough to matter — an ability called get_report can still send email. This plugin prefers evidence, strongest first:

1. 01Watching it run. While an ability executes, the plugin records what it touches: posts, pages, options, users, terms, comments, and writes to any plugin’s own tables. Seen reading and never writing, it earns read-only status.
2. 02Reading its code. Before an ability has ever run, its callback is inspected for database writes, outbound requests and file changes. This catches a write on the first call rather than the second.
3. 03Its declared annotation. A read-only claim is taken only as a hint. A claim of being destructive , though, is believed and the ability is held — that admission costs its author access, which is why it is worth trusting.
4. 04Its name. The weakest signal, used last, and never enough on its own to auto-allow.

Every row in the admin list shows which of these produced its classification, so you always know whether you are reading a verified result or an assumption. When nothing can be determined the plugin says unknown rather than guessing. An unknown ordinary call still runs; an unknown removal or outbound effect is held, since those are the ones worth stopping when in doubt.

What is held, and when

Out of the box, nothing is held — every call runs and is recorded, and you choose what to gate. There are two ways to choose.

The first is per ability: on the Abilities screen, set any ability to require approval or always reject . Use this for the specific tools you want a person to see — a “mail every subscriber” action, a bulk importer, anything you would rather confirm.

The second is the Hold removals switch in Settings: one toggle that holds every delete at once, including deletes caught only by watching an ability run. A removal is the one write worth a blanket rule, because its “before” is gone the instant it runs and there is nothing to undo afterwards. It is off by default — the gate is opt-in — and most sites will want it on.

What a held request looks like

Nothing has changed yet. The call is queued, and the agent receives a clear message: approval is pending, do not retry, and do not attempt the same change another way. It can check the outcome later through an ability provided for that purpose, so it waits rather than looking for a way around.

You review it in wp-admin, with the arguments the agent proposed. Values that look sensitive are redacted. Approve and it runs; reject and it never does.

Seeing the change before you allow it

A held request is not a name and a shrug. Where the target can be resolved, the review screen shows the object’s current values against what the agent proposes — a real before and after, read from your database at the moment you are looking at it.

Where that is not possible the screen says so rather than dressing up a guess. A reviewer who believes they are reading a verified diff when they are reading the arguments is worse off than one who knows which they have.

Undoing what already happened

This plugin records that a call happened, who made it, how it was decided and what it touched. Putting a change back is a different problem: it needs every affected object’s previous state kept, which is storage a site that only wants the gate has no reason to pay for. That, with the full before-and-after history, is MCP Abilities Guard Pro .

Nothing here degrades without it. The gate, the approvals, the previews and the record of decisions are complete on their own.

MCP Abilities Guard Pro

The free plugin decides what may happen and keeps an honest record that it did. The Pro add-on adds what it takes to see and unwind what already happened:

• Full change history. A before-and-after image of every write an agent made — posts, options, users, terms, comments, metadata, and writes to any plugin’s own tables — described in plain language and kept for as long as you choose.
• One-click undo. Revert any recorded change straight from the log, restoring the object to exactly what it was. This includes raw SQL writes to core tables that fire no WordPress hook, which nothing else can put back.
• Multiple approvers, with a quorum. Require several people to sign off on a held request — named users or roles — and choose whether any one of them is enough or all of them must approve. The free plugin applies a request on a single administrator’s approval.

Pro attaches to the free plugin through its own hooks: install it and the audit log gains a history and an undo button, and the approver picker gains a quorum. Remove it and the gate keeps working exactly as before. Learn more at MCP Abilities Guard Pro .

What this plugin does

• Sets every registered ability to always allow, require approval, or always reject
• Covers abilities from any plugin, without their authors doing anything
• Classifies read versus write by observation and code inspection, not naming
• One switch to hold every removal (delete) for approval — including ones caught only by watching an ability run
• Queues held calls for human review, with the proposed arguments shown and sensitive values redacted
• Keeps every held request with who asked, who answered and when — the history an approver looks back at
• Supports different rules per caller, so one agent can be trusted where another is not
• Applies a held request on a single approval from any administrator (choosing specific approvers, and requiring several — any or all — is available in the Pro add-on)
• Expires unanswered requests after a period you choose
• Learning mode: watch and classify without holding anything, so you can see the list before you set rules
• Reports coverage: which MCP tool calls it saw, and which did not map to a registered ability

What this plugin does not do

• It does not run an MCP server, transport or authentication. Those are your MCP plugin’s job.
• It does not register abilities of its own, other than one small ability that lets an agent look up whether its pending request was approved.
• It does not replace an ability’s own permission checks. Those still run. This is a layer on top, not a substitute.
• It does not govern MCP tools that were never registered as abilities. Some plugins serve tools directly without registering them; those are outside its reach, and the Coverage screen names them rather than leaving you to assume you are covered.
• It does not phone home, collect telemetry, or make any external network request.

Requirements

• WordPress 6.9 or later — the Abilities API arrived in core in 6.9
• PHP 7.4 or later
• At least one plugin that registers abilities, and usually an MCP server plugin to expose them

Source code

Development happens in the open at github.com/KevinPlugins/mcp-abilities-guard .

The admin screen is a Vue application. What runs in assets/ is the compiled bundle; the readable source it was built from ships alongside it, in the app/ directory of the plugin, together with the build configuration ( app/package.json , app/vite.config.js ). Run npm install && npm run build inside app/ to rebuild the bundle and compare it against what ships.

Privacy

Nothing leaves your site. There is no external service, no telemetry and no account. Requests, approvals and behaviour profiles are stored in your own database.

Arguments passed to abilities are stored with each queued request so a reviewer can see what was proposed. Values that look sensitive are redacted before display. Requests can be purged on a schedule you set, because those arguments may contain personal data.

About MCP

Model Context Protocol is an open specification originally developed by Anthropic. This p