Version 1.7.0 of Agent Abilities for MCP adds an Enable all writes button next to the existing Enable all reads button on every Abilities tab section. Read that as a convenience feature and you would miss the actual design decision. A bulk-enable button on a plugin built around off by default and least privilege is worth being suspicious of, and the interesting part of this one is not what it turns on. It is what it refuses to.
What does the Enable all writes button turn on?
It ticks every ordinary write ability in a section, the same way Enable all reads ticks every read. It leaves every delete ability unticked, and it leaves every high-risk ability locked, whether or not you have already unlocked the high-risk switch in Settings.
Why a bulk-enable button needed a design decision at all
Agent Abilities for MCP ships with 153 abilities, and every one of them starts off. Turning on a whole category of behavior with one click looks, on its face, like the opposite of that posture. It only stays consistent with it because the button was scoped before it shipped, not after.
| What Enable all writes touches | What happens |
|---|---|
| An ordinary write, such as updating a post | Turned on |
| A delete ability, such as deleting a post | Left exactly as it was, still needs its own switch |
| A high-risk ability (the nine WooCommerce abilities that move money or grant authority) | Left locked, the separate high-risk switch in Settings still has to be turned on first |
An “enable everything” button that actually enabled everything would undo the point of a catalog that starts off. Agent Abilities for MCP’s Enable all writes button ticks the ordinary writes in a section and stops there, on purpose, leaving deletes and high-risk abilities exactly where you left them.
The three outcomes look like this on a real Abilities tab section:
Deletes stay out of the bulk action because a delete is still a delete, even the ones WordPress sends to Trash first and can restore. High-risk abilities stay out because they cover the nine WooCommerce abilities that move money or grant authority, refunds, order status, payment gateway settings, coupons, and tax rates, and enabling one of those has always needed two separate decisions, not one. Enable all writes does not get to shortcut either decision.
The fuller audit log
The audit log also does more in 1.7.0, on the two paths that mattered most: permanent deletes, and a handful of writes that were recording that something changed without saying what.
Before 1.7.0, nine of the plugin’s thirteen abilities that permanently delete something wrote a blank detail column in the log when they ran. The row said a delete happened. It did not say what was deleted. Every one of those thirteen abilities now records what it removed, an id, a slug, an identifying detail, the same kind of identifier-only note the log has always kept, never the object’s own free-text content.
Three more abilities gained the same kind of detail on the write side. Updating a term’s meta, a user’s meta, or a site setting now names the specific key it wrote, rather than logging that an update happened with no further detail. If you review the log to see what an agent actually did on your site, these are exactly the rows that used to make you go check the database yourself.
A small addition: a review-request notice
1.7.0 also adds an admin notice that asks for a wordpress.org review once the plugin has been carrying traffic on your site for a while. It is dismissible for good, and it still works with JavaScript off.
What 1.7.0 does not change
No ability was added, removed, or renamed. The catalog is still 153: 83 core abilities plus 70 across the WooCommerce, ACF, Rank Math, Yoast, and All in One SEO integrations. Nothing about who can call what changed either, only how much of what you have already unlocked you can switch on in one click, and how much detail the log keeps once you do.
1.7.0 also carries a run of correctness fixes: an OAuth revocation race, a payment gateway credential leak, and four ACF writes that were destroying content while reporting failure. Those are covered in what we fixed in the 1.7.0 correctness release. Two refusals that named the wrong cause got fixed the same release, covered separately in what we fixed: setting alt text said permission denied, for everyone. For the release before this one, see what we fixed in the 1.6.2 hardening release. The current catalog and safety controls are on the features and security pages.