First release.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3675125,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3675125,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3675125,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3675125,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.0"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3675125,"resolution":"1","location":"assets","locale":"","width":2508,"height":1106},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3675125,"resolution":"2","location":"assets","locale":"","width":2592,"height":1186},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3675125,"resolution":"3","location":"assets","locale":"","width":2538,"height":1114},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3675125,"resolution":"4","location":"assets","locale":"","width":2618,"height":1118},"screenshot-5.png":{"filename":"screenshot-5.png","revision":3675125,"resolution":"5","location":"assets","locale":"","width":2578,"height":1186},"screenshot-6.png":{"filename":"screenshot-6.png","revision":3675125,"resolution":"6","location":"assets","locale":"","width":2598,"height":1438}},"screenshots":{"1":"The abilities list. Every registered ability, from any MCP plugin, labelled by what it actually does \u2014 read, write or remove \u2014 with a per-ability rule: always allow, require approval (naming who signs off), or block.","2":"The approval queue, seen by someone who is not an approver for this request. A removal is held with its proposed arguments shown; the Approve button is disabled and explains why.","3":"The same held request, seen by an approver \u2014 one click applies it or rejects it. Nothing has touched the site while it waits.","4":"The audit log: every governed call \u2014 allowed, queued, blocked or reverted \u2014 with the caller, the outcome, and exactly what changed. (Change history and one-click undo are part of the Pro add-on.)","5":"Undo in action: an applied change reverted from the log, the original row marked \"reverted\", and the undo itself recorded. (Pro add-on.)","6":"Settings. Everything runs and is recorded by default; the gate is opt-in. A single \"hold removals\" switch holds every delete, plus learning mode, holding unidentifiable callers, and request expiry."}},"plugin_section":[],"plugin_tags":[251511,2353,8196,242115,253991],"plugin_category":[],"plugin_contributors":[278557],"plugin_business_model":[],"class_list":["post-355766","plugin","type-plugin","status-publish","hentry","plugin_tags-abilities","plugin_tags-ai","plugin_tags-approval","plugin_tags-mcp","plugin_tags-model-context-protocol","plugin_contributors-kevinplugins","plugin_committers-kevinplugins"],"banners":{"banner":"https:\/\/ps.w.org\/kevinplugins-mcp-abilities-guard\/assets\/banner-772x250.png?rev=3675125","banner_2x":"https:\/\/ps.w.org\/kevinplugins-mcp-abilities-guard\/assets\/banner-1544x500.png?rev=3675125","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/kevinplugins-mcp-abilities-guard\/assets\/icon-128x128.png?rev=3675125","icon_2x":"https:\/\/ps.w.org\/kevinplugins-mcp-abilities-guard\/assets\/icon-256x256.png?rev=3675125","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/kevinplugins-mcp-abilities-guard\/assets\/screenshot-1.png?rev=3675125","caption":"The abilities list. Every registered ability, from any MCP plugin, labelled by what it actually does \u2014 read, write or remove \u2014 with a per-ability rule: always allow, require approval (naming who signs off), or block."},{"src":"https:\/\/ps.w.org\/kevinplugins-mcp-abilities-guard\/assets\/screenshot-2.png?rev=3675125","caption":"The approval queue, seen by someone who is not an approver for this request. A removal is held with its proposed arguments shown; the Approve button is disabled and explains why."},{"src":"https:\/\/ps.w.org\/kevinplugins-mcp-abilities-guard\/assets\/screenshot-3.png?rev=3675125","caption":"The same held request, seen by an approver \u2014 one click applies it or rejects it. Nothing has touched the site while it waits."},{"src":"https:\/\/ps.w.org\/kevinplugins-mcp-abilities-guard\/assets\/screenshot-4.png?rev=3675125","caption":"The audit log: every governed call \u2014 allowed, queued, blocked or reverted \u2014 with the caller, the outcome, and exactly what changed. (Change history and one-click undo are part of the Pro add-on.)"},{"src":"https:\/\/ps.w.org\/kevinplugins-mcp-abilities-guard\/assets\/screenshot-5.png?rev=3675125","caption":"Undo in action: an applied change reverted from the log, the original row marked \"reverted\", and the undo itself recorded. (Pro add-on.)"},{"src":"https:\/\/ps.w.org\/kevinplugins-mcp-abilities-guard\/assets\/screenshot-6.png?rev=3675125","caption":"Settings. Everything runs and is recorded by default; the gate is opt-in. A single \"hold removals\" switch holds every delete, plus learning mode, holding unidentifiable callers, and request expiry."}],"raw_content":"\n
MCP plugins let an AI agent act on your site. Whichever one you use, the result is the same: a model connected in Claude, Cursor or Codex can create posts, edit content, change settings and delete things, and by default nothing stands between the model deciding and WordPress doing.<\/p>\n\n
MCP Abilities Guard lets you govern every ability an AI agent can call. For each one you can set:<\/p>\n\n
By default, everything runs and is recorded \u2014 the gate is opt-in. You decide what to hold: set a rule on a particular ability to require approval or block it, or flip a single switch to hold every delete across the site. Nothing is held until you ask for it, so the plugin never quietly breaks an agent workflow you did not choose to stop.<\/p>\n\n
The Hold removals<\/strong> switch is the one most sites will want: one click, and every delete \u2014 posts, users, options, whole tables \u2014 waits for approval, including deletes hidden inside an ability whose code cannot be read (once it is seen deleting, it is caught from then on). A removal is the write worth this treatment, because once it runs the site no longer has what was there to put back.<\/p>\n\n You do not need the ability's author to have built any of this. The guard attaches as abilities are registered, so it covers plugins that have never heard of it.<\/p>\n\n There are many MCP server plugins now, each with its own endpoint, its own authentication and its own way of exposing tools. This plugin is not tied to any of them.<\/p>\n\n Abilities are guarded at the moment WordPress registers them, so a rule applies no matter which server later exposes that ability. And because MCP is a standard protocol, tool calls are recognised by their shape rather than by any plugin's URL \u2014 so a call is inspected the same way whether it arrives through one MCP plugin, another, or one released next year.<\/p>\n\n That matters more than it sounds. Several MCP plugins register abilities and<\/em> run their own server that calls the underlying code directly. Guard only the ability, and a rule you set looks armed while the agent's actual route sails past it. This plugin watches both, so the rule holds whichever way the call comes in.<\/p>\n\n Most tools guess from an ability's name, or trust whatever its author declared. Both are wrong often enough to matter \u2014 an ability called 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<\/strong> 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.<\/p>\n\n Out of the box, nothing is held \u2014 every call runs and is recorded, and you choose what to gate. There are two ways to choose.<\/p>\n\n The first is per ability: on the Abilities screen, set any ability to require approval<\/em> or always reject<\/em>. Use this for the specific tools you want a person to see \u2014 a \"mail every subscriber\" action, a bulk importer, anything you would rather confirm.<\/p>\n\n The second is the Hold removals<\/strong> 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 \u2014 the gate is opt-in \u2014 and most sites will want it on.<\/p>\n\n 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.<\/p>\n\n 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.<\/p>\n\n 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 \u2014 a real before and after, read from your database at the moment you are looking at it.<\/p>\n\n 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.<\/p>\n\n 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<\/a>.<\/p>\n\n Nothing here degrades without it. The gate, the approvals, the previews and the record of decisions are complete on their own.<\/p>\n\n 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:<\/p>\n\n 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<\/a>.<\/p>\n\nIt works with whichever MCP plugin you use<\/h4>\n\n
How it decides what an ability does<\/h4>\n\n
get_report<\/code> can still send email. This plugin prefers evidence, strongest first:<\/p>\n\n\n
What is held, and when<\/h4>\n\n
What a held request looks like<\/h4>\n\n
Seeing the change before you allow it<\/h4>\n\n
Undoing what already happened<\/h4>\n\n
MCP Abilities Guard Pro<\/h4>\n\n
\n
What this plugin does<\/h4>\n\n
\n
What this plugin does not do<\/h4>\n\n
\n
Requirements<\/h4>\n\n