AI/MCP-Compatible Widget Schema & Semantic Metadata Layer for Elementor (to enable accurate AI-driven page building via Claude/other LLMs)

[akaryan2020]

Describe the Problem

When using AI models (Claude Code, Claude Design, or other LLM-based tools) connected to WordPress via the Elementor MCP integration, the AI is able to design visually excellent layouts conceptually, but fails to translate that design accurately into native Elementor widgets and structures.

Specific issues encountered:

• The AI cannot reliably discover, map, or configure Elementor's native widgets (both core and third-party, e.g., from addon packs) because there is no structured, machine-readable schema describing each widget's available settings, controls, nesting rules, and styling options.

• Because of this gap, the AI defaults to inserting raw HTML/CSS blocks (via the HTML widget) instead of using proper Elementor widgets/sections/containers — meaning the final page is not truly "Elementor-native." This breaks the core benefit of using Elementor in the first place: visual editability, widget-level control, responsive settings, and compatibility with theme/global styles.

• Pages built this way become harder to edit later inside the Elementor UI itself, since large parts of the page exist as unstructured HTML rather than editable widgets.

• There's no standardized way for an AI/MCP client to query "what widgets exist, what parameters do they accept, and what are valid value ranges/formats" — so the AI is essentially guessing based on generic web knowledge rather than Elementor-specific documentation.

• This problem compounds with third-party widget libraries (Essential Addons, Crocoblock/JetElements, etc.), where there's even less structured data available for an AI to reference.

Propose a Solution

Introduce a standardized, machine-readable widget schema/API that any AI model or MCP-based tool can query and act on reliably. Suggested components:

• Widget Manifest/Schema Endpoint: A REST/MCP-exposed endpoint that returns a structured JSON schema for every registered widget (core + third-party), including: widget name/slug, all available controls (text, color, typography, spacing, responsive breakpoints, etc.), accepted value types/ranges, default values, and nesting/container compatibility rules.

• Semantic Design Intent Mapping: A translation layer that maps common design intents (e.g., "hero section with centered heading, CTA button, background image") to the closest matching combination of native Elementor widgets/containers, so AI tools don't have to reverse-engineer this from scratch each time.

• MCP-Native "Build Page" Actions: Instead of the AI generating raw HTML and injecting it, expose granular MCP actions like add_widget(type, parent, settings), update_widget_settings(), set_container_layout() — mirroring what a human does in the Elementor editor, so structure stays fully native and editable.

• Validation/Feedback Loop: When an AI submits a widget configuration, return validation errors or suggestions (e.g., "this control expects a JS object with these keys") so the AI can self-correct instead of silently falling back to HTML.

• Documentation in AI-ingestible format: Publish widget/control documentation as structured data (JSON/YAML) alongside the existing human-readable docs, similar to how OpenAPI specs work for REST APIs.

Additional Context

• Alternative considered: Continuing to allow AI tools to fall back to HTML widgets is a workable stopgap but defeats the purpose of Elementor's visual/no-code value proposition once AI is in the loop — pages become a hybrid mess of native + raw HTML, harder for humans to maintain afterward.

• A useful parallel: Figma's plugin API and design-token export systems allow external tools (including AI) to read and write structured data rather than guessing from visuals — Elementor could benefit from a similar structured approach specifically tailored for MCP/AI clients.

• This would also benefit non-AI use cases: a well-documented, structured widget schema improves third-party plugin interoperability and could reduce onboarding friction for developers building on top of Elementor's API in general.

Agreement

• I confirm I have read and followed all the guidelines and instructions outlined in the Feature Request form.
• I agree that my discussion may be closed without further action if it doesn't meet all the requirements outlined in the Feature Request form.

[philip-evocs]

@akaryan2020 I am seeing in their commits that they are working towards an MCP solution. Crossing fingers on 4.3 beta!