=== AcrossAI MCP Manager — Full Changelog === The complete release history. README.txt carries only the most recent versions, because WordPress.org truncates a readme's Changelog section at 5,000 words; this file is the unabridged record and ships with the plugin. Releases are also published at: https://github.com/acrossaico/acrossai-mcp-manager/releases = 0.4.4 = * **New: a log of what AI assistants actually did on your site.** Every request an assistant makes, and every ability that ran to fulfil it, recorded together — one "create a page" from an assistant may run several abilities, and the log keeps them linked, so you open one entry and read what happened instead of inferring it from the result. It records which assistant, how it authenticated, whether it worked, how long it took, what was asked and roughly how much of your content was read back. Find it under **MCP → Activity Log**, or on an individual server's own tab. * **The log is on from the moment you update, and bounded without being configured.** Requests are kept 30 days, ability runs 7 — they are much noisier — and the whole log is capped at 50,000 entries. A daily job applies all three. Every number is adjustable and either half can be switched off on the MCP settings tab. Recording is on by default because a log nobody enabled is a log nobody has when they need it; it is bounded by default because a plugin that records without being asked should also tidy up without being asked. * **It tells you when it is failing.** An empty log and a broken log look identical, which is how a logging fault stays invisible. The screen and Site Health now both report when writes are failing, when the table cannot be reached, and when the daily cleanup has not run — the last one usually meaning WordPress scheduled tasks are not running at all on the site, which affects far more than this log. * **Private by design.** Values that look like credentials are redacted by key name before anything is stored, response bodies are never kept, and WordPress's own personal-data export and erase both reach the log. Erasure clears the person from the record and keeps the event, so a subject request cannot be used to delete audit history. * **Changed: the connection wizard is now called "Connect".** It was "Quick Connect via AcrossAI" in the admin bar, the menu, the server list and the wizard's own header. Nothing moved and nothing behaves differently — the label just says less. * **Fixed: a PHP notice on every page load.** A database table was passing an index setting in a form newer PHP versions warn about. It had never had any effect — the table was not using it — so removing it changes nothing except that the notice stops. Only visible to sites with debug logging switched on. = 0.4.3 = * **New: a heads-up in Firefox, where tracking protection can block an assistant from connecting.** Firefox's Enhanced Tracking Protection can stop the connection part-way through — the connector is added, sign-in opens, and then nothing completes, with no error shown anywhere to explain it. Opening a connector screen in Firefox now shows a note explaining this and how to get past it: click the shield icon to the left of the address bar and switch Enhanced Tracking Protection off for this site, then connect again. The setting is remembered per site, affects nothing else you browse, and can be switched back on once the connection is working. The note appears only in Firefox and can be dismissed. Adopted from AcrossAI Pro 0.9.16, where it was written for a real site that could not connect — connecting an assistant is this plugin's job now, so the warning belongs here. * **Fixed: uninstalling left a settings row behind.** The "delete all data on uninstall" sweep deliberately skipped every option starting `acrossai_mcp_connector_`, because an earlier release had handed that namespace to the paid plugin and deleting another plugin's settings would have been wrong. Version 0.4.0 took that area back, which quietly turned the exception into a leak: the only row it still protected was this plugin's own version marker for one of its four tables — a table the same uninstall drops. The sweep now covers the whole namespace. Only affects uninstalling with the delete option switched on. = 0.4.2 = * Improved: rewrote the plugin listing around what your AI can actually do on the site, instead of leading with how the plugin relates to MCP Adapter. * Added: real use cases with links, ability counts for each plugin integration, and an explanation of why your AI sees about a dozen tools when there are 357 abilities. * Added: sections on controlling every ability, and on reproducing a plugin conflict without writing to `active_plugins`. * New: six screenshots of the ability controls — the abilities table, the override drawer, bulk actions, the Ability Library, Add-ons and abilities settings. * Tidied: shortened the FAQ and replaced the questions that only restated the description. * Note: listing and documentation only. No code, settings or database change. = 0.4.1 = * Changed: minimum WordPress version lowered from 7.0 to 6.9. * Fixed: the plugin header used an unrecognised name for the minimum WordPress version, so WordPress did not enforce it. * Corrected: the description still said one-click connectors were a paid extra. They have been part of this plugin since 0.4.0. * Improved: rewrote the plugin listing and FAQ, and added a FAQ on how this plugin relates to MCP Adapter. * Tidied: removed boilerplate that claimed PHP 7.4 compatibility, shortened upgrade notices and trimmed the changelog to recent releases. = 0.4.0 = * **New — connecting Claude, ChatGPT, Gemini, Grok or Cursor is now part of this plugin, free.** Paste one URL into the AI client, approve the consent screen, and you are connected. This used to require the paid AcrossAI Pro add-on; the **Connectors/Integrations/Plugins** tab that previously showed an advert for it now does the actual job. * **Please note — load wp-admin once after updating.** The upgrade moves your existing connections into this plugin, and that move runs on the first WordPress admin page you open. On a site updated by auto-update or WP-CLI, nothing runs until someone signs in, and connected AI clients cannot authenticate until it does. Open any wp-admin page once and it completes by itself. Nothing is lost in the meantime — the clients simply get told "not authorised" until the move finishes. * **Unchanged — your existing connections keep working.** Every connected AI client stays connected. No reconnecting, no re-approving, no new URLs to paste. The tokens your clients already hold remain valid, and the paid plugin's copy of them is left untouched as a safety net rather than deleted. * **Changed — the Quick Connect wizard no longer asks you to buy anything.** The two screens that pitched the add-on and walked you through installing and licensing it are gone. Choosing one-click connection now takes you straight to the connector screen. * **Please note — AcrossAI Pro is still useful, just not for this.** It keeps its abilities library, access control and the n8n connection. You do not need it for connectors any more, and if you have it installed it will notice this plugin has taken over and stand aside on its own. There is nothing to uninstall and no order to update them in. * **Database — four tables are added** for OAuth clients, tokens, authorization codes and connector approvals. If you were using the paid plugin, their contents are copied across; its own tables are left exactly as they were. * **Security — people outside a server's access rule could still read its list of tools.** If you limited a server to certain roles or users, anyone else who was logged in could still open it and see every tool it offered, with names and descriptions. They could not run any of them, and nothing could be changed or taken — but a list you meant to be private was readable. Those people now see an empty server. Administrators and anyone the rule allows are unaffected. * **Fixed — switching off the Default MCP Server now actually switches it off.** It used to be marked Inactive while its address carried on answering as if nothing had happened. It now stops answering. New installations also start with it switched off, so nothing is reachable until you turn it on; sites that already have it switched on are not changed. * **Updated — MCP Adapter 0.7.0.** Adds the newest version of the MCP standard (2026-07-28) while continuing to work with the older ones, so existing connections keep working. It also clears a stream of errors the previous version wrote into the debug log on every request. * **Fixed — setup instructions showed Windows and Linux users a macOS file path.** The Clients tab printed one config file location for everyone, and it was the macOS one, so a Windows user following the Claude Desktop steps was sent to a folder that does not exist on their machine. Every system a client supports is now listed and labelled. = 0.3.8 = * **Changed — the **AcrossAI** server is recommended again, and now says so.** It carries a green **RECOMMENDED** badge on the servers list and on its **Overview** tab, and its row is pinned to the top of the list rather than sitting wherever its creation order put it. 0.3.4 removed that promotion; this puts it back, because a recommendation on a row buried mid-list is not much of a recommendation. * **Changed — **Quick Connect** step 1 arrives with AcrossAI already selected.** Landing on the wizard with no previous choice used to select whichever server happened to be first in the list. It now preselects the recommended one and marks it, so the common path — accept the recommendation and carry on — is correct before you touch anything. A choice you have already made is still remembered and still wins. * **Changed — new servers start on the **AcrossAI** type where the add-on is installed.** Creating a server, from either the classic form or the Quick Connect wizard, now starts it on AcrossAI instead of MCP Adapter, so it arrives carrying the AcrossAI toolsets. 0.3.4 made MCP Adapter the type for every new server; that is the decision being reversed here. Pick MCP Adapter from the **Server type** dropdown when you want it — nothing is taken away, only the starting point moves. * **Please note — on a site without the add-on, new servers still start on **MCP Adapter**.** The AcrossAI type needs the AcrossAI Abilities Manager plugin to supply its toolsets, so it is only chosen where it can actually run. Where it cannot, creation falls back to MCP Adapter exactly as in 0.3.7 — you will not get a server that starts out waiting on a plugin you have not installed. * **Please note — every existing server is untouched.** No type is changed, no tool selection is rewritten, and nothing is re-ordered except where the recommended row is drawn. This release changes which server is *suggested* and what a *new* server starts as; it does not reach into servers you already have. * **Unchanged — both seeded servers still cannot be deleted.** Being recommended and being protected from deletion are two separate things, and they stay separate: **Default MCP Server** and **AcrossAI** are both undeletable as before, while only AcrossAI is recommended. * **No database change.** Schema stays at `1.1.7`; no table is added, altered or removed, and no migration runs on update. = 0.3.7 = * **Fixed — a server could offer tools you never chose, and refuse to let you remove them.** On some sites the plugin's database tables were missing columns the plugin expected, and had been for a long time. Nothing reported it: the missing settings simply read as "on", so a server could advertise three extra tools, and unchecking them said "saved" while changing nothing — the setting was being written to a column that did not exist. Affected sites now repair themselves on the next wp-admin page load. You do not need to do anything, and your own tool selections are left exactly as you set them. * **Please note — reconnect your AI client afterwards.** An AI client is handed its list of tools once, at the moment it connects, and there is no way to hand it a new one. So a repaired site serves the right tools immediately, but a client that was already connected keeps showing the old list until you disconnect and reconnect it. If the count still looks wrong after the repair, that is why. * **Please note — the repair runs when someone opens wp-admin.** It happens on the first admin page load after updating, with no reactivation needed. A site nobody ever signs into is not repaired, because nothing runs there to do it. * **Fixed — a failed database change no longer records itself as done.** Certain changes that could not be applied were nevertheless marked complete, which meant they were never retried and the site stayed wrong indefinitely. They now retry on the next admin page load. * **Changed — the WordPress.org listing now describes what the plugin actually does.** The description, feature list and FAQ were rewritten against the code, three claims that the plugin did not support were removed, and every screenshot is now captioned. No change to the plugin itself. = 0.3.6 = * **Fixed — installing the AcrossAI Abilities Manager add-on now just works.** Before this release, installing the add-on after this plugin changed nothing you could see: your server still offered the same few tools and nothing told you the larger set had arrived. Getting it took four undocumented steps — open **Tools**, change **Server type** to AcrossAI, confirm, then press **Reset to Type Defaults**. The cause was that the AcrossAI type shipped with an empty tool list, because this plugin did not know what belonged on it until the add-on turned up and said so. It knows now, so the list is written down in advance and the tools start working the moment the add-on is activated. No type change, no Reset, nothing to read. * **New — the plugin creates a second server, **AcrossAI**, alongside the default one.** It arrives **disabled**, listed after **Default MCP Server**, at `/acrossai/mcp`, and carries the AcrossAI toolsets from the start. Nothing is served until you enable it, and enabling it is your decision. If you do not want it, disable or delete it. (0.3.4 briefly added a similar server and 0.3.5 withdrew it — the row was never the problem, the tools it carried were. It returns with the right ones.) * **Fixed — a fresh install created that server with no tools at all.** Found by installing on a genuinely new site rather than by resetting an existing one. The plugin created its servers *before* creating the table their tool selections live in, so every selection was written into a table that did not exist yet — and the write reported success. Activation looked fine and the server arrived empty. Sites already affected are repaired automatically on the next wp-admin page load; a server you have curated yourself is left alone. * **Changed — a server can be enabled before its add-on is installed, and says what it is waiting for.** Previously such a server could not be switched on at all, which broke the **Quick Connect** wizard for exactly the person who had not installed the add-on yet. Now enabling records your intent, the admin shows which plugin is still missing, and installing that plugin makes the server live with no further clicks. Quick Connect will still not hand over a client configuration until then, and says why — a configuration pasted into Claude or Cursor too early connects and looks broken, and because AI clients cache their tool list when they connect, it would keep looking broken afterwards. A server whose type is **unrecognised** still cannot be enabled: no install fixes that one. * **Fixed — the Tools tab now shows the tools your server is configured with.** It was showing what the server is *serving right now*, so a server carrying fifteen tools could read "Added as tools (1)". Related fixes in the same screen: **Reset to Type Defaults**, **Enable All** and even adding a single tool could quietly delete the rest of your selection; the picker offered tools belonging to a different server type; and changing **Server type** appeared to work but reverted on the next page load. * **New — you can write your own connect message.** Every server sends a short briefing to an AI client when it connects, explaining what kind of server it is and which tool to call first. The **Overview** tab now offers **System default** (recommended, and kept up to date by the plugin) or **Custom**, prefilled with the message your server sends today so you can edit rather than start from nothing. Already-connected clients keep the message they received; new connections get yours. * **Changed — every existing server gains **Server guide**.** A one-time addition to servers created before it existed, so they get the tool that explains what the site actually contains. Your own tool selections are untouched. * **Changed — a quieter admin.** Warnings about a missing add-on now appear only once a server is actually enabled, rather than on a server that is switched off and serving nobody. Tools waiting on a plugin read as ordinary rows instead of a column of apologies. The Overview tab no longer repeats the client list and credential notes that belong on the Connect tab. * **Removed — the **Backups** toolset.** It was the one toolset named after a category rather than a plugin, covering UpdraftPlus and All-in-One WP Migration together, while every other integration is named for the plugin it serves. It is being rebuilt as one toolset per backup plugin. The backup abilities themselves are unchanged and stay in the add-on. * **Internal — this plugin now owns the Toolset layer** (the dispatchers behind `toolset/content`, `toolset/users` and the rest) instead of the add-on. **Nothing changes for you:** on a site running both plugins the add-on's copies still win and this plugin's stand down, verified by comparing the two side by side. The abilities themselves have not moved and stay in the add-on. * **No database change.** Schema stays at `1.1.7`; no table is added, altered or removed. The new server is an ordinary row, written on the first wp-admin page load after updating. = 0.3.5 = * **Changed — a new server now arrives with its type's tools already selected.** Creating a server, from either the classic form or the Quick Connect wizard, used to hand it the same three `mcp-adapter/*` protocol tools whatever type you picked, because that is what the database columns default to. A type's tool set was only ever written when you pressed **Reset to Type Defaults**. A new MCP Adapter server now includes **Server guide** from the start, and a new AcrossAI server starts with the AcrossAI toolsets rather than the wrong three. Existing servers are untouched — where a type has tools a server does not, the Tools tab still offers them with a one-click **Apply**, and your own selection is never overwritten. * **Changed — the plugin no longer creates a second MCP server.** 0.3.4 added an AcrossAI-branded server at `acrossai/mcp` on every site. It is not created any more: a second MCP endpoint appearing unasked is a decision that belongs to you, and the **AcrossAI** server *type* already covers it — create a server and choose that type when you want one. If your site already has that server it is left exactly as it is, still working, and it is now deletable like any other server rather than locked as plugin-managed. Servers list in the order they were created. * **Changed — the Server type control is hidden when there is only one type to choose.** With no add-on installed there is nothing to pick, so the create form and the Tools tab no longer show a dropdown whose only other option is unavailable. It returns the moment a second type is installed. * **Internal — the full changelog moved to `changelog.txt`, shipped with the plugin.** WordPress.org truncates a readme's changelog at 5,000 words and had begun cutting this one, so the readme now carries the recent releases and that file holds the complete history. * **No database change.** Schema stays at `1.1.7`; nothing is added, altered or removed on update. = 0.3.4 = * **New + changed — the Tools tab now lists tools, and the Abilities tab lists abilities (F087).** Two admin screens were each showing the wrong set. The per-server **Tools** tab offered all ~370 registered abilities in its left pool, even though abilities have not been advertised individually in `tools/list` since 0.2.x — they reach AI clients *through* a handful of tool-level entries: the three `mcp-adapter/*` protocol tools, and the `toolset/*` dispatchers the AcrossAI Abilities Manager plugin registers (each one a router that takes `action=discover|info|execute` and forwards to a whole group of abilities). Meanwhile those same dispatchers cluttered the **Abilities** tab as ordinary rows with their own Exposed toggle, where a toggle on them either does nothing or breaks the protocol. Both screens now read from one declared list of tool-level abilities: the Abilities tab hides them, the Tools tab shows nothing else. The left pool is relabelled **Available tools** to match. Any plugin can declare its own through the new filter `apply_filters( 'acrossai_mcp_manager_tool_abilities', string[] $slugs )`, which is seeded with the three protocol tools; removing one of those puts it back on the Abilities tab. **Behaviour change worth reading:** on a site where no plugin hooks the filter, the Tools pool holds exactly the three protocol tools, so individual abilities can no longer be added as tools from that screen — use the existing `acrossai_mcp_manager_server_tools` filter to put one on a server in PHP. **Nothing you already picked is lost:** abilities already added to a server keep rendering in the "Added as tools" pane with their real labels, stay removable, and survive every save; they simply can't be re-added from the left pool once removed. The list is presentational — it changes neither per-server exposure, nor tool curation, nor call-time permission enforcement; every tool call is gated exactly as before. Contract and worked examples in `docs/extending-abilities-tab.md`. * **Changed — the plugin now keeps its own servers' details in step, and will undo edits to them.** Before this release the plugin-managed server rows were written once and never revisited, so an edit to one stuck. They are now reconciled on each admin page load: **name, description, route, route namespace and version are plugin-owned and get restored if they differ.** If you renamed **Default MCP Server** or changed its description or route, that change is reverted on update — recreate it as your own server instead, where nothing will overwrite it. What stays yours: whether the server is **enabled**, its **server type**, and every **tool and ability selection** on it. * **New — Server types, and Reset finally restores the right tools (F090).** Every MCP server now records what type of server it is. This fixes a real defect: the Tools tab's **Reset** button restored the same three `mcp-adapter/*` protocol tools on every server regardless of what that server was for, so on a server meant to serve the AcrossAI toolsets "reset to defaults" produced the *wrong* defaults and silently discarded the operator's selection. Reset now restores the server's own type's tool set. Two types ship: **MCP Adapter** (the three protocol tools) and **AcrossAI** (toolsets supplied by the AcrossAI Abilities Manager add-on). Every server that existed before this release is recorded as **MCP Adapter** and what it advertises is unchanged — byte for byte. New filter `apply_filters( 'acrossai_mcp_server_types', array $types )` lets any plugin contribute a type or replace a shipped one; contract and worked example in `docs/extending-server-types.md`. * **New — the AcrossAI type requires its add-on, and says so instead of failing quietly.** A server whose type declares a requirement that is unmet cannot be **enabled**, and the refusal names the missing plugin rather than silently doing nothing. Enforcement is server-side on every route that can switch a server on — the single toggle, the bulk action, and the Quick Connect wizard — not in the interface alone. Two ways out are always offered: install the add-on, or change the server's type. **Disabling is never blocked**, so a server stranded by a deactivated add-on can always be switched off, and a running server is **never auto-disabled** — that would break a live AI client session instead of explaining itself. * **New — a connected AI client is told what is wrong.** If the add-on is deactivated underneath a server that was already enabled, the server keeps answering and advertises a single entry whose description names the plugin that must be installed. Its address does not 404 and the connection is not dropped. Curated tool selections are untouched throughout and return intact when the add-on is reactivated. One caveat worth knowing: a client holding a tool list from *before* the deactivation and calling one of those tools receives the MCP Adapter's own generic "tool not found" — that lookup happens inside the adapter before any plugin filter runs. Clients that re-list after an error, which is what most agents do, see the explanation. * **New — bulk tool controls on the Tools tab, matching the Abilities tab.** **Enable All**, **Disable All** and **Reset to Type Defaults**. Each is a one-time write to the server's tool selection, not a standing rule: "Enable All" adds every tool available to this server right now, and a tool-level ability registered *later* by a plugin you install in future is offered in the picker rather than added automatically. That is a deliberate choice — what a server serves is decided in exactly one place, the selection you can see on the tab, so what the screen shows and what an AI client receives cannot disagree. The confirmation dialog says a bulk action replaces the current selection, because it does. * **Tools tab — says when a change has not reached connected AI clients yet.** An MCP client caches the server's tool list at the moment it connects, and the protocol gives a WordPress server no way to reach one that is already connected: the MCP Adapter advertises `tools.listChanged: false` and its server-to-client channel is unimplemented. Measured against a real client, the notification is ignored even with both corrected. So after a change that alters what the server serves, the Tools tab now states plainly that already-connected clients keep the list they loaded and will see the change on their next session — rather than leaving you with a count that is not yet true for anyone connected. New connections get the change immediately. This is the companion to the AcrossAI Abilities Manager’s `toolset/integrations`, which keeps new capability reachable through a tool a connected client already holds: together, a stale list neither blocks anything nor goes unmentioned. * **Changed — new servers are created as **MCP Adapter**, and they arrive with that type's tools already selected.** Creating a server from either the classic form or the Quick Connect wizard now starts it on the MCP Adapter type; pick AcrossAI from the **Server type** dropdown when you want it. Servers list in the order they were created, with nothing pinned above anything else. Which type new servers start on is one declaration, `ServerTypes::seed()`'s `is_default` key, resolved everywhere through the existing `ServerTypes::default_slug()`. * **Database — schema 1.1.7.** Adds `server_type varchar(32) NOT NULL DEFAULT 'mcp-adapter'` to `{prefix}acrossai_mcp_servers`, applied automatically on the first wp-admin page load after updating. The column default is what backfills existing rows, so every pre-existing server keeps its current behaviour. Schema `1.1.7` also drops a `tools_default_policy` column, which **you will not have** if you are updating from 0.3.3 — it existed only between two development migrations and was never released. The coarse expose/hide tool rule it backed was never honoured at call time, so a server could advertise a tool it then refused; the drop is there to clean up development installs. `abilities_default_policy` on the Abilities tab is a different setting and is unaffected. = 0.3.3 = * **New — Per-server default ability policy (F082, #95).** Each MCP server now carries a tri-state default policy: **Use each ability's own default** (the pre-F082 behaviour every existing server migrates to), **Expose every ability by default**, or **Hide every ability by default**. Clicking **Enable All** or **Disable All** on the per-server Abilities tab now flips this server-level policy — so abilities that a later plugin update or mu-plugin registers inherit the operator's intent automatically, without any admin action. Per-ability overrides still win over the default. Backwards-compatible: existing servers land on **Use each ability's own default** and every ability's effective exposure is byte-for-byte unchanged. New REST route `POST /acrossai-mcp-manager/v1/servers/{id}/abilities/policy` (permission_callback: `manage_options`). New action hook `acrossai_mcp_server_policy_changed( $server_id, $old_policy, $new_policy, $affected_slugs, $user_id )` fires on non-no-op transitions with a per-slug `[was, now]` diff map — policy-transition audit events carry the affected ability slugs and their exposure states, so choose audit-log integrations you trust. Row-only F030 permission-callback bypass semantics preserved verbatim via the SEC-001 rename `ExposureResolver::resolve()` → `resolve_row_only()`; the three-tier resolver used everywhere else is the new `resolve_effective()` sibling. * **Cleanup — orphaned pre-F040 OAuth tables retired (F083).** Older builds of this plugin created `wp_acrossai_mcp_oauth_clients`, `wp_acrossai_mcp_oauth_tokens`, `wp_acrossai_mcp_oauth_auth_codes`, and `wp_acrossai_mcp_connector_approved_users`. Feature 040 moved the OAuth subsystem to the paid companion, which creates its own fresh tables under the `acrossai_pro_mcp_*` namespace and only cleans up those names (it never reads, migrates, or drops the old ones) — leaving the old tables abandoned in place with no owner. This release cleans them up two ways. (1) Automatic: on the first wp-admin page load after updating, a one-shot routine drops each orphaned table **only if it exists and is empty** and deletes its stale `*_db_version` option; non-empty tables are never auto-dropped (their rows were never migrated anywhere) — instead the `acrossai_mcp_legacy_oauth_cleanup_skipped` action fires with a per-table row-count map so operators can decide. Re-trigger after emptying by deleting the `acrossai_mcp_legacy_oauth_cleanup_done` option. (2) Safety net: the four old-name tables are also restored to `uninstall.php`'s opt-in drop list (`DROP TABLE IF EXISTS`; cannot touch the companion's differently-named live tables). Operators who prefer manual cleanup can run, after confirming the tables are empty: `DROP TABLE IF EXISTS wp_acrossai_mcp_oauth_clients, wp_acrossai_mcp_oauth_tokens, wp_acrossai_mcp_oauth_auth_codes, wp_acrossai_mcp_connector_approved_users;` `DELETE FROM wp_options WHERE option_name IN ('acrossai_mcp_oauth_clients_db_version', 'acrossai_mcp_oauth_tokens_db_version', 'acrossai_mcp_oauth_auth_codes_db_version', 'acrossai_mcp_connector_approved_users_db_version');` (Adjust the `wp_` prefix to your site's table prefix. Do NOT touch `wp_acrossai_pro_mcp_*` tables — those belong to the active AcrossAI Pro plugin.) * **UI — the five connection tabs merged into one (F084, #109).** **npm**, **MCP Clients**, **Connectors/Integrations**, **n8n** and **WP-CLI** all answered the same question — *how do I connect an AI client to this server?* — while sitting as five separate tabs in an eleven-tab strip. They are now one tab, labelled **How would you like to connect?**, with the five choices as a second-level row inside it: Connectors/Integrations/Plugins, MCP Client via config file, npm, n8n, WP-CLI. The top-level strip drops from 11 tabs to 8. **Every existing link keeps working:** the five old addresses (`?tab=npm`, `?tab=clients`, `?tab=ai-connectors`, `?tab=n8n`, `?tab=wp-cli`) resolve to the new tab with the right choice selected, and any deeper selection they carry (`&client=`, `&panel=`) is preserved — resolved in place, never via a redirect, so anything keyed to the requested address keeps working. On a local install the tab opens on **MCP Client via config file** rather than the first choice, since copying a client config is almost always the next step there and those configs carry a local-only TLS setting worth seeing early. The servers-list **Connectors** and **MCP Clients** row shortcuts point at the new addresses; the other three shortcuts are untouched. All three navigation rows now use one consistent WordPress tab styling, graded by size so the hierarchy reads at a glance. **Requires AcrossAI Pro 0.9.10+** if that add-on is active — the Connectors and n8n choices are supplied by it, and the two plugins must be updated together; an older Pro leaves those two as leftover top-level tabs until it is updated. Third-party plugins can contribute their own connection method through the new `acrossai_mcp_manager_connect_methods` filter (same entry shape as the existing tab filter, documented in `docs/extending-per-server-tabs.md`). * **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.3.3` matching the plugin header.** `Tested up to: 7.1` and `Requires at least: 7.0` unchanged from 0.3.2. = 0.3.2 = * **UI + backend — F069 Quick Setup wizard renamed to "Quick Connect via AcrossAI" everywhere (F080, #97).** Every admin surface (plugins.php row action, MCP Servers list page-title button + per-row pill, Settings-page sub-nav tab, admin-bar chip) now reads **Quick Connect via AcrossAI**. The AcrossAI parent-menu submenu and the wizard header itself use the shorter **Quick Connect** — those two surfaces already sit next to the AcrossAI logo / brand context, so the tail is redundant there (#100). Machine identifiers renamed to `quick-connect` in the same pass: URL query param (`?quick-connect=1`), REST routes (`/quick-connect/state|step|complete`), PHP namespace `AcrossAI_MCP_Manager\Admin\Partials\QuickConnect`, class `QuickConnectController`, source directories `src/js/quick-connect/` + `src/scss/quick-connect.scss`, asset directory `assets/quick-connect/`, JS bootstrap global `window.acrossaiMcpQuickConnect`, CSS classes `.acrossai-mcp-quick-connect-*`, transient key prefix `acrossai_mcp_manager_quick_connect_state_`. **Breaking change — no backwards-compat shim:** any operator bookmark against `?quick-setup=1` will 404; any external code calling the old REST route will 404; any in-flight wizard scratchpad transient at deploy time is orphaned (harmless — 30 min TTL). Wizard state, entry-point behaviour, licensing gates, and all downstream integrations otherwise unchanged. Historical `README.txt` changelog entries for 0.3.0 / 0.3.1 that mention "Quick Setup Wizard" are intentionally left as-is — they describe what shipped under that name at merge time. * **UI — Quick Connect wizard Step 10 now embeds the AcrossAI Pro per-connector walkthrough panels when the paid add-on is active (F081 + F082, #98 / #101 / #102).** When acrossai-pro 0.9.4+ is installed, Step 10 renders the same rich per-vendor walkthrough (Claude / ChatGPT / Cursor / Gemini / Grok) that the per-server **AI Connectors** admin tab shows — three sub-boxes per client with numbered instructions, an inline `
` command block for CLI paths, and a "Still stuck? Full walkthroughs..." docs footnote. F082 exposes the walkthrough HTML through its own discovery lane (`acrossai_mcp_manager_discovery_ai_connector_instructions`, mirroring the existing `..._ai_connectors` producer/consumer pattern) rather than piggybacking on the connector DTO; the pro plugin emits the HTML with a `__ACROSSAI_MCP_URL__` sentinel that Step 10 substitutes with the currently-selected server's URL client-side just before rendering (HTML-escaped). Single source of truth: `*ConnectorProfile::get_mcp_url_setup_html()` on the pro side, consumed unchanged by both this wizard AND the pro plugin's own tab — if a vendor changes their onboarding flow, one edit updates both surfaces. The rich walkthrough renders BELOW the wizard's Back / Finish footer so the primary CTA stays visible without scrolling past the guide (#102 — new `useBelowFooter()` hook on `hooks/useAdvanceGuard.js`, opt-in per step, zero effect on the other twelve). When acrossai-pro is missing or on a pre-F082 version, Step 10 falls back to today's rendering (MCP URL + Copy + "Dynamic Client Registration only" notice) — zero visual regression. Rendered via `dangerouslySetInnerHTML` trusting the paid plugin's `wp_kses_post` guarantee at the filter write boundary. Ports ~20 CSS rules from `acrossai-pro/includes/Connectors/AbstractConnectorProfile::print_setup_styles()` into `src/scss/quick-connect.scss` with a source-of-truth comment banner — identical class names on both surfaces per D50 (cross-surface visual parity via shared markup contract, F077).
* **Compatibility — Tested up to WordPress 7.1.** Minimum required version (`Requires at least: 7.0`) unchanged.
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.3.2` matching the plugin header.**

= 0.3.1 =
* **Docs — WordPress.org listing refresh: tags, short description, "under a minute" positioning, and supported-client roster updated.** `Tags:` header replaced (`mcp, ai, claude, chatgpt, cursor` → `ai assistant, chatgpt, claude, mcp, mcp-server`). Short description reframed to lead with the "Connect ChatGPT / Claude / Grok to WordPress in under a minute" hook and cite the 16-client roster. Description opening paragraph gains a second lede sentence linking the [Quick Setup wizard docs](https://acrossai.co/mcp-manager-quick-setup/) and stating the under-a-minute end-to-end setup claim; the same link + claim also lead the "How It Works" section above the six-step manual flow (kept as an alternative for operators who prefer to do it by hand). Key Features connection-guides bullet and "Which AI clients are supported?" FAQ answer now enumerate all 16 built-in clients (Claude Desktop, Claude Code, VS Code, GitHub Copilot, Codex, Cursor, Gemini CLI, Windsurf, Zed, Cline, Roo Code, Kilo Code, Amazon Q Developer, OpenCode, Antigravity, Custom Client). Paid AcrossAI Pro OAuth Connectors (ChatGPT / Claude / Grok / Gemini / Cursor) are called out as a separate optional add-on. No behavioural change; readme-only refresh.
* **Fix — VS Code + GitHub Copilot user-level MCP config path corrected (F078).** Previously shipped `~/.vscode/mcp.json` (Cursor's convention, not VS Code's). Now ships the documented macOS user-level path `~/Library/Application Support/Code/User/mcp.json` for both clients. Instructions also mention the `Cmd/Ctrl + Shift + P → "MCP: Open User Configuration"` menu entry. GitHub Copilot restart phrasing now correctly explains that Copilot Chat needs to be in Agent mode and VS Code auto-starts the server. Fix cites [VS Code MCP docs](https://code.visualstudio.com/docs/agents/reference/mcp-configuration) and [Copilot MCP docs](https://code.visualstudio.com/docs/copilot/customization/mcp-servers) — see `specs/078-client-config-upstream-fixes/research.md`. The audit that surfaced this fix (4 parallel research agents across all 16 clients) also verified 7 other clients had drift; those fixes are deferred to a follow-up PR pending review.
* **Fix — Local dev sites now auto-inject `NODE_TLS_REJECT_UNAUTHORIZED: "0"` into the copied MCP client JSON and surface an Automattic troubleshooting link (F075).** When the environment looks local (`wp_get_environment_type()` returns `local` or `development`, or the host is `localhost` / `127.0.0.1` / `::1`, or ends with `.local` / `.test` / `.localhost`) — regardless of whether the site is served over HTTPS or plain HTTP — every generated client snippet (all 16 clients: Claude Desktop, Claude Code, Cursor, VS Code, GitHub Copilot, Codex, Gemini, Windsurf, Zed, Cline, Roo Code, Kilo Code, Amazon Q, OpenCode, Antigravity, Custom) now carries the flag in its `env` block, and a static warning notice above the JSON on both surfaces (per-server **MCP Clients** tab and Quick Setup wizard **Step 11**) explains what was added and why, with a link to Automattic's mcp-wordpress-remote troubleshooting doc. Fixes the "MCP client connects but the tool list stays empty" symptom on Local by Flywheel / MAMP / DDEV / wp-env style installs — the flag is the real fix when the local site uses HTTPS with a self-signed certificate, and a harmless no-op on plain HTTP (Node's HTTP client never runs TLS validation) — but the warning + doc link is useful in both cases. Live sites are unaffected: on a real production install (`wp_get_environment_type() = production`, non-local hostname), the injection does not occur and no notice renders. Ops teams that self-host on custom suffixes (`.docker`, `.internal`, `.dev`) can extend the host-suffix list via the new `acrossai_mcp_local_hostname_suffixes` filter. Internal refactor: all 16 clients' `env` arrays are now built via a shared `AbstractMCPClient::build_env()` helper — the previous 16-way duplication of the standard env-key list is retired in the same pass.
* **UI — Client picker emojis removed on both admin surfaces (F076).** The per-server MCP Clients tab pill sub-nav and Quick Setup wizard Step 11 client-picker buttons now render each client's name only — no leading emoji glyph. The `get_icon()` methods on all 16 client classes stay defined (so companion plugins reading the ConnectionMethodRegistry DTO's `icon` field still see the value); only the two visible pickers stop rendering it.
* **UI — Per-server MCP Clients tab now uses the same numbered STEP 1..5 walkthrough as the Quick Setup wizard's Step 11 (F077).** The admin tab's client-detail area is reorganized under STEP 1 (Generate the password) → STEP 2 (Open the config file) → STEP 3 (Locate the top-level key) → STEP 4 (Copy this config and paste it under the top-level key — includes the local-dev warning + JSON + Copy button) → STEP 5 (Restart the MCP client — client-specific action). Same content as before; consistent visual scaffolding between the two surfaces.
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.3.1` matching the plugin header.**

= 0.3.0 =
* **Admin — MCP Quick Setup Wizard (F069, F072, F073, F074).** New guided React admin wizard that condenses the plugin's 11-tab per-server-edit surface into a single linear configuration flow — a dynamic 5-to-10-step flow across 13 total steps driven by 10 skip predicates. Auto-redirects on activation to Step 1 with the seeded default server preselected; always reachable from a persistent top-admin-bar chip and four everyday entry points (plugins.php row action next to Settings, submenu under the AcrossAI menu, `page-title-action` on the MCP Servers list header, and a per-row quicklink pill in the Actions cell). Step index + optional `?server=` live in the URL, so browser Back/Forward and shareable deep-links work. Every step's answers persist to a per-user 30-min transient scratchpad; all authoritative writes delegate to existing plugin APIs — no existing tab, REST route, or DB schema is changed. Step 11 reaches feature parity with the per-server-edit **MCP Clients** tab (all 16 client sub-nav entries), and an in-wizard app-password generation step removes the round-trip to the WP user profile page. F074 adds a Pro setup step for the Connectors branch (steps 8–9) gated by a new `acrossaiProLicensed` field on `GET /quick-setup/state`, which delegates to acrossai-pro's own Freemius `can_use_premium_code()` predicate — the wizard and the plugin can never disagree about what "licensed" means. Opting into the free version returns false and blocks the branch, which is the point: Connectors is unusable without a licence. Fully additive — every existing route/tab still works exactly as before for operators who prefer the traditional flow.
* **Fix — Quick Setup Wizard: Step 3 "Save and Continue" now advances on the first click.** Previously required two clicks — the first saved the access-control rule and moved the URL to `step=4` but the rendered step snapped back to 3. Root cause was two compounding defects in `useWizardRouter`: (1) the hook returned a fresh object literal on every render, cascading through `advanceFromContext` → `guardContext` → the step's `onClick` → `footerAction` → `useFooterAction`'s effect into a self-sustaining passive-effect loop (React logged "Maximum update depth exceeded"); (2) the guarded advance re-read stale state before the previous `setState` had flushed. Fix stabilises the router reference and threads the fresh state through the guard synchronously. Affected every step registering a footer action — 3, 5 and 6.
* **Feature — 8 new MCP client integrations (F071): Windsurf, Zed, Cline, Roo Code, Kilo Code, Amazon Q Developer, OpenCode, Antigravity.** Doubles the built-in registry from 8 → 16 clients. Every consumer (wizard Step 7 method grid, Step 11 client detail sub-nav, admin snippet display) picks the new clients up automatically via `AbstractMCPClient::get_all_registered_clients()` — zero React changes. Two non-standard entry shapes preserved inline per D-071-03: **Zed** uses a `context_servers` top-level key with `source: 'custom'` + `enabled: true` prefix before the standard `command`/`args`/`env` fields (Zed runtime requirement); **OpenCode** uses an `mcp` top-level key with `type: 'local'`, `command` as a JSON array, and env vars under `environment`.
* **Fix — Companion add-on slug updated `acrossai-ai-connectors` → `acrossai-pro`.** `AIConnectorsPromoTab::SIBLING_SLUG` now matches the renamed paid plugin (`acrossai-pro/acrossai-pro.php`), which is what the shared Add-ons page installs and what registers the real `AIConnectorsTab` via `acrossai_mcp_manager_server_tabs` at priority 35. Without this, `find_sibling_plugin_file()` never located the add-on: the installed-but-inactive state was misread as not-installed, and the "Activate add-on" CTA could not build its `plugins.php?action=activate` nonce URL. Docblock references in `admin/Partials/ServerTabs/Registry.php` refreshed to the new slug. Historical F040 migration comments elsewhere still name the old slug intentionally — they describe what happened at the time.
* **UI — Connectors/Integrations promo card: trial-first CTA + launch-offer banner.** On the per-server-edit **Connectors/Integrations** tab (`?page=acrossai_mcp_manager&action=edit&server=&tab=ai-connectors`), the promo card shown when AcrossAI Pro is missing or inactive gains: (1) a full-bleed gradient banner across the card's top edge — "Start today — free for 30 days." / "No credit card required." with a white pill **Start free trial** button linking to `https://acrossai.co/pricing/` in a new tab — rendered in both promo states (not-installed and installed-but-inactive); (2) the not-installed primary CTA relabelled **Install add-on** → **Start free trial**, pointing at the pricing page instead of the shared Add-ons page (new `PRICING_URL` constant; the `ADDONS_PAGE_SLUG` constant and `resolve_install_url()` helper are removed). The installed-but-inactive CTA is unchanged — still "Activate add-on" with its nonced same-tab activate link — and the active state still renders no card at all.
* **Copy — Supported AI clients expanded to Claude, ChatGPT, Grok, Gemini, and Cursor.** Promo-card headline and client pills updated; `README.txt` Connection Types bullet and the "Do I need the paid AI Connectors add-on?" FAQ answer list all five and now link to the AcrossAI Pro pricing page rather than the retired `acrossai.co/ai-connectors/` plugin page.
* **Admin — Plugins.php Settings link retargeted to the shared AcrossAI Settings page's MCP tab.** Plugin action-link **Settings** on `/wp-admin/plugins.php` now points at `?page=acrossai-settings&tab=mcp` instead of the plugin's own top-level page. That tab now renders a three-item sub-nav at the top of the body — **Servers** / **Settings** / **Quick Setup** — via a title-less `add_settings_section` callback so it inherits the tab-scoped page-slug lifecycle. Uses WordPress-native `.nav-tab-wrapper` markup for visual parity with other tabbed admin surfaces. URL constants reused (`SettingsPage::SETTINGS_SLUG` + `SettingsMenu::TAB_SLUG`) so a future rename of either symbol propagates.
* **Admin — npm/CLI login enabled by default on activation (D44).** `add_option( 'acrossai_mcp_npm_login_enabled', 1 )` added in `Activator::activate()` — fresh installs now expose the CLI login flow without the admin needing to check the box first. `add_option()` is idempotent (WP core: "fails silently if the option already exists"), so sites that explicitly stored `0` (unchecked + saved) keep their disabled state. No changes to `register_setting()`'s metadata default (stays `false`) or to any `get_option()` fallback (the row is always present post-activation, so fallbacks never fire).
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.3.0` matching the plugin header.**

= 0.2.10 =
* **Admin — Embeds tab hidden from the per-server-edit page.** The **Embeds** tab (formerly reached at `?page=acrossai_mcp_manager&action=edit&server=&tab=embeds`) is no longer registered in `Registry::all_tabs()` and its self-registration in `Main::define_public_hooks()` (`EmbedsTab::register()`) is now commented out — so the tab's REST controller (`/acrossai-mcp-manager/v1/servers/{server_id}/embeds`) and its React bundle (`build/js/embeds.js` + `.css`, ~389 KiB) no longer enqueue on the server-edit screen. Direct URL access to `?tab=embeds` falls through to Registry's default (first surviving tab = Overview) rather than 404 — same graceful-fallback path any unknown slug takes. Built-in tab count: 12 → 11. The `admin/Partials/ServerTabs/EmbedsTab.php` class file, the underlying `[acrossai_mcp_embed]` shortcode, the block, and the `AbstractEmbedTransport` transports in `includes/Embeds/` are all retained — hiding is admin-UI-only; the frontend embed rendering pipeline is unaffected. Re-enabling the tab is a two-line change (re-add `EmbedsTab::instance()` to Registry + uncomment the `register()` call). Tests in `tests/phpunit/Admin/ServerTabs/RegistryTest.php` updated: expected counts adjusted (12 → 11 for canonical + database-source servers; 10 → 9 for plugin-source servers); ordering array + docblock counts refreshed; a new `assertNotContains( 'embeds', $slugs )` line locks in the invariant.
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.2.10` matching the plugin header.**

= 0.2.9 =
* **Dependencies — bump `acrossai-co/main-menu` `0.0.31` → `0.0.33`.** The upstream vendor renamed its "AI Connectors" baseline Add-ons entry to **AcrossAI Pro** in `0.0.32` — the shared Add-ons page (`admin.php?page=acrossai-addons`) and Dashboard card now advertise the renamed plugin (`acrossai-pro/acrossai-pro.php` install folder, `acrossai-pro` registry slug) instead of the former AI Connectors listing. `0.0.33` refreshed the AcrossAI Pro card copy — description now also mentions user access control across AcrossAI plugins — and points every AcrossAI Pro CTA (Add-ons card `more_url` / `learn_more_url`, Dashboard primary/secondary CTAs) at `https://acrossai.co/pricing/#pricing`. **No changes required in this plugin:** MCP Manager's `AddonsFilter::remove_self()` filters the `acrossai_addons` list by its own slug (`acrossai-mcp-manager`), so the vendor's baseline entry rename doesn't affect what shows on the Add-ons page here. The per-server-edit **Connectors/Integrations** tab still points at the separate `acrossai-ai-connectors` WordPress plugin (WP plugin folder slug, distinct from the vendor's addons-registry slug), so the promo card + CTA are unaffected. Transitive: `automattic/jetpack-autoloader` `v5.0.21` → `v5.0.23` (patch).
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.2.9` matching the plugin header.**

= 0.2.8 =
* **⚠️ Security — Behavior change — MCP `resources/read` and `prompts/get` requests are now gated by the per-server Access Control rule (F1 fix).** Prior to 0.2.8 the plugin only hooked the vendor's `mcp_adapter_pre_tool_call` filter. The two sibling pre-dispatch filters — `mcp_adapter_pre_resource_read` (`vendor/wordpress/mcp-adapter/includes/Handlers/Resources/ResourcesHandler.php:138`) and `mcp_adapter_pre_prompt_get` (`.../Prompts/PromptsHandler.php:157`) — had no subscriber. Combined with the Feature 042 transport layer intentionally deferring to F015 for rule-configured servers (returning the vendor `'read'` default so any authenticated user passes the transport gate, on the assumption that F015 would then enforce), any authenticated user could `POST {"method":"resources/read","params":{"uri":"…"}}` (or `{"method":"prompts/get"}`) against a server configured "Editors only" and the operator's rule was **never consulted**. 0.2.8 extracts the enforcement body of `gate_mcp_tool_call` into a shared private `apply_ac_gate()` helper and adds two sibling public callbacks — `gate_mcp_resource_read` + `gate_mcp_prompt_get` — wired adjacent to the existing tool-call filter in `Main::define_public_hooks()`. Deny path returns a `WP_Error` with a `gate` value of `mcp_resource_read` / `mcp_prompt_get` (previously always `mcp_tool_call`). Observability hooks are reused: `acrossai_mcp_access_control_denied` and `acrossai_mcp_access_control_missing_server` now fire from three MCP boundary sites — the `$context` arg discriminates and the `$subject` arg is polymorphic (tool name / resource URI / prompt name depending on which gate fired). New PHPUnit coverage at `tests/phpunit/Includes/AccessControl/McpDispatchGatesTest.php` — fail-open parity per gate, missing-server observability hook subject-arg carries URI/prompt name, three-context deny-hook contract, all three vendor filter registrations verified.
    * **Operator action if you were relying on the resource/prompt bypass**: audit any server that exposes MCP resources or prompts AND has a rule configured. Non-privileged users who previously succeeded on `resources/read` / `prompts/get` will now receive HTTP 403 with the same `acrossai_mcp_access_denied` error code the tool-call gate has emitted since 0.0.7. Broaden the rule in the **Access Control** tab if the previous fail-open was intended (unlikely — most operators wanted the rule to apply).
* **⚠️ Security — Behavior change — F042 transport layer now fails CLOSED when the wpb-access-control vendor package is unavailable (F2 fix).** Prior to 0.2.8 both access-control gates failed OPEN under the same condition: `AcrossAI_MCP_Access_Control::gate_mcp_tool_call` returned `$args` (allow) when `class_exists( AccessControlManager::class )` was false; `TransportPermissionDefault::filter_default_capability` returned the vendor `'read'` default under the mirror condition (`class_exists( RuleQuery::class )`). Because both gates degraded in the same direction, a single dependency failure — composer breakage, autoloader race on `rest_api_init`, missed dependency after site clone, vendor package rename — collapsed the entire two-gate stack, letting every authenticated user reach every tool on every server. 0.2.8 inverts F042's missing-vendor branch to return `'manage_options'` instead. Paired with F015's fail-open on the same condition, the stack now degrades to **admin-only** rather than "wide open to every logged-in user" when the vendor library is missing. Class docblock on `TransportPermissionDefault` explicitly documents the intentional asymmetry — "F015 fails open + F042 fails closed = admin-only when the vendor breaks" — so the invariant survives future refactors. The `class_exists()` call is now behind a protected `has_access_control_library()` seam to enable direct test coverage (`tests/phpunit/Includes/AccessControl/TransportPermissionMissingVendorTest.php`).
    * **Operator action**: none in the healthy-vendor case (Composer install intact). If your deploy pipeline can produce a state where `vendor/wpboilerplate/access-control` is absent, non-admin MCP traffic will now receive 401 instead of full access. Restore the vendor package and MCP endpoints resume normal per-rule enforcement.
* **Admin — Server list at `?page=acrossai_mcp_manager` redesigned for a tighter, more actionable layout.** Column changes: **removed** Slug (redundant with the Route/Route Namespace columns and the Name column's inline edit link), Route Namespace + Route **merged** into a single `Route` column displayed as `/` with duplicate slashes at the join collapsed, **removed** Version (still surfaced on the per-server-edit Overview tab). Final column order: `☐ | Name | Status | Registered From | Route | Actions`. **Actions column extended** — the existing Enable/Disable toggle is now bundled with 5 quick-access buttons: **Edit** (primary-styled) links to the server-edit page, and four per-tab quick-links (**Connectors**, **Access Control**, **Abilities**, **MCP Clients**) jump directly to the corresponding tab on the edit page. Quick-links render as subtle rounded pill-badges with a dashicon prefix (`dashicons-admin-plugins` / `dashicons-shield` / `dashicons-superhero-alt` / `dashicons-admin-users`) — lighter than full buttons but more scannable than plain text links. New `.acrossai-actions-cell` flex wrapper in `src/scss/backend.scss` keeps the button cluster wrapping cleanly on narrow viewports; Status + Registered From columns capped at 120px so the freed horizontal space flows to Route + Actions. Preserves the existing per-row nonce on the Enable/Disable toggle. No DB or REST changes.
* **UI — AI Connectors tab renamed to "Connectors/Integrations".** The per-server-edit tab label at `?page=acrossai_mcp_manager&action=edit&server=&tab=ai-connectors` now reads **Connectors/Integrations** instead of "AI Connectors". Tab slug (`ai-connectors`) is intentionally unchanged so the last-wins tab-registration override from the `acrossai-ai-connectors` companion plugin keeps landing on the same placeholder — no companion-plugin coordination required. `AiConnectorEmbedTransport::label()` (a separate F037 embed transport) is left as-is; only the per-server-edit tab label is affected.
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.2.8` matching the plugin header.**

= 0.2.7 =
* **Docs — Fixes for the WordPress.org plugin import.** Trimmed the `Tags:` header from 8 tags to 5 (`mcp, ai, claude, chatgpt, cursor`) — WordPress.org silently drops any tag past the fifth; the surplus (`copilot`, `vscode`, `gemini`) never showed up in the plugin listing anyway. Condensed the changelog for versions prior to `0.2.0` into a single "Earlier versions" pointer to the GitHub Releases page so the full changelog stays under WordPress.org's 5,000-word cap (previously ~8,258 words → the older entries were truncated on import and never rendered on the plugin page). Same information, still discoverable — just hosted on GitHub instead of duplicated in `README.txt`.
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.2.7` matching the plugin header.**

= 0.2.6 =
* **Refactor — `ConnectionMethodRegistry::get_ai_connectors()` now sources its DTOs from a new WordPress filter `acrossai_mcp_manager_discovery_ai_connectors` instead of calling the companion plugin's `ConnectorProfileRegistry` class directly.** The paid companion (`acrossai-pro` 0.8.0+) hooks the new filter and returns the same DTO shape from its own registry — Discovery's `ai_connector` category behaves identically for end users. Removes a hardcoded FQN string (`\AcrossAI_AI_Connectors\Includes\Connectors\ConnectorProfileRegistry`) from the free plugin so future companion renames / restructures don't silently break Discovery. Fail-safe unchanged: with no companion active, the filter returns an empty array and the `ai_connector` category is omitted from Discovery — no fatal, no warning.
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.2.6` matching the plugin header.**

= 0.2.5 =
* **⚠️ Security — Behavior change — MCP endpoints default to administrators only when no Access Control rule is set (Feature 042).** Previously, an MCP server with no rule configured in its **Access Control** tab was fail-open at the tool-call layer — any authenticated user could reach the server's `/wp-json/{namespace}/{route}` endpoint. Starting with 0.2.5, a new runtime filter (`mcp_adapter_default_transport_permission_user_capability`, hooked by the new `\AcrossAI_MCP_Manager\Includes\AccessControl\TransportPermissionDefault` singleton) hard-blocks non-admins at the REST `permission_callback` stage whenever the wpb-access-control dropdown reads **"No user access added by admin"**. Together with the existing F015 `mcp_adapter_pre_tool_call` gate, this ships a **two-filter, per-server permission stack** (defense-in-depth): filter 1 hard-stops non-admin traffic on rules-less servers; filter 2 does precise per-rule enforcement on rule-configured servers. **Neither filter has any hardcoded server slug or "default server special case"** — both resolve the current server independently per request (filter 1 via URL route → `MCPServerQuery` lookup; filter 2 via `$server->get_server_id()`). Adding a server via **Add New Server** applies both filters automatically. **Zero DB writes** — the runtime filter approach replaced an earlier DB-row-seeding attempt (dropped via force-push on PR #71) that conflicted with the vendor UI's admin state model. Ships with a static info banner on the **Access Control** tab describing the default policy + how to broaden access via the vendor dropdown (Anyone / Authenticated users / role / user / capability). **26 PHPUnit tests** across 2 files at `tests/phpunit/Includes/AccessControl/` (`TransportPermissionDefaultTest` + `TransportPermissionRoleMatrixTest`) cover every filter-callback branch in isolation plus 6 user roles × 4 rule shapes × ≥4 servers per test end-to-end (including a 5×4 truth-table matrix proving per-server independence).
    * **Operator action if you were relying on the fail-open default**: open each MCP server's **Access Control** tab, set the "Who can access" dropdown to the intended rule (e.g. `WordPress role → Editor` or `Anyone` for the previous behavior), and Save. Rules-less servers are now admin-only until you configure them.
* **UX — Cache-exclusion warning surfaces in the shared Notices submenu when the CLI (npm/npx) connection flow is enabled (Feature 041).** When **Settings → MCP → Allow CLI connections via npm / npx** (`acrossai_mcp_npm_login_enabled`) is ON, a persistent warning card now appears in the AcrossAI **Notices** submenu (and in the WP-native dismissible summary) instructing operators to exclude the CLI auth URL (`https:///acrossai-mcp-manager/`) from page caching. The URL carries per-request nonces + single-use auth codes; caching plugins that treat it as static content silently break the login flow. The existing inline banner in the settings section is preserved — this feature adds a second, higher-visibility surface that co-admins and future visitors see even if they never open the specific settings section. Notice id `acrossai_mcp_manager_cli_auth_cache_exclusion`, source `MCP Manager`, gated on the option value. Uses `FrontendAuth::get_base_url()` for the URL — any future change to the CLI landing route propagates automatically.
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.2.5` matching the plugin header.**

= 0.2.4 =
* **Dependencies — bump `wpboilerplate/wpb-access-control` `2.0.0` → `3.1.0`.** Two vendor changes surface in the per-server **Access Control** tab (`?tab=access-control`): (1) new **"Any logged-in user"** option in the *Who can access* dropdown — backed by the new `TYPE_AUTHENTICATED` sentinel in `AccessControlManager` (returns `true` iff `$user_id > 0`), and (2) the existing "Everyone (no restriction)" option is relabelled **"Public (no login required)"** — pure UI relabel, same underlying behavior (`TYPE_EVERYONE` unchanged, existing rules unaffected). v3.0.0 also removed the built-in `BuddyBossProfileTypeProvider` + `MemberPressMembershipProvider` (moved to a separate `acrossai/user-access-pro` add-on); this plugin never wired them into the *Who can access* dropdown, so removal has no visible effect here. Docblock at `includes/Main.php` refreshed to drop the stale BuddyBoss/MemberPress reference. No data migration required.
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.2.4` matching the plugin header.**

= 0.2.3 =
* **UX — In-context nudges to install the AcrossAI Abilities Manager add-on.** When the sibling `acrossai-abilities-manager` plugin is not active, the server-edit **Abilities** and **Tools** tabs (`?tab=abilities` / `?tab=tools`) now surface a small WordPress-native `notice-info` block above the picker with a link to the shared Add-ons page (`admin.php?page=acrossai-addons`). Without the add-on both pickers only list the three core abilities WordPress ships by default (`core/get-environment-info`, `core/get-site-info`, `core/get-user-info`); the add-on registers a rich library of built-in abilities that populate both surfaces. Detection is a plain `is_plugin_active()` check — same message + same link covers both "not installed" and "installed-but-off" states. Placed after the existing "Server is disabled" warning and before the `wp_get_abilities()` capability check, so the nudge is visible even when the abilities API itself is missing.
* **UI — AcrossAI brand logo on the AI Connectors placeholder tab.** Replaces the hand-rolled interconnected-nodes SVG on the AI Connectors placeholder promo (`?tab=ai-connectors` when the `acrossai-ai-connectors` companion is missing / inactive) with the same brand SVG the vendor uses on the shared Add-ons page (`https://acrossai.co/wp-content/uploads/2026/07/acrossai-logo-2.svg`). New `LOGO_URL` class constant on `AIConnectorsPromoTab`; icon markup swapped from an inline `` inside a gradient tile to a plain `AcrossAI` tag; deleted the private `render_network_svg()` method (dead code). CSS: dropped `.acai-aic-promo__icon` (gradient background + colored SVG) in favor of `.acai-aic-promo__logo` (`height: 48px; max-width: 180px; object-fit: contain`) so the brand mark sits cleanly without a decorative background box.
* **Refactor — Renamed the "MCP Tracker" tab to "Logs".** The per-server tab formerly reached at `?tab=mcp-tracker` is now `?tab=mcp-log`, and the tab-bar label reads **Logs** instead of **MCP Tracker**. Priority slot 80 preserved so the tab-bar ordering is unchanged. Class name `McpTrackerTab` kept (internal identifier) along with the body copy that identifies the third-party [MCP Tracker plugin on WordPress.org](https://wordpress.org/plugins/mcp-tracker/) (WPVMCPT) product name — those aren't the tab label, they're a specific product reference. Deep links to the old `?tab=mcp-tracker` fall through to Registry's "first surviving tab" default (Overview) rather than 404. Test fixture updated: five `'mcp-tracker'` occurrences in `RegistryTest.php` migrated to `'mcp-log'`.
* **Docs — Rewrote `README.txt` as a lean docs-hub pointer.** The plugin's WordPress.org readme now defers to [acrossai.co/doc-category/mcp-manager](https://acrossai.co/doc-category/mcp-manager/) as the source of truth for every feature description — copy lives in one place instead of drifting between two. Description condensed to a two-line multi-client pitch; **Key Features** reshaped to reflect the current feature set (multiple servers per site, per-server tool/ability curation, per-server access control, frontend embeds, CLI + WP-CLI STDIO transports) with each bullet linking to its docs page; **How It Works** trimmed to the 6-step get-started path; new **Connection Types** section calls out the four supported paths (MCP Client, CLI Connections, WP-CLI STDIO, and the paid [AI Connectors add-on](https://acrossai.co/ai-connectors/)); **Requirements** bumped to WordPress 7.0+ / PHP 8.1+ (matches the plugin header — old readme had drifted to 5.9 / 7.4); FAQ trimmed from 7 questions to 5 with a new "Do I need the paid AI Connectors add-on?" entry; new **Support** section links to docs hub, FAQ page, and GitHub issue tracker. Header tags expanded (`chatgpt`, `cursor`, `gemini` added). Deleted the stale post-F040 **Experimental Direct Claude Connectors** section, the CLI-flow deep dive, and the Provider Configuration Paths list — those live in the docs now.
* **Internal: `ACROSSAI_MCP_MANAGER_VERSION` constant + `Stable tag` bumped to `0.2.3` matching the plugin header.**

= 0.2.2 =
* **Notices — migrated persistent-condition banners to the cross-plugin `acrossai_notices` filter.** The "MCP adapter package missing" and "wpb-access-control library missing" warnings no longer render as inline `admin_notices` banners on every screen. They're pushed into the shared collection introduced in `acrossai-co/main-menu` 0.0.30, which surfaces them in two consolidated places: (1) a **Notices submenu** under the AcrossAI parent menu (with a count bubble; the page also stays reachable when the count is zero and renders an "All clear" empty state per the 0.0.31 fix) and (2) a **single WP-native dismissible summary** on every other admin page. Dismissal is now fingerprint-based (per-user meta `_acrossai_notices_summary_fp`) — adding, resolving, or renaming a notice re-shows the summary automatically. **Deletions**: `Notices::render_missing_adapter_notice`, `Notices::handle_adapter_notice_dismissal`, `ADAPTER_DISMISS_META_KEY`, `ADAPTER_DISMISS_NONCE_ACTION`, `AcrossAI_MCP_Access_Control::maybe_show_library_notice`, and the US4 dismiss-persistence handler in `src/js/backend.js` — all obsoleted by the shared summary. **Additions**: `Notices::register_shared_notices()` returns records with ids `acrossai_mcp_manager_adapter_missing` (type `error`) and `acrossai_mcp_manager_wpb_access_control_missing` (type `warning`), both scoped with `source: 'MCP Manager'`. One-shot action-result flashes (`?notice=`) stay on the standard `admin_notices` hook — page-scoped transient messages don't fit the shared collection model.
* **UI — Redesigned the AI Connectors placeholder tab as a centered sales card.** When the `acrossai-ai-connectors` companion add-on is not installed or not active, the AI Connectors tab on the server-edit page (`?page=acrossai_mcp_manager&action=edit&server=&tab=ai-connectors`) now renders a vertically-centered polished card sourced from https://acrossai.co/ai-connectors/ — headline ("Connect WordPress to Claude, ChatGPT & Grok in one click"), supported-client pills (Claude · ChatGPT · Grok), four benefit bullets, a purple CTA ("Install add-on" / "Activate add-on" depending on companion state), a "Learn more" link, and a 14-day money-back trust line. State resolution unchanged — Registry's last-wins dedup at priority 35 still swaps the placeholder out for the companion's real `AIConnectorsTab` the moment the add-on activates.
* **Dependencies: bump `acrossai-co/main-menu` `0.0.29` → `0.0.31`.** 0.0.30 shipped the shared `acrossai_notices` filter + Notices submenu + `SummaryNoticeEmitter`. 0.0.31 fixed a "Sorry, you are not allowed to access this page." error on direct visits to `admin.php?page=acrossai-notices` when the notice count was zero (page callback is now always wired; empty-state sidebar row is hidden via inline `