1.3.0

Added

• Codex tab in the Connection screen. Its snippet goes into ~/.codex/config.toml (or a trusted project's .codex/config.toml), shared by the Codex CLI, its IDE extension and the ChatGPT desktop app. Codex speaks streamable HTTP, so it reaches the server directly with the Authorization header, no proxy.
• Each client tab shows its logo: the Claude Code mascot, the Claude logo for Claude Desktop, the Cursor and Codex logos, and a plugin icon for the other clients.
• Screenshots of the three tabs, in the README and for the WordPress.org listing.

Changed

• When an ability label wraps, its "?" and badges stay on the right of its first line instead of falling alone under it, and the checkbox lines up with that first line.
• The README describes the badges, the legend and the "?" as they are since 1.2.4.

1.2.4

Changed

• The "?" is back: written under every checkbox, the descriptions made the blocks of plugins that describe their abilities at length (Product Feed for one) hard to read. It now shows only when the description says more than the label, and its tooltip gives the technical name and the description.
• A badge every ability of a block carries is no longer repeated on each row: the legend says it applies to every ability below. The badges that remain line up with the label when they wrap.

1.2.3

Changed

• The release workflow builds the installable zip and publishes the GitHub release in its own job. The WordPress.org deploy only runs when the DEPLOY_TO_WPORG repository variable is true: while the plugin is not on WordPress.org, its failure skipped the release, zip included.
• Clearer badges on the settings screen. "Deletes" becomes "Irreversible", since it reflects the destructive annotation of an ability (it can overwrite data, not only delete it), and "Closed by its plugin" becomes "Hidden by default". A legend above each block explains the badges it shows.
• The "?" tooltip is gone: each ability's technical name, and its description when it says more than the label, are written under the checkbox and stay tied to it through aria-describedby.

1.2.2

Fixed

• Exposing to MCP a third-party ability its own plugin keeps closed had no effect. The validation wrote false in wpmcpa_enabled for every such ability, and both the exposure and the availability filter drop an ability switched off there. Only the abilities whose box writes to that option are rewritten now, and the entries left by earlier versions are cleared.
• Accessibility of the settings screen: each ability's name and description are tied to its checkbox through aria-describedby, and the "?" is a real button with a name. "Copied!" is announced to screen readers. A failed save stays on screen in an error notice instead of a snackbar that vanished. The loading spinner has a status role and a label.
• The login in the application password sentence is passed as an element, no longer parsed with the translated string.

Added

• wpmcpa_server_url filter, to change the MCP server URL the settings screen hands out.

Changed

• Destructive abilities are off by default by construction: AbstractAbility::isEnabledByDefault() follows isDestructive().
• The settings REST route returns, for each row, the parameter its box writes to (option: enabled or exposed), decided by ThirdPartyAbilityCatalog::optionFor(). Its read model moves to Services\SettingsScreenData.
• The options.php capability filter is gone: no form posts there any more. The options stay registered so that update_option() keeps its validation.

1.2.1

Security

• get-term-seopress only checked edit_posts: a contributor could read the SEO fields of any term, private taxonomies included. It now requires edit_term on the term, like get-term-meta and update-term-seopress.
• get-term-meta and get-term-seopress answer a missing term like a forbidden one, so a direct execute() call cannot tell which terms exist.

Fixed

• A POST to the wp-mcp-abilities/v1/settings route only changes the switches it sends. An empty or partial payload used to switch every other ability off. The settings screen always sends every switch and is not affected.
• The settings screen loads its RTL stylesheet on right-to-left sites.
• The Base64 helper command escapes a single quote in the login, and the Claude Code instructions now say that the command leaves the password in the shell history.
• The preloaded settings are encoded with JSON_HEX_TAG | JSON_HEX_AMP in the inline script.

1.2.0

Added

• A Connection tab on the settings screen: the MCP server URL with a copy button, an application password created for the current user in one click, and configurations for Claude Code, Claude Desktop (through @automattic/mcp-wordpress-remote), Cursor and a generic HTTP client, filled with the login and the new password. Warnings show when the MCP Adapter is not running, when the default server is switched off, or when application passwords are unavailable.
• readonly and destructive annotations on every ability, published in meta.annotations and read by MCP clients. AbstractAbility gains isReadOnly() and isDestructive().
• wp-mcp-abilities/v1/settings REST route (GET, POST), reserved to manage_options, behind the settings screen.

Changed

• The settings screen is rebuilt with @wordpress/components, in tabs. Abilities are grouped in cards and split into read-only and write, with a select-all box per block, a filter field, the name and description behind a ?, and a badge on the ones that delete. Third-party abilities move to their own tab. The stored options and their validation are unchanged.
• The screen's script is built with @wordpress/scripts into build/, which is not versioned: a copy cloned from the repository needs npm ci && npm run build. The release workflow builds it before deploying.

Security

• Read abilities only checked edit_posts, never the object they read: any contributor could read the content, meta and SEOpress data of private posts and of other authors' drafts, and browse the whole media library. Permissions are now checked on the object itself. get-* post type abilities require read_post (edit_post for a password-protected post). list-* post type abilities only return published posts and the caller's own without edit_others_posts. get-post-meta and get-post-seopress require edit_post on the post, as the REST API edit context does. list-media requires upload_files and leaves out attachments whose parent the caller cannot read. Ported from bsaweb-mcp-abilities.
• get-term-meta only checked edit_posts: a contributor could read the meta of any term, private taxonomies included. It now requires edit_term on the term read, like update-term-meta and delete-term-meta.