msrbuilds/elementor-mcp v3.12.2

v3.12.2 — lighter on memory, Kadence auto-repair, non-Pro fix

on GitHub

Added

• Kadence blocks inserted by AI now auto-repair in the editor. Kadence blocks use a static JS save() the server cannot run, so blocks inserted through the tools rendered perfectly on the front end but showed "Attempt recovery" on every block in the editor. EMCP now runs that recovery automatically: when you open a post the AI added Kadence blocks to, the editor repairs each of them with its own recovery mechanism (regenerating the markup with Kadence's own save(), content preserved), shows a single notice, and one click on Update stores the clean markup for good. No more clicking "Attempt recovery" block by block. Other static-save block packs can opt in via the emcp_tools_block_repair_namespaces filter.

Fixed

• detect-elementor-version failed on sites without Elementor Pro (#116). The tool declared its elementor_pro_version output as a string but returned null when Elementor Pro was not installed, and WordPress validates an ability's output against that schema, so the call errored out instead of answering. It now returns an empty string, matching how the core version already reports "not detected". This one bit every free-Elementor site, and detect-elementor-version is the first call an AI agent makes to decide which tools to use. Thanks to @Winsoftpedia for the report and the fix (#117).
• Inserting a block at a position that does not exist silently lost the block. When add-block was given a position.path that did not resolve to a real block (a stale or miscounted index), the insert quietly did nothing, the post was saved unchanged, and the tool still reported success, so an AI believed the block was added when it was not. Every block pack (Kadence, Spectra, GenerateBlocks, Blocksy) now validates the position first and returns a clear invalid_position error naming the problem. The core Gutenberg tools already did this.
• OAuth sign-in failed on subdirectory installs (WordPress in a subfolder). On a site installed under a path such as example.com/gpt-build/, the OAuth discovery document that clients need (/.well-known/oauth-protected-resource, RFC 9728) returned 404, so connecting over OAuth from ChatGPT, Claude, or any standard MCP client dead-ended before it could get a token, and no tools appeared. The plugin advertised the correct subfolder URL but did not serve it there, because the request path was matched against the site-root path without accounting for the subdirectory. It now strips the install's home-path prefix before matching, so discovery works on subfolder installs and is unchanged on root installs.

Performance

• Lower memory use on every front-end page view. The plugin used to load all ~180 of its PHP class files (about 10 MB) on every single request, including plain front-end page views that never touch the AI tools. The ~120 MCP ability classes and their supporting code (schema catalogs, guards, security and performance audits, and the theme/forms/SEO integrations) now load only when they are actually needed: an MCP request, the admin Tools screen, WP-CLI, or cron. A normal front-end page view now loads about 6 MB less per request, which gives sites on a 128 MB PHP memory limit real headroom and stops the out-of-memory crashes some hosts hit. The full tool surface is unchanged for every real MCP, admin, and CLI request, and a lazy fallback still loads everything the moment the Abilities API fires, so nothing is ever missing when a tool is called.