AcrossAI Abilities Manager – WordPress Abilities for Claude, ChatGPT & Any AI Agent

Changelog

Unreleased

(nothing yet)

0.0.40 – 2026-09-28

• Fixed: the plugin’s Description was being truncated on WordPress.org. Every import reported “The Description section is too long and was truncated. A maximum of 2,500 words is supported” — a warning only the plugin’s committers can see, so the listing was silently losing its tail for anyone reading it. The cause was not obvious: the Description itself was well inside the limit at around 1,800 words, but WordPress.org folds sections it does not recognise into the Description, and this readme carries two of them — External Services and Privacy Policy, both required disclosures totalling another 750. Together they crossed the limit. The Description is now tightened to 2,372 effective words with every point kept, leaving room for the next few releases, and neither disclosure was touched.
• The WordPress.org listing title now says what the plugin does. It read “AcrossAI Abilities Manager”, which tells a search engine nothing, while the sibling plugins carry a descriptive title. It is now “AcrossAI Abilities Manager – WordPress Abilities for Claude, ChatGPT & Any AI Agent”. The name shown inside wp-admin is unchanged. The tags move from abilities, mcp, access control, site management, ai to abilities, ai assistant, chatgpt, claude, mcp — the terms people actually search, with abilities kept because it is the one word that distinguishes this plugin from an MCP server.
• The listing no longer counts toolsets as this plugin’s feature. It led with “357 ready-made WordPress abilities across 14 toolsets” and explained the toolset dispatch model as something this plugin gives you. That attribution is wrong: AcrossAI MCP Manager owns the toolset layer now. The counts of abilities stay, because those are what this plugin ships; the counts of toolsets are gone, and the explanation of why an AI sees a dozen tools instead of hundreds now credits the MCP server for the grouping. The per-plugin toolsets — Elementor, Rank Math, Site Kit, UpdraftPlus, All-in-One and the rest — are still described here, because they still come from this plugin and MCP Manager deliberately does not carry them. Nothing about the code changed in this release.
• Tested up to WordPress 7.1, and the plugin’s own one-line description rewritten. The header still described this as a way to “manage and customize the abilities of AcrossAI … tailor the AI’s capabilities”, which is what an AI settings panel does, not a plugin that ships 357 abilities. That line is what WordPress shows under the plugin name in wp-admin, so it now says what you actually get.
• The listing now says plainly that this works with any Abilities API consumer, not just one MCP server. Every ability here is registered through WordPress 6.9’s own Abilities API, so anything that reads that API can expose them — AcrossAI MCP Manager, the WordPress MCP Adapter, another MCP server, a REST client, or a plugin calling the Abilities API directly. That was previously one clause at the end of a paragraph; it is now three named routes and an explicit statement that nothing here is proprietary or bound to a particular transport.
• The integration list is shorter, because each entry now links to its own page. Every integration gained a link in 0.0.39; the inline paragraph describing each one was then saying what the linked page says at length. Each is now a single line naming the area it covers.

Verified: the Description parses at 2,372 of 2,500 words with the two unrecognised sections folded in, as WordPress.org counts them.

0.0.39 – 2026-09-28

• Fixed: asking All-in-One WP Migration for a backup told you to install UpdraftPlus. The All-in-One abilities detect their plugin correctly, but when it was missing they reported the failure using UpdraftPlus’s error code and UpdraftPlus’s message. So calling all-in-one/get-status on a site without All-in-One named the wrong plugin — and following that advice installed the wrong plugin, after which the ability still failed. Worse for anything automated, both suites returned the same updraftplus_missing code, so a caller checking which plugin was absent could not tell them apart, which is the one question a typed error code exists to answer. All-in-One now returns all_in_one_missing and a message about its own archives and exports. Every guard in the plugin is now checked for a shared code, so this cannot recur quietly.
• Rank Math SEO scores now record where they came from and when. Rank Math stores a score as a bare number, so nothing distinguished a score its own browser analyzer wrote months ago from one an AI client worked out this morning — and “are these scores current?” had no answer. rank-math/update-seo-scores now stamps each score it writes with a timestamp and a source, and takes a new optional source: agent (the default, meaning an AI client graded the post against the rubric Rank Math’s own rank-math/analyze-post-content hands out) or rank-math-analyzer (a number Rank Math’s client-side analyzer produced). The two do not always agree, and saying which one you have is the point. rank-math/audit-content-seo reports both back as seo_score_at and seo_score_source. Scores Rank Math wrote itself report null for both, which is the honest answer rather than a guess. Nothing about the score itself changes, and the existing single-argument call still works.
• rank-math/audit-content-seo can now audit an exact list of posts. It could sweep a post type or search for text, but there was no way to ask about five specific posts — which is exactly what you need before and after changing them. Pass post_ids and it reports on those posts, in the order you gave, all in one response. Because naming ids means naming the posts, it also stops applying the post/page and published-only defaults that would quietly drop a draft or a custom post type and leave it looking like it did not exist, and it lists healthy posts alongside problem ones instead of returning a shorter list with no explanation. Passing post_types, post_statuses or only_issues yourself still overrides all of that, and a sweep with no post_ids behaves exactly as before.

Verified against Rank Math 1.0.278.
* New: a Site Kit by Google toolset — 11 abilities under site-kit/*. Site Kit connects a WordPress site to Search Console, Analytics 4, PageSpeed Insights, AdSense and Tag Manager, and until now none of that was reachable. site-kit/get-status reports whether Site Kit is set up, whether the WordPress user making the call has connected their own Google account, which account that is, and what to do next. site-kit/list-modules, site-kit/get-module-settings, site-kit/set-module-state, site-kit/get-sharing-settings and site-kit/list-module-datapoints cover the modules — which are on, which are fully configured, which Google property each points at, and who can see the data. site-kit/get-search-analytics reads Search Console clicks, impressions, CTR and position by query, page, country, device or date; site-kit/get-analytics-report runs GA4 reports; site-kit/get-pagespeed-insights runs Lighthouse; site-kit/get-adsense-report reads earnings. site-kit/get-module-data reaches any read datapoint the named abilities do not cover. Everything is read through Site Kit’s own module clients, so no request shape is reimplemented and no Google credential is ever returned. The toolset appears only when Site Kit is active, and like Rank Math’s it is not in a new MCP server’s default set — add it by hand or reach it through Integrations.
* Site Kit abilities say whose problem it is when there is no data. Site Kit stores one Google token per WordPress user, so an administrator on a fully configured site can still see nothing because a colleague did the connecting. Four situations that all look like “no data” — Site Kit not set up, this user not connected, the module switched off, the module on but missing its property settings — each get their own error code and their own sentence naming who must do what. Search Console returning zero rows is reported as the ordinary result it usually is, with the two-day reporting lag named, rather than as a failure.
* PageSpeed Insights returns a summary, not half a megabyte. Google’s raw Lighthouse response for one page measured 529 KB — 199 KB of it a base64 screenshot no assistant can display, and 315 KB of audit detail tables — which overflowed the reply before any of it could be read. site-kit/get-pagespeed-insights now returns the category scores as percentages, the Core Web Vitals, any real-user field data Google holds for the URL, and just the audits that failed. Pass detail: "audits" for every audit’s score without its tables, or detail: "full" for Google’s whole response. The screenshot is dropped at every level. The ability also now says up front that a run takes ten to sixty seconds and can outlast a client’s request timeout.
* Site Kit settings can now be changed, not just read. The suite could report that a site sends its analytics to one Google property but could do nothing about it. site-kit/update-module-settings writes them: which Analytics 4 property and measurement ID the site reports to, which Search Console property it reads, which Tag Manager container it uses, whether each module places its snippet, and who is excluded from tracking. Send only the keys you want changed. A key the module does not have is named back to you rather than silently dropped, which is what Site Kit’s own writer does and the reason a typo used to look like success. The response reports each key’s old and new value read back after the write, because every module runs its own sanitiser and what you asked for is not always what got stored. Confirm-gated, since switching a snippet off stops measurement on the live site immediately.
* Changing a Site Kit connection setting moves who owns the module — and now says so. Site Kit silently reassigns a module’s owner to whoever changes its property or account, and that owner’s Google credentials are what serve the module’s data to everyone reading a shared dashboard. The write reports when that happened instead of leaving it to be discovered. ownerID itself cannot be written by hand, and neither can any credential key — an ability that hides secrets on read should not let you set one.
* New: read and change your Site Kit Key Metrics. The row of tiles at the top of the Site Kit dashboard — new visitors, most popular content, top traffic source — was invisible here. site-kit/get-key-metrics reports which tiles the current user has chosen, whether the row is hidden, and who set it up for the site; site-kit/update-key-metrics changes them. The selection is stored per WordPress user, so both describe and change only the dashboard of the user making the call. The slug list lives in Site Kit’s JavaScript and grows with ordinary releases, so an unrecognised tile is saved and flagged rather than refused — refusing would break on exactly the tiles a newer Site Kit just added. Not confirm-gated: it moves tiles on one admin screen and touches neither the site nor its measurement.

Verified against Site Kit by Google 1.188.0 on a live site with Search Console, Analytics 4, Tag Manager and PageSpeed Insights connected.
* The 27 Elementor design audits now actually examine the page. They were registered and callable, but the analysis inside each was never written: they returned a made-up score with no findings, wrapped in “Ran audit: …” and a claim to be grounded in Elementor’s official documentation. On a test page built as four identical 50/50 sections carrying the same button, audit-generic-layout-patterns used to answer 100 out of 100. It now answers 46, and names the three reasons — four repeated 50/50 rows, every row splitting evenly, and a stock split hero opening the page. All 27 are implemented against a shared model of the document, so every audit means the same thing by a row, a lane and a ratio.
* The eleven design fixes now change the page, and say exactly what they changed. Each one is confirm-gated, writes through a single audited path, and returns every setting it touched with its previous value so a change can be put back by hand. Running one twice changes nothing the second time and does not re-save. The image-to-background conversion hides the original widget rather than deleting it, because that judgement is one you may want to reverse.
* Fixed: elementor/evaluate-design failed on every call, on every site. It returned two fields its own output schema did not declare, and the schema forbids undeclared fields, so it errored every time it was used — it had never worked. The same fault was then found in the individual audits, which return their evidence under a field the schema also did not declare. Both are fixed and both are now pinned by tests.
* elementor/evaluate-design composes the audits it is supposed to. Its registry was only ever filled in by the test suite, so on a real site it aggregated nothing — a separate fault from the skeletons, and one that fixing them would not have touched. Audits now enrol themselves, and the aggregate reports 16 running on a typical page. The mutating abilities deliberately do not enrol: an aggregate that rewrote the document as a side effect of being asked a question would be indefensible.
* Fixed a false positive found by building a good page rather than a bad one. The native-widget audit counted icon elements across a whole row, so the standard three-up feature grid — one icon box per column — was told to become an Icon List, which is a vertical list inside a single column and not the same thing at all. It now counts within each column. Advice that is wrong about correct work is how a tool teaches people to ignore it.
* The aggregate score now says what it is. It is a mean across audits, so audits finding nothing pull it up and a page with real problems can still read in the eighties. The response now carries that caveat and the lowest individual score alongside the average, so the number is read rather than trusted.

0.0.38 – 2026-09-22

• Fixed: a toolset that happened to be empty disappeared from the tool list, and could never come back. An AI assistant is handed its list of tools once, when it connects, and there is no way to hand it a new one. A toolset holding nothing was left off that list — so on a site where every ability already had a home, the Other toolset was missing, the Tools tab said fourteen while the assistant was served thirteen, and reconnecting did not help because it was still empty at that moment. The built-in toolsets are now always offered, empty or not; calling an empty one answers with a message rather than an error. Toolsets belonging to a specific plugin are unchanged: they still appear only when their plugin is there, and the Integrations toolset still reaches them either way.
• Fixed: the Integrations toolset could disappear too — the one thing that should never have. Integrations exists so an assistant can reach a plugin installed after it connected. Its contents come only from plugin toolsets, so on a site with none active it was empty and therefore absent, exactly when it was most needed. It is now always present.
• Integrations and Other now say that their contents change. Both fill and empty as plugins and themes are activated, so an assistant that asked once and remembered the answer was wrong from the next activation onwards with nothing to tell it. Their listings now carry a volatile marker and a note to ask again. An empty one says the emptiness is about this moment rather than settled.
• Fixed: Contact Form 7 mail tags written inside angle brackets were silently deleted. From: [your-name] <[your-email]> is how a From line is normally written in a plain-text mail body. Sanitising read <[your-email]> as an unknown HTML tag and removed it, taking the mail tag with it — the save reported success, and checking the template afterwards reported it valid, because the tag that would have been flagged was gone. The tag survives now. Sanitising itself is unchanged and still removes real HTML; only this one shape, a bare mail tag between angle brackets, is let through. Updating a mail template also now names any field whose stored content was altered, so nothing is dropped quietly again.
• Fixed: a Contact Form 7 field option containing a space became several options. Contact Form 7 splits a field tag on spaces, so placeholder:+44 7700 900000 arrived as three separate options and the field ended up with a placeholder of +44. Option values are now quoted the way choice values always were. An option with a space and no key: in front of it cannot be repaired, so it is refused with the offending text named rather than silently mangled.
• Fixed: the Contact Form 7 field-type list advertised syntax that does not work. Contact Form 7 registers text and text* as separate types, and the list appended an asterisk to each — producing a duplicate row for every type and the string text**, which Contact Form 7 does not understand. There is now one row per type, showing a required form only where one genuinely exists: submit and the captcha fields have none. The list goes from 35 entries to 24.
• Creating a Contact Form 7 form now accepts template, the name the other template abilities already use. Creating a form called the markup form while reading and replacing it called the same thing template, so anything that learned one name was rejected by the next. template works everywhere now, and form still works for anything already using it.
• Enabling a Contact Form 7 autoresponder now warns when it would send to nobody. A form whose fields were rewritten keeps Contact Form 7’s stock autoresponder, which is addressed to [your-email] — on a form without that field the reply goes nowhere, and the visitor still sees a success message. Switching the autoresponder on now reports any mail tag in it that matches no field, so the problem is visible at the moment it is created.

0.0.37 – 2026-09-21

• Fixed: the UpdraftPlus and All-in-One WP Migration tools were offered on sites without those plugins. Both appeared in an MCP server’s tool picker, and in the set a new server starts with, whether or not the backup plugin was anywhere on the site. Every other per-plugin toolset — Elementor, Rank Math, LiteSpeed — already excluded itself; these two, added in 0.0.35, did not. The tools themselves were never broken: they are still registered when their plugin is active, still addable by hand, and still reachable through the Integrations toolset. What changes is that they are no longer part of what a new server is given by default. If a server already has one and the plugin is not installed, “Reset to Type Defaults” clears it.

0.0.36 – 2026-09-21

• Listing posts no longer forces you to download every body. content/list-posts, content/list-pages and content/list-cpt-items returned every field of every item including the whole post_content — ten posts came to about 172 KB when almost all of it was content nobody had asked for yet. Pass fields: "summary" to get just what identifies an item: title, status, dates, slug, author, a trimmed excerpt, and content_bytes so you can size the follow-up read. Measured at 36-39x smaller. The default is unchanged, so nothing existing sees a difference.
• Fixed: the block outline reported the wrong total. Asking for 3 blocks of a 40-block post reported total: 3 — it counted what it returned rather than what matched, because it stopped walking the moment it had enough. It now reports total: 40 with a new returned: 3 alongside, so you can tell a small post from a truncated view of a large one. Each block also reports subtree_bytes next to bytes, which distinguishes a genuinely small block from a small wrapper around half the page.
• Site Health results can now be read as text. The description and actions fields carry WordPress core’s own markup — paragraph tags, icon spans that render as pictures and read as nothing, and screen-reader spans that repeat every link’s text. Pass format: "text" for plain sentences with the link destinations kept. The default still returns the markup unchanged.
• Every ability now has to say whether it reads, destroys, or can be repeated. Those three flags are how an AI client decides whether something is safe to try, safe to retry, and safe to run without asking, and a missing one reads as “not destructive” — the dangerous way to be wrong. Abilities missing them are now caught by the test suite, and reported on screen while WP_DEBUG is on. Nothing changes on a production site.
• The transient and object-cache abilities now point at the page cache when there is one. Clearing transients is not what a visitor sees. On a site running LiteSpeed, these abilities now suggest litespeed/purge-cache for that — and say nothing on sites without it, rather than naming an ability that is not there.

0.0.35 – 2026-09-21

• The backup abilities are now two tabs, one per plugin. UpdraftPlus and All-in-One WP Migration each get their own tab, their own toolset and their own abilities, the same way Elementor, Rank Math, WPCode and every other integration works. 0.0.34 shipped them as a single “Backups” tab that reached both plugins through a shared layer; that made two genuinely different plugins look interchangeable and turned every real difference into a flag you had to go and check.
• Each suite now offers only what its plugin can actually do. UpdraftPlus schedules backups and restores them, and stores no label – so it has no label ability. All-in-One labels its archives, and restoring belongs to their paid Unlimited Extension – so that ability asks the plugin and passes its own answer back, naming the manual import route, rather than refusing on its behalf.
• Breaking: the backups/* abilities are gone. They are replaced by updraftplus/* and all-in-one/*. Anything holding a backups/ slug needs updating; there are no aliases. The suite was one release old.
• Fixed: restoring never worked outside the admin screens. The restore checked whether WordPress could write to the filesystem directly – the check that stops a restore dying half-way through – using a function WordPress only loads inside wp-admin. Every restore request therefore failed on that line before checking anything, whatever it was asked to do. This shipped in 0.0.34 and is fixed here.
• The exposure check is shared and reports per plugin. Whether the web server will hand out a backup archive has nothing to do with which plugin wrote it, so that logic exists once – but each tab now reports on its own storage rather than on everything at once.

0.0.34 – 2026-09-18

The largest release so far: 25 features, 19 new tabs and around 400 new abilities. The theme is reach and honesty – most of the popular plugins a site actually runs can now be driven directly, each behind this plugin’s own permission floor, and every ability that cannot do something says why and names the route that works instead.

Breaking changes

• Abilities now require administrator rights unless you say otherwise. If anyone below administrator drives this site through an AI client – a shop manager running a store, for example – they lose access on update until an administrator grants it. Set a rule on the individual ability under User Access, or move the site-wide floor with the acrossai_default_ability_capability filter.
• Why: every plugin chose its own lock, and nobody was checking them. Measured across the abilities installed on one site: three registered with no permission check at all, two were open to any logged-in subscriber, and one that writes content was open at contributor level. This plugin now decides who may run an ability, whoever registered it.
• Setting access used to be able to remove the lock. Choosing “Everyone” on an ability replaced its built-in check with one that allowed anybody – an action that reads as tightening actually opened the door. Access rules now sit on top of a floor that cannot be removed by accident.

New tabs

• Store (WooCommerce) – 34 abilities. The catalogue, pricing, stock, orders, customers, coupons, tax, shipping and store settings, plus WooCommerce’s own seven adopted into the same tab. Variable products can now be created at all, which WooCommerce’s own abilities cannot do.
• Backups – 9 abilities. Whether this site can be recovered: what exists, when it last ran and whether it worked, whether the archives are reachable over HTTP, and taking, labelling, deleting or restoring one. Works with UpdraftPlus and All-in-One WP Migration through one set of abilities.
• Yoast SEO – 64 abilities, and Yoast’s own two now have a home.
• LiteSpeed Cache – 61 abilities.
• Contact Form 7 – 25 abilities, and WPForms’ own abilities now have a home with an off switch for form writing.
• WPCode – 24 abilities, adopting the five WPCode already had.
• Cookie Consent – 22 abilities, with an honest account gate rather than silent failure.
• The Events Calendar – 18 abilities and Event Tickets – 16, with capacity modelled and personal data gated.
• Advanced Custom Fields – 16 abilities, joining the existing ACF tab.
• Translations – 14 abilities.
• Email Delivery – 4 abilities, plus a home for the ones the mail plugin ships, and Akismet’s own abilities adopted.
• Classic Editor – 4 abilities for what nothing else can reach.

Safety

• Fixed: editing a WooCommerce product or order through the generic content tools silently corrupted the store. Writing a price through content/update-cpt-item left the price the shop actually charges on the old value, and saving the product correctly afterwards did not repair it. Orders were worse: WooCommerce no longer keeps them in the posts table, so the write changed a row nothing reads and was later deleted. Both are now refused, naming the ability that does work.
• A backup archive that anyone can download is a total compromise, and this now checks for it. Both backup plugins drop a .htaccess to prevent it; on nginx, IIS and Caddy that file is never read, so the protection is present, looks correct, and does nothing.
• Restoring says plainly that it cannot be undone, and records what the site looked like beforehand so what was given up is visible.

The abilities screen

• Integration tabs are now named after the plugin they drive, and abilities registered by other plugins now belong to a toolset instead of vanishing into a catch-all.
• One screen, one access model. The registration gate is gone; tabs were regrouped into task groups, and deep links to retired tabs fall back to “All”.
• Fixed: WPCode’s own five abilities were never actually adopted into its tab – the prefix could not match.

For the complete detail of this release – all 156 entries – and the full history of every earlier release, see changelog.txt inside the plugin, or
https://github.com/acrossaico/acrossai-abilities-manager/blob/main/changelog.txt

0.0.33 – 2026-08-28

Release theme: closing the cheap-edit loop. A follow-up to 0.0.32 that closes the last two gaps between “locate a block cheaply” and “modify it cheaply”. Two changes, both surgical and backwards-compatible.

return_content:false default now covers the two block-tree writers. blocks/add-block and blocks/update-post-block gain the same return_content:{boolean, default:false} input as the six content writers (PR #152) and nine block-editor writers (PR #153). When false (default), the response’s block object strips its innerHTML, innerContent, and innerBlocks — leaving blockName, attrs, and path — and content_bytes reports the saved innerHTML size. Container blocks (columns, cover, group) previously echoed their entire innerBlocks subtree; now they don’t unless the caller passes return_content:true. BREAKING for callers reading response.block.innerHTML on these two abilities — pass return_content:true explicitly. Every other block-tree read/write (mutate-block-tree, replace-block-text, remove-block, duplicate-block, move-block) already returned lightweight envelopes and is unchanged.

blocks/get-post-blocks gains scoping inputs. Three new optional inputs close the “read one block’s markup” gap between blocks/get-post-blocks (full tree, full content) and blocks/outline-post-blocks (scoped but never returns content). path: int[] scopes the response to a subtree (uses the same raw parse_blocks() index scheme as add-block / update-post-block / remove-block, so returned paths interchange). depth: integer bounds descent below the subtree root (-1 unlimited, 0 subtree root only, N below). include_html: boolean (default true = backwards-compat) strips innerHTML + innerContent from every returned node when false. Backwards-compatible: existing callers passing only post_id see identical responses. An unresolvable path returns a standard error envelope with error_code: invalid_path naming which depth failed and how many blocks exist at that level.

Earlier releases

Every release before 0.0.33 is recorded in full at https://acrossai.co/changelog/acrossai-abilities-manager/ and in changelog.txt, shipped inside the plugin.