Title: AcrossAI Abilities Manager – WordPress Abilities for Claude, ChatGPT & Any AI Agent Author: AcrossAI Published: Июнь 26, 2026 Last modified: Сентябрь 30, 2026 --- Search plugins ![](https://ps.w.org/acrossai-abilities-manager/assets/banner-772x250.png?rev=3614045) ![](https://ps.w.org/acrossai-abilities-manager/assets/icon.svg?rev=3595583) # AcrossAI Abilities Manager – WordPress Abilities for Claude, ChatGPT & Any AI Agent By [AcrossAI](https://profiles.wordpress.org/raftaar1191/) [Download](https://downloads.wordpress.org/plugin/acrossai-abilities-manager.0.0.41.zip) * [Details](https://os.wordpress.org/plugins/acrossai-abilities-manager/#description) * [Reviews](https://os.wordpress.org/plugins/acrossai-abilities-manager/#reviews) * [Installation](https://os.wordpress.org/plugins/acrossai-abilities-manager/#installation) * [Development](https://os.wordpress.org/plugins/acrossai-abilities-manager/#developers) [Support](https://wordpress.org/support/plugin/acrossai-abilities-manager/) ## Description **AcrossAI Abilities Manager gives your WordPress site 357 ready-made abilities, and gives you control over every one of them.** An _ability_ is a self-describing operation that WordPress 6.9’s Abilities API lets a plugin register — something an AI assistant, a REST client or another plugin can discover and call. WordPress ships the API; almost nothing ships abilities. This plugin does: **357 on any site, with no configuration**, rising to **over 800** as it detects the plugins you already run. It is free, GPL, and works on its own. Pair it with an MCP server and your site becomes something Claude, ChatGPT, Cursor or any MCP-capable assistant can operate. #### What Your Site Can Do, Out of the Box * **Content** — posts, pages and any custom post type with meta and revisions; comments; media, categories and tags; and semantic search that proposes, reviews and applies internal links. * **Blocks** — edit a page’s block tree without rewriting the page, build from patterns, generate sections and landing pages, and audit copy and design. * **Appearance** — theme.json and global styles, site-editor templates and parts, menus, widget areas, fonts, and site title, logo and icon. * **Users** — create and edit users, reset passwords, create roles, and grant or revoke individual capabilities. * **Configuration** — any option including values nested inside serialised arrays, permalinks, and which admin screen a setting lives on. * **Database** — schema and table sizes, index health, bloated autoloaded options, EXPLAIN on a slow query, table optimisation, and serialisation-safe search-and- replace. * **Files** — browse, read, write and delete inside an administrator-defined allowlist; zip backups; wp-config constants; the debug log. * **Cron** — every scheduled task, the overdue ones, running one on demand, and whether WP-Cron is firing at all. * **Updates** — plugins, themes and core; rollback; and verification against official checksums. * **Diagnostics** — Site Health, maintenance mode, recent fatal errors, and un- pausing what WordPress auto-disabled. * **Cache** — transients, object cache and rewrite rules. #### A Dozen Tools, Not 357 An AI client is handed its tool list once, at connect time, and pays for it out of the model’s context window on every conversation. Exposing 357 separate tools would flood it — most assistants degrade past a few dozen. So your MCP server groups them into **toolsets**, and a toolset is a **single tool** answering three actions: `discover` to list what it holds, `info` to read one ability’s parameters, and `execute` to run it — the same three everywhere. AcrossAI MCP Manager provides that layer; this plugin provides the abilities. #### Plugins You Already Run Get Their Own Toolset Nineteen integrations ship with the plugin, each with its own page under https:// acrossai.co/integrations/ — and each registers **only when that plugin is active**, so nothing appears for software you do not have, and each becomes one more dispatcher tool rather than a pile of loose ones. * **[Elementor](https://acrossai.co/integrations/elementor/)** (89 abilities) — pages, templates, kits, global widgets, form submissions and its cache. A Pro subset needs Elementor Pro. * **[Yoast SEO](https://acrossai.co/integrations/yoast-seo/)** (64) — titles and meta, indexing, breadcrumbs, the knowledge graph, social defaults and schema. * **[Rank Math](https://acrossai.co/integrations/rank-math/)** (61) — on-page and site-wide SEO, redirections, schema, analytics and settings. * **[LiteSpeed Cache](https://acrossai.co/integrations/litespeed-cache/)** (61)— purge by target, URL, post or taxonomy, and tune TTLs, exclusions and vary rules. * **[WooCommerce](https://acrossai.co/integrations/woocommerce/)** (34) — catalogue, prices, stock, orders, customers and store health. * **[Contact Form 7](https://acrossai.co/integrations/contact-form-7/)** (25) — forms, fields, both mail templates, tag validation and messages. * **[WPCode](https://acrossai.co/integrations/wpcode/)** (24) — snippets of every type, where each is inserted, and its conditional logic. * **[CookieYes](https://acrossai.co/integrations/cookieyes/)** (22) — declared cookies, consent categories, the banner, its languages and Google Consent Mode. * **[The Events Calendar](https://acrossai.co/integrations/the-events-calendar/)**( 18) — find, create, reschedule and trash events; manage venues and organizers. * **[Event Tickets](https://acrossai.co/integrations/event-tickets/)** (16) — tickets, real capacity including shared pools, check-ins, orders and sales. * **[Advanced Custom Fields](https://acrossai.co/integrations/advanced-custom-fields/)**( 16) — field groups, and post types and taxonomies registered through ACF. * **Site Kit by Google** (14) — Search Console analytics, Analytics 4 reports, PageSpeed Insights and AdSense, plus what is actually connected. * **[Loco Translate](https://acrossai.co/integrations/loco-translate/)** (14) — what can be translated, what is untranslated, and writing translations. * **[All-in-One WP Migration](https://acrossai.co/integrations/all-in-one-wp-migration/)**( 9) — what archives exist, how recent they are, and exporting or removing them. * **[UpdraftPlus](https://acrossai.co/integrations/updraftplus/)** (8) — when a backup last ran, whether it worked, and what each set contains. * **[WP Mail SMTP](https://acrossai.co/integrations/wp-mail-smtp/)** (4) — how the site sends mail, whether it can, and a real test send. * **[Classic Editor](https://acrossai.co/integrations/classic-editor/)** (4) — the effective editor per post type, which layer decided it, and whether users may choose. * **Akismet** — spam figures and checking a comment. These abilities come from Akismet itself. * **WPForms** — read forms and statistics, create forms, change settings. Writes sit behind an admin switch, off by default. The two backup integrations are deliberate exceptions: they register whether or not their plugin is installed, so _is this site backed up?”_ can be answered **no, there is no backup plugin here”** rather than having no tool to answer it. Third-party developers can register a toolset of their own through a filter, without touching this plugin. #### More Integrations With AcrossAI Pro The paid [AcrossAI Pro](https://acrossai.co/pricing/) add-on contributes **276 further abilities** through the same toolset mechanism, again only when the host plugin is active: * **MailerPress** (89 abilities) _(Pro)_ — campaigns, contacts, lists, tags, templates, workflows and settings. * **LearnDash** (74) _(Pro)_ — courses, lessons, quizzes, enrolment, progress, groups and reporting, plus the Certificates, Notifications and WooCommerce add- ons. * **BuddyBoss** (60) _(Pro)_ — members, groups, activity, forums, messages, media, connections and moderation. * **MailerPress Pro** (28) _(Pro)_ — segments, custom fields, webhooks, embed keys and email templates. * **GeoDirectory** (25) _(Pro)_ — listings, locations, fields, pricing packages and directory pages. Everything else on this page is free. #### Nothing Is Wide Open Every ability runs WordPress’s own capability check for the calling user, so reaching one through this plugin grants nobody anything they could not already do. On top of that: * Roughly **half the catalogue is annotated read-only** and only about **13% is flagged destructive**, so a look-but-don’t-touch surface is a matter of filtering, not trust. * Higher-risk operations require an explicit **confirmation flag** before they run. * **Search-and-replace is a dry run** unless you say otherwise, and skips post GUIDs unless asked. * File access is confined to an **administrator-defined path allowlist** — an empty write-allowlist means deny all writes” — with a dangerous-extension blocklist and a maximum write size on top. * **Secrets are redacted** — database credentials and authentication salts are stripped out of file and debug-log reads. * Database abilities never accept a raw table name; they work from a fixed allowlist of core tables. * Any ability can be **disallowed site-wide**, and one you turn off is unregistered outright rather than merely hidden. #### Full Control Over Every Ability * **Browse all abilities** — a searchable, sortable, paginated table listing every registered ability with slug, provider, source and current status. * **Toggle allow/disallow** — enable or disable any ability site-wide with a single click, saved instantly without a page reload. * **Edit ability metadata** — override `readonly`, `destructive`, `idempotent`,` show_in_rest`, `show_in_mcp`, `mcp_type` and `mcp_servers` per ability with a tri-state Yes / No / Inherit control, and reset any of it to registry defaults in one click. * **Bulk actions** — allow, disallow or reset up to 50 abilities at once. * **Ability Library** — enable or disable add-on ability groups from a dedicated page, with All/Specific mode per group. * **Add-ons page** — browse companion plugins from wp-admin; WordPress.org-hosted ones install and activate in place. Overrides live in their own table. **The ability registry is never modified** — only fields that differ from registry defaults are stored, so removing the plugin leaves it exactly as found. #### Reproduce a Plugin Conflict Without Breaking the Site **Debugging Conflict Testing** toggles any plugin’s _effective_ active state ** without ever writing to `wp_options.active_plugins`** — reproduce a conflict for one browser session, then restore the site exactly by clearing a single JSON file. Seven abilities expose the same thing to a REST client or an AI assistant, so an assistant can bisect a conflict for you. Every activation is guarded by a WordPress- core-style sandbox probe, so a fatal-erroring plugin cannot leave the site where every page load dies — the override is refused instead. #### Works With or Without an MCP Server Abilities are the capability layer, not the connection. Every one is registered through WordPress 6.9’s own Abilities API with `show_in_rest`, so it is reachable over the REST API and callable by any plugin the moment you activate this one. Nothing here is proprietary, and nothing is bound to a particular transport. That means anything which reads the Abilities API can expose these abilities — there is no lock-in: * **[AcrossAI MCP Manager](https://wordpress.org/plugins/acrossai-mcp-manager/)**— the free MCP server this plugin is built alongside. Turns the toolsets into MCP tools with per-server curation and access control. * **MCP Adapter** — the WordPress MCP Adapter exposes registered abilities as MCP tools. When it is active, this plugin also lists its servers in the ability edit panel. * **Any other consumer** — another MCP server, a REST client, or a plugin calling the Abilities API directly. Abilities registered here are ordinary WordPress abilities, not a private format. #### Requirements * WordPress **6.9 or later** — the Abilities API arrived in 6.9, and this plugin registers nothing without it * PHP **8.1 or later** * No other plugin is required #### Where To Read More * **The plugin** — https://acrossai.co/abilities-manager/ * **Every ability, searchable** — https://acrossai.co/abilities/ — one page per ability, rather than a list in a readme. * **Integrations** — https://acrossai.co/integrations/ * **Use cases** — https://acrossai.co/use-cases/ — real jobs done through an AI assistant, start to finish. * **Full changelog** — https://acrossai.co/changelog/acrossai-abilities-manager/— including releases trimmed from the Changelog here for length. ### External Services This plugin’s own code makes no external HTTP requests. Each connection below is triggered by a specific admin-only action, and is disclosed per the WordPress.org plugin directory guidelines. In every case the plugin sends no site content, user data or ability data. **1. Calendly (`calendly.com`)** — a third-party scheduling service. _When:_ never on render. The Consultations page loads no Calendly script, iframe, cookie or asset; Calendly is reached only if an administrator clicks Book a Consultation”, opening the booking page in a new tab. _Data:_ only the browser’s standard metadata (IP, User-Agent, referrer) on that click. Anything typed into Calendly’s own form is processed by Calendly; this plugin never intercepts or stores it. _Note:_ that page also references Google Fonts (`fonts.googleapis.com`), its only external asset. _Terms:_ https://calendly.com/pages/terms · _Privacy:_ https://calendly.com/pages/ privacy **2. WordPress.org plugin directory (`api.wordpress.org`, `downloads.wordpress.org`)**— installs free companion plugins from the Add-ons page. _When:_ only when an administrator with `install_plugins` clicks Install on a card sourced from WordPress.org, always through core’s own `plugins_api()` and `Plugin_Upgrader`. Add-ons hosted elsewhere render as plain links; nothing is requested from those vendors. _Data:_ core’s standard plugin-API payload — site URL, WordPress version, PHP version, locale. _Terms:_ https://wordpress.org/about/terms/ · _Privacy:_ https://wordpress.org/about/privacy/ **3. WordPress.org core version-check (`api.wordpress.org/core/version-check/1.7/`)** _When:_ only when an administrator invokes the `core/rollback-wp-core` ability and the local cache has expired — at most once per day, per locale, per site. _Data:_ core’s standard version-check payload. Same terms and privacy policy as service 2. **4. YouTube walkthrough videos (`youtube-nocookie.com`, `youtube.com`)** — short recordings embedded in the setup wizard, via YouTube’s privacy-enhanced host. _When:_ only on the wizard’s own screens, gated on the `quick-connect` parameter and loaded nowhere else in wp-admin. Two screens autoplay, so YouTube is contacted on render; the rest show a local placeholder and embed only when play is pressed. _Data:_ the browser’s standard metadata plus a `Referer` limited to the site’s origin, because a `strict-origin-when-cross-origin` policy keeps the wp-admin path private. No tracking cookies unless playback begins. _Avoiding it:_ every embed is paired with a plain link, and the wizard is optional — every screen offers Exit setup. _Terms:_ https:// www.youtube.com/t/terms · _Privacy:_ https://policies.google.com/privacy **5. GitHub (`github.com`)** — the wizard links to MCP Adapter’s latest release, which is distributed there rather than on WordPress.org. _When:_ never on render; only if an administrator clicks the link. The plugin makes no request to GitHub and downloads nothing. _Data:_ standard browser metadata only, as with any external link. _Terms:_ https://docs.github.com/site-policy/github-terms/github-terms-of- service · _Privacy:_ https://docs.github.com/site-policy/privacy-policies/github- privacy-statement ### Privacy Policy This plugin does not itself collect, store, or transmit any user data to any third party. Several admin-only actions can cause external services to receive data — all are described in the External Services section above and are triggered only by an authenticated administrator: * The AcrossAI Consultations admin page displays a static call-to-action button. Merely loading the Consultations page sends no data to Calendly — no Calendly script, iframe, or asset is loaded inside wp-admin. If the administrator clicks the CTA button, their browser opens `calendly.com/acrossai/using-ai-in-wordpress` in a new tab, at which point standard browser metadata (IP, User-Agent, referrer) is sent to Calendly and Calendly’s own privacy policy applies. If they then book a consultation on Calendly’s site, information they enter into Calendly’s form( name, email, meeting details) is transmitted to Calendly. * Installing a WordPress.org-hosted add-on from the AcrossAI Add-ons page contacts the WordPress.org plugin directory via WordPress core’s own `plugins_api()` and` Plugin_Upgrader` (`api.wordpress.org` + `downloads.wordpress.org`). Add-ons distributed elsewhere (e.g. GitHub, Freemius) are rendered as external Get add-on ” links that open the vendor’s site in a new browser tab — the plugin itself does not download or install those add-ons, so no request is sent to the vendor’s servers from wp-admin. If the administrator clicks the external link, their browser navigates directly to the vendor and standard browser metadata (IP, User-Agent, referrer) is sent to the vendor as with any external hyperlink. * Invoking the `core/rollback-wp-core` ability contacts the WordPress.org core version-check API (a WordPress-core-hosted service) via the standard WordPress update API. No data is sent to any external server without an explicit administrator action. ## Screenshots [⌊The Abilities Manager admin page — searchable, sortable ability table.⌉⌊The Abilities Manager admin page — searchable, sortable ability table.⌉[ The Abilities Manager admin page — searchable, sortable ability table. [⌊The edit drawer — tri-state override controls for each ability field.⌉⌊The edit drawer — tri-state override controls for each ability field.⌉[ The edit drawer — tri-state override controls for each ability field. [⌊Bulk actions toolbar for allow/disallow/reset across multiple abilities.⌉⌊Bulk actions toolbar for allow/disallow/reset across multiple abilities.⌉[ Bulk actions toolbar for allow/disallow/reset across multiple abilities. [⌊The Ability Library page — enable/disable add-on ability groups.⌉⌊The Ability Library page — enable/disable add-on ability groups.⌉[ The Ability Library page — enable/disable add-on ability groups. [⌊The Add-ons page — browse free companion plugins.⌉⌊The Add-ons page — browse free companion plugins.⌉[ The Add-ons page — browse free companion plugins. [⌊Settings — Display (abilities-per-page) and Upload Media Abilities (allowed-MIME list + Add file types).⌉⌊Settings — Display (abilities-per-page) and Upload Media Abilities (allowed-MIME list + Add file types).⌉[ Settings — Display (abilities-per-page) and Upload Media Abilities (allowed-MIME list + Add file types). ## Installation 1. Upload the `acrossai-abilities-manager` folder to `/wp-content/plugins/`. 2. Activate the plugin through the **Plugins** menu in WordPress. 3. Navigate to **AcrossAI Abilities Manager** in the WordPress admin menu. **Quick Connect setup wizard:** On activation the plugin opens a short setup wizard once — how many abilities the site has, how to edit them, how to act on many at once, what they cover, and how to connect them to an AI assistant. It does not open on sites already running AcrossAI MCP Manager, which provides its own wizard. The wizard is re-runnable at any time and is reachable from four places: **AcrossAI Quick Connect** in the sidebar, the **Quick Connect via AcrossAI** entry in the admin toolbar, the **Quick Connect via AcrossAI** link on the Plugins screen, and a button under **Setup** on the AcrossAI Settings Abilities tab. Those entries are hidden when AcrossAI MCP Manager is active, to avoid two wizards competing for the same surfaces; the wizard itself stays reachable at /wp-admin/admin.php?page =acrossai-abilities-manager&quick-connect=1&step=1. **Add-ons:** 1. Go to **AcrossAI Add-ons** to browse available companion plugins. 2. All add-ons are free and hosted on WordPress.org; each card offers a one-click Install / Activate / Deactivate action via the standard WordPress plugin installer. ## FAQ ### Is this plugin free? Yes, entirely, and under GPL. There is no paid tier of this plugin and no feature is held back. ### What can an AI actually do once this is installed? 357 abilities on any site — content, blocks, appearance, users, configuration, database, files, cron, cache, updates and diagnostics — rising to over 800 as it detects plugins such as WooCommerce, Elementor, Rank Math, Yoast SEO, ACF and LiteSpeed Cache. Abilities are the capability layer; connecting an AI assistant to them needs a transport ( see below). ### Why does my AI only see about a dozen tools when there are 357 abilities? That is deliberate, and it is what makes the catalogue usable. Your MCP server groups the abilities into toolsets, and each toolset is a single tool answering three actions—` discover` to list what it holds, `info` to read one ability’s parameters, `execute` to run it. Exposing 357 separate tools would flood the model’s context window, and most assistants degrade badly past a few dozen. Your AI reaches everything through those, drilling in only when it needs to. ### Does removing the plugin leave anything behind? The WordPress ability registry is never modified, so deactivating returns it exactly as it was. Overrides you set live in the plugin’s own table; abilities registered by this plugin simply stop being registered. ### Do I need another plugin to use this with an AI assistant? For an AI client to reach these abilities over MCP, yes — you need an MCP server such as [AcrossAI MCP Manager](https://wordpress.org/plugins/acrossai-mcp-manager/), which is also free. This plugin works perfectly well without one: abilities are registered with `show_in_rest`, so they remain reachable over the WordPress REST API and callable by any plugin. ### Can an AI break my site? It can only do what you allow. Every ability runs WordPress’s own capability check for the calling user, so nothing here grants extra privilege. Roughly half the catalogue is annotated read-only and only about 13% is flagged destructive; higher-risk operations require an explicit confirmation flag; search-and-replace defaults to a dry run; file access is confined to an administrator-defined path allowlist; and secrets such as database credentials and auth salts are stripped from file and log reads. Any ability you disallow is unregistered outright, not merely hidden. ### Does it need WordPress 6.9? Yes. The Abilities API arrived in WordPress 6.9, and this plugin registers nothing without it — the registration path is guarded, so an older site simply gets no abilities rather than an error. ### Does this plugin support Multisite? No. This plugin has not been tested on WordPress Multisite installations. ### Does this plugin modify the WordPress ability registry? No. The plugin stores only overrides — fields that differ from the registry defaults. The ability registry itself (`wp_get_ability()`) is never modified. ### What happens when I reset an override? The override row is deleted from the database. The ability will inherit its values from the registry again. ### What is the Ability Library? The Library page lets you enable or disable ability groups registered by add-on plugins. Each group shows an ON/OFF master toggle and an All/Specific mode selector. In Specific mode, individual ability slots can be toggled independently. ### What is the MCP Adapter integration? If the MCP Adapter plugin is active on your site, AcrossAI Abilities Manager will display the list of registered MCP servers in the ability edit panel. This is entirely optional — the plugin works without the MCP Adapter. ### Does this plugin make external HTTP requests? The plugin’s own code makes no external HTTP requests. Two admin-only surfaces trigger external connections on behalf of an authenticated administrator: * **AcrossAI Consultations** submenu — renders a static call-to-action button that links to `https://calendly.com/acrossai/using-ai-in-wordpress` and opens in a new browser tab. The plugin does not load any Calendly script, iframe, or asset inside wp-admin. Calendly is only contacted if the administrator explicitly clicks the button — at which point their browser navigates directly to `calendly. com`, exactly as with any external hyperlink. * **AcrossAI Add-ons** submenu — installs WordPress.org-hosted companion plugins in place through WordPress core’s `plugins_api()` + `Plugin_Upgrader` (contacts` api.wordpress.org` + `downloads.wordpress.org`). Add-ons registered with any other source (e.g. GitHub, Freemius) render as external Get add-on ” links that open the vendor’s site in a new browser tab — the plugin does not download or install those add-ons itself. Users install off-directory add-ons via WP admin’s standard **Plugins Add New Upload Plugin** flow (or via the vendor’s own installer once the paid plugin is activated). Full disclosure — including what data is transmitted, and links to each service’s terms + privacy policy — is in the **External Services** section of this readme. ## Reviews There are no reviews for this plugin. ## Contributors & Developers “AcrossAI Abilities Manager – WordPress Abilities for Claude, ChatGPT & Any AI Agent” is open source software. The following people have contributed to this plugin. Contributors * [ AcrossAI ](https://profiles.wordpress.org/raftaar1191/) “AcrossAI Abilities Manager – WordPress Abilities for Claude, ChatGPT & Any AI Agent” has been translated into 1 locale. Thank you to [the translators](https://translate.wordpress.org/projects/wp-plugins/acrossai-abilities-manager/contributors) for their contributions. [Translate “AcrossAI Abilities Manager – WordPress Abilities for Claude, ChatGPT & Any AI Agent” into your language.](https://translate.wordpress.org/projects/wp-plugins/acrossai-abilities-manager) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/acrossai-abilities-manager/), check out the [SVN repository](https://plugins.svn.wordpress.org/acrossai-abilities-manager/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/acrossai-abilities-manager/) by [RSS](https://plugins.trac.wordpress.org/log/acrossai-abilities-manager/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 0.0.41 – 2026-09-30 * **Fixed: Global Styles saved through the abilities were stored but never applied.** Every write to the database record (`blocks/create-global-style`, `blocks/update- global-style` with `source: "db"`) saved `settings` and `styles` and nothing else. WordPress only uses that record when it also carries `"isGlobalStylesUserThemeJSON": true` — `WP_Theme_JSON_Resolver::get_user_data()` discards the whole thing otherwise and falls back to the theme’s `theme.json`, without logging anything. So a palette, a font, a layout width would be written, read back correctly, reported as `origin:" db"` and `effective: true`, and the site would go on rendering theme defaults. Adding the key by hand did not help either: it was rejected as an unknown top- level key, because the record was being validated against the list of keys a ` theme.json` _file_ may carry. Both flags — the marker and `version`, set to ` WP_Theme_JSON::LATEST_SCHEMA` — are now stamped on the server for every DB write, including section writes, merges, replaces and migrations, so nothing has to be passed by the caller. The DB source is validated against the shape core actually reads from it (`version`, `isGlobalStylesUserThemeJSON`, `settings`, `styles`,` title`); `templateParts`, `customTemplates` and `patterns` are refused there by name, with the message saying they belong in a `theme.json` file and which ability writes one. * **Fixed: a font stack containing double quotes wiped the entire Global Styles record, and still reported success.** `"fontFamily": "\"EB Garamond\", Georgia, serif"` is an ordinary value; saving it destroyed everything else in the record. The encoded JSON was handed to `wp_update_post()` unslashed, and core runs `wp_unslash()` over every field it is given, so each `\"` inside the JSON lost its backslash and the stored content stopped being JSON. It then decoded to null, which the read path reported as an _empty_ record — so the next merge-write started from empty and saved only the section it was given, silently dropping the colors, layout and spacing saved minutes earlier. The ability reported `success: true` and a non-zero `content_bytes` throughout. Content is now slashed on the way in, exactly as core’s own Global Styles REST controller does; every write is read back and decoded before it is called a success, and one that does not decode is rolled back to the previous content and returned as `success: false`. A merge into a record that does not decode is refused outright rather than treated as empty — that conversion is what turned one bad write into total loss. The same fix is applied to block style variation records, which are written through the same path and had the same defect. * **Global Styles reads now say when WordPress is ignoring the record.** `read- global-style` reported `origin: "db"` and `list-global-styles` reported `effective: true` for records WordPress was not using at all. `origin` is now `"db:ignored"` for a record that is missing the marker or does not decode, with a warning naming the reason; `list-global-styles` reports `applied_by_wordpress` on every row and marks the `theme.json` copy the site is really serving as the effective one. Records written by earlier versions are repaired automatically by the next write, by a one-time upgrade routine that runs on activation and on the first request after updating, or on demand with `update-global-style` and `repair: true`, which adds the flags and changes nothing else. The upgrade routine touches only records whose content decodes and that carry core’s `wp-global-styles-` naming; content that does not parse is left alone for hand-recovery, and block style variations are skipped, since they must not carry the marker. * **Section writes no longer discard what they were given in silence.** A `section:" typography"` write carrying `styles.elements` saved the typography and dropped every heading, link and button style in the same call, reporting success. A ` section: "blockStyles"` write carrying only `styles.elements` saved nothing at all and also reported success. Element styles now have a section of their own—` section: "elements"` — anything a section write does not save is named back in` warnings` as `ignored: styles.elements`, and a section write that would save nothing is refused with a message naming what was ignored and where it belongs. * **`blocks/get-style-guide` now labels where each preset came from.** It listed theme and user presets for the same slug side by side with nothing to tell them apart, so an overridden colour read as a duplicate; and for fonts, font sizes, duotones and gradients it read the theme’s presets only, so user presets were missing from the style guide entirely. Each preset now carries an `origin` of` theme` or `custom`, a slug appears once — the value the site actually renders— and where a user preset replaced a theme one it says so with `overrides`. #### 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. #### Earlier releases Every release before 0.0.36 is recorded in full at https://acrossai.co/changelog/ acrossai-abilities-manager/ and in changelog.txt, shipped inside the plugin. ## Meta * Version **0.0.41** * Last updated **22 сахаты ago** * Active installations **20+** * WordPress version ** 6.9 or higher ** * Tested up to **7.1.2** * PHP version ** 8.1 or higher ** * Languages * [English (US)](https://wordpress.org/plugins/acrossai-abilities-manager/) and [Lao](https://lo.wordpress.org/plugins/acrossai-abilities-manager/). * [Translate into your language](https://translate.wordpress.org/projects/wp-plugins/acrossai-abilities-manager) * Tags * [abilities](https://os.wordpress.org/plugins/tags/abilities/)[ai assistant](https://os.wordpress.org/plugins/tags/ai-assistant/) [ChatGPT](https://os.wordpress.org/plugins/tags/chatgpt/)[Claude](https://os.wordpress.org/plugins/tags/claude/) [mcp](https://os.wordpress.org/plugins/tags/mcp/) * [Advanced View](https://os.wordpress.org/plugins/acrossai-abilities-manager/advanced/) ## Ratings No reviews have been submitted yet. [Your review](https://wordpress.org/support/plugin/acrossai-abilities-manager/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/acrossai-abilities-manager/reviews/) ## Contributors * [ AcrossAI ](https://profiles.wordpress.org/raftaar1191/) ## Support Got something to say? Need help? [View support forum](https://wordpress.org/support/plugin/acrossai-abilities-manager/) ## Donate Would you like to support the advancement of this plugin? [ Donate to this plugin ](https://acrossai.co/abilities-manager/)