AcrossAI MCP Manager

Changelog

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=<id> 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=<id>&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=<id>&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 <namespace>/<route> 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=<id>&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://<site>/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 <svg> inside a gradient tile to a plain <img alt="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 (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 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); 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=<slug>) 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=<id>&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 <style> on admin_head rather than remove_submenu_page(), which had desynced $_registered_pages).
• Internal: ACROSSAI_MCP_MANAGER_VERSION constant + Stable tag bumped to 0.2.2 matching the plugin header (backfills the Stable tag drift that persisted since 0.2.0).

0.2.1

• Security — Defended REST + AJAX response paths against full-page cache poisoning. Full-page caches (LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Super Cache, host-level FastCGI cache) don’t honor arbitrary Cache-Control: no-store headers when making caching decisions — they gate on DONOTCACHEPAGE (WordPress-community convention) and their admin exclusion list. Companion fix to acrossai-ai-connectors 0.5.3 PR #13 (DEC-OAUTH-DONOTCACHEPAGE-PATTERN). New includes/Utilities/CacheHeaders.php — port of the utility from acrossai-ai-connectors — applies a three-pronged defense (constant + headers + WP filter) on every per-session and per-server response emission surface: GET /servers/{id}/abilities, GET /servers/{id}/tools, GET /auth/status, GET /servers, POST /auth/start, POST /auth/exchange, POST /generate-app-password, and the wp_ajax_acrossai_mcp_dismiss_adapter_notice AJAX endpoint. Prevents cross-server data leaks (per-server ability/tool rosters bleeding into other sessions) and stale-response classes (cached {approved:false} served after the flip to true). Also fixes plugin-header vs ACROSSAI_MCP_MANAGER_VERSION constant drift — B5 bug pattern (constant lagged at 0.1.9 while header sat at 0.2.0). Both now aligned at 0.2.1.

0.2.0

• Dependencies: bump acrossai-co/main-menu 0.0.27 → 0.0.29. Picks up the shared main-menu package’s latest baseline for the 0.2.0 release cycle.
• Feature 040 — Migrated the AI Connectors + OAuth stack to the companion plugin acrossai-ai-connectors (v0.5.0+). MCP Manager now ships only the free-tier tab=npm and tab=clients connection paths; the OAuth click-to-connect flow (Claude Web, ChatGPT connectors, Grok) plus the AI Connectors admin tab now live in the paid acrossai-ai-connectors add-on. Token / client / auth_code storage is unchanged — same table names (wp_acrossai_mcp_oauth_clients, _tokens, _auth_codes, wp_acrossai_mcp_connector_approved_users), same BerlinDB db_version_keys, no data migration. REST namespace kept as acrossai-mcp-manager/v1 for RFC 8414 discovery compatibility. Existing Claude/ChatGPT/Grok OAuth connections continue to authenticate transparently when the add-on is installed — zero re-authorization required. Free users updating without the add-on are undisturbed (mcp-manager remains standalone-activatable; the AI Connectors tab simply doesn’t appear). Deletions: entire includes/OAuth/, includes/Connectors/, includes/Database/{OAuthClients,OAuthTokens,OAuthAuthCodes,ConnectorApprovedUsers}/, admin/Partials/ServerTabs/AIConnectorsTab.php, templates/oauth/consent.php, src/js/ai-connectors.js, src/scss/ai-connectors.scss, all build/js/ai-connectors.* artifacts, and all associated PHPUnit tests. Modifications: Activator.php, Deactivator.php (retains unconditional cron-clear as belt-and-suspenders per FR-004), Main.php (drops all OAuth REST route + infra wiring + 4 OAuth-table bootstrap/reconcile calls), admin/Main.php (drops maybe_enqueue_ai_connectors_app()), admin/Partials/ServerTabs/Registry.php (drops built-in AIConnectorsTab entry — companion re-registers via existing acrossai_mcp_manager_server_tabs filter at priority 35), uninstall.php (drops OAuth DROP TABLE lines + cron-clear + narrows the acrossai_mcp_% option sweep to exclude acrossai_mcp_connector_%), webpack.config.js (drops js/ai-connectors entry), and public/Discovery/ConnectionMethodRegistry.php (FR-019: swaps ConnectorProfileRegistry FQN to the companion namespace and guards with class_exists() so the discovery API returns an empty ai_connector category when the add-on is absent). Coordination invariant: the companion at v0.5.0+ has been audited across 44 checks (23 structural readiness + 21 wiring counterparts) and is deployable — the migration is atomic via the companion’s class_exists( '\AcrossAI_MCP_Manager\Includes\OAuth\AuthorizationController' ) self-disable probe. No compat shim, no Requires Plugins: header, no admin notice — per clarifications Q4/Q5/Q6, this feature adds ZERO new code (pure deletions + header version bump). Durable lesson captured: when a subsystem gets its own plugin, prefer code-only migration (identical table names, identical version keys, byte-identical BerlinDB Table subclass declarations) over data-migration.

Earlier versions

• For changelog entries prior to 0.2.0 (versions 0.1.9 → 0.0.1), see the full release history on GitHub: https://github.com/acrossai-co/acrossai-mcp-manager/releases