v1.27.1 — Angie bridge fixes from the first live run
Patch release. Both fixes came out of the first live run of the Angie bridge (WP 6.9 / Elementor 4.2.2 / Angie 1.1.11) — the K3 smoke test — and landed after the v1.27.0 tag, so the 1.27.0 build does not contain them.
The bridge never loaded in the Elementor editor
The one surface it exists for. Its bundle was registered on admin_enqueue_scripts, which the editor never fires: that screen is rendered from admin_action_elementor, before admin-header.php, and Elementor then calls remove_all_actions( 'wp_enqueue_scripts' ) and rebuilds a front-end style document from its own hooks. The bridge now also rides elementor/editor/after_enqueue_scripts — the hook Angie's own editor integration uses — and guards against a double localize, since wp_localize_script() prints a script tag on every call.
The registration promise was meaningless
The bridge called registerServer() with a config carrying no type. The SDK answers that with a warning and hands off to registerLocalServer() without awaiting it, so the promise resolved before the registration had begun and a failure inside it could never reach the catch. It now calls registerLocalServer() directly.
Registration state is now observable
window.emcpAngieBridgeDebug exposes isAngieReady(), registrations() and pending(). A registration that stays queued is otherwise indistinguishable from a successful one: nothing throws, nothing logs, the tools simply never appear — which is exactly the state the smoke test was stuck in. It exposes state, not authority: every tool call still goes through the REST routes, the server-side allowlist, the read-only invariant, and each ability's own permission callback.
Verified live
Angie discovers the six read-only tools and executes them — list-pages, list-global-classes and list-variables all returning 200 through emcp/angie/v1/execute/.
Worth knowing: the bridge's tool list is independent of the admin Tools toggles. Every ability is registered with the Abilities API regardless; the elementor_mcp_ability_names filter only trims the list handed to the MCP Adapter server, and the bridge resolves its own allowlist through wp_get_ability().
Full details in CHANGELOG.md.