AcrossAI MCP Manager

Registro de cambios

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 <pre> 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 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 and Copilot MCP docs — 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=<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. …