Elementor Atomic Builder MCP 详解:get-widget-schema Ability 与 Widget JSON Schema、llm_guidance 的生成机制【免费下载链接】elementorThe most advanced frontend drag drop page builder. Create high-end, pixel perfect websites at record speeds. Any theme, any page, any design.项目地址: https://gitcode.com/GitHub_Trending/el/elementor本文围绕 Elementor 官方 MCP 模块中的elementor/get-widget-schemaAbility 展开:它是 Agent 在拼装页面元素之前获取单个 widget 实时 JSON Schema 的唯一入口,返回结果同时包含属性 Schema 与面向 LLM 的llm_guidance(容器判断、嵌套规则、必填子元素等)。读完本文,你可以准确使用该 Ability 的输入输出契约,理解 v4 原子 widget 与 v3 回退 Schema 的分流逻辑,并能从 get-widget-schema-ability.php、widget-context-helper.php 等源码层面追溯每个字段的生成过程。一、它是什么:一个只读的 Schema 查询 Ability文档 docs/atomic-builder/mcp/abilities/get-widget-schema.md 定义的核心信息如下:Ability ID:elementor/get-widget-schema,这是 MCP 宿主侧稳定的标识符;功能定位:返回某一个widget type 的实时 JSON Schema,它是后续build-composition中element_config的事实来源(source of truth);权限要求:调用者需具备edit_posts权限;对应模块:modules/mcp/abilities/get-widget-schema-ability.php。在 get-widget-schema-ability.php#L18-L45 中,get_definition()构造Ability_Definition时为它声明了 MCP 工具注解:readonly: true、idempotent: true、destructive: false—— 即这是一个纯读取、可重复调用、不产生任何副作用的工具,权限校验通过current_user_can( edit_posts )闭包实现。公开 API 摘要(继承自文档):符号签名用途Get_Widget_Schema_Abilityexecute( array $input ): array针对widget_type返回 schema llm_guidanceAbility IDelementor/get-widget-schema稳定的 MCP 宿主标识二、什么时候用它:在 build-composition 之前先取 Schema文档给出的三个典型使用时机:在为build-composition的element_config构造某个 widget type 的配置之前;检查嵌套规则(allowed_child_types、required_direct_children);查看哪些 prop 接受动态标签(dynamic tag)绑定。文档同时给出了工作流建议:对组合中出现的每个 widget type 各调用一次;而有哪些可用类型的发现步骤应先用 list-widget-schemas 完成,再用本 Ability 精确拉取单个 Schema。这一点在工具自带的 Prompt 说明文件 modules/mcp/static-resources/abilities/get-widget-schema.md 中被进一步强化:Useelementor/list-widget-schemaswithsummarytruefirst to discover validwidget_typevalues. Types not returned by that endpoint are not supported by this tool and must be edited directly in the Elementor editor (call fails withelementor_v3_not_supported).即:凡没有被list-widget-schemas返回的类型,本工具都视为不支持,必须回到 Elementor 编辑器内手工编辑。Prompt 文件还约定了设置值的传输形状——纯 JSON,标量保持标量,动态标签写作{ name, settings };只有properties下列出的 key 会被接受;所有视觉样式一律放进style(CSS)输入中,而不是element_config。该 Prompt 经由 prompt-loader.php 加载,且支持在 Pro 的static-resources-extra/abilities/目录下合并同名.md追加说明,因此外部使用者看到的工具描述就是核心说明 可选 Pro 扩展说明的拼接。下游消费方 build-composition 的element_config字段注释中直接写明 plain widget settings (seeget-widget-schema),印证了先查 Schema、再填配置的调用顺序。三、输入参数字段必填说明widget_type是注册表标识符,例如e-heading、e-flexbox在 get-widget-schema-ability.php#L47-L57 中,execute()对输入做了两层防护:非数组输入被归一为空数组,widget_type经sanitize_key()清洗;为空时直接返回invalid_input错误。这与下方错误小节一一对应。四、v4 输出结构:属性 Schema llm_guidance对于带有atomic_props_schema的 v4 原子 widget,返回结构为(完整继承文档示例):{ type: object, properties: { /* prop key → JSON schema */ }, description: Widget description from meta, llm_guidance: { can_have_children: true, instructions: ..., default_styles: { }, default_settings: { }, nesting: { allowed_child_types: [e-heading, e-button], allowed_parents: [e-flexbox, document] }, required_direct_children: [e-tab-content] } }各字段的含义(文档 llm_guidance fields 表格):字段含义can_have_children该 widget 是否为容器(取自meta.is_container)instructions何时应从element_config中省略default_styles/default_settingsdefault_styles基础样式的 CSS 映射——仅在需要时覆写default_settings基础设置——除非用户要求修改,否则不要写入element_confignesting.allowed_child_types合法的子 widget 类型nesting.allowed_parents合法的父类型(来自 parents index)required_direct_children必须作为 XML 直接子节点出现的子类型源码印证:Llm_Guidance_Builder 的生成逻辑从源码结构看,llm-guidance-builder.php 中的Llm_Guidance_Builder::build()按有则输出、空则剔除的原则逐字段构造 guidance:can_have_children直接取! empty( $config[meta][is_container] );default_styles由 widget 的base_styles各变体的 props 合并后,经Style_Props_To_Css::to_map()转成 CSS 映射;一旦存在,instructions即固定输出 These are the default styles applied to the widget. Override only when necessary.(见 llm-guidance-builder.php#L13-L47);nesting由allowed_child_types与 parents index 中的反查结果组成。一个容易被忽略的细节是 llm-guidance-builder.php#L63-L64:只有当 widget 未设置show_in_panel时才会输出allowed_parents——即面板中不可见的系统型 widget才需要父级提示;required_direct_children来自 widget 的default_children配置,经Default_Children_Utils::get_required_child_types()提取必须出现的子类型(对应 default-children-utils.php)。parents index 本身在 widget-context-helper.php#L144-L154 中由build_parents_index()预计算:遍历所有 LLM 可用 widget 的allowed_child_types,建立child_type parent_types[]的反向索引,从而让单次allowed_parents查询变为 O(1) 数组取值。属性过滤:NON_CONFIGURABLE_PROP_KEYS 与 llm_configurable 逃生门文档强调:位于NON_CONFIGURABLE_PROP_KEYS(classes、attributes等)中的 prop 默认被排除,除非其 meta 显式设置了llm_configurable;而 base settings 类 prop 会在其 schema 描述中带有提示。源码确认了这一机制的两处细节(见 widget-context-helper.php):黑名单常量完整值为[_cssid, classes, attributes, display-conditions](第 26 行);is_prop_key_configurable()(第 318-324 行)的逻辑是:非黑名单 key 一律可配置;黑名单 key 仅当$prop_type-get_meta_item( llm_configurable, false )为真时放行。此外,在build_configurable_properties_schema()(第 204-223 行)中,对接受转义 HTML 的 prop,Schema 会附加allowed_html_tags字段(来自Escaped_Html_Prop_Type::get_allowed_html_tags_for_prop()),把该字段允许哪些 HTML 标签直接告诉模型,便于生成合规内容。从 Prop_Type 到LLM 友好Schema 的转换链v4 分支的转换链路是:$prop_type-to_json_schema()→apply_filters( elementor/atomic-widgets/llm-json-schema, $schema )→Plain_Llm_Schema_Converter::convert()(见 widget-context-helper.php#L231-L235,转换器实现在 plain-llm-schema-converter.php)。这条链解释了文档 Extension 一节提到的 Schema 过滤器elementor/atomic-widgets/llm-json-schema的作用点:第三方在该过滤点拿到的是标准 JSON Schema,可以在交给Plain_Llm_Schema_Converter拍平之前做自定义改写。钩子的完整清单见 docs/atomic-builder/atomic-widgets/hooks.md。五、v3 回退:没有 atomic_props_schema 时的信息性输出对于没有atomic_props_schema但带有传统 controls 的 v3 widget,build_widget_schema()走另一条分支,返回:{ widget_version: v3, message: This widget exists in the editor but has no atomic props schema (V4)..., fields_note: All settings are optional..., properties: { /* control_metadata hints */ } }文档的定性是:build-composition面向 v4 元素,v3 回退输出仅供信息参考。结合源码可以进一步弄清它的边界(见 widget-context-helper.php#L34-L45):V3_FALLBACK_MESSAGE的完整文案是:propertieslists the only keys accepted inelement_config/manage-elements.settingsfor this widget. Put all visual styling in thestyle(CSS) input.——即 properties 中列出的 key 是该 widget 唯一接受的设置键,其余视觉表现全部走style输入;V3_FALLBACK_FIELDS_NOTE声明所有属性均为可选,对象类型属性描述的是常见形状而非穷尽式内部校验;源码中存在一个白名单V3_ALLOWLIST(nav-menu、theme-post-content、theme-post-title、theme-post-featured-image、theme-post-excerpt、theme-archive-title),这些主题类 widget 的 controls 栈会被强制初始化,以便其 v3 controls 能参与 Schema 构建。需要指出一个文档与源码行为上的差异:在 get-widget-schema-ability.php#L70-L82 中,execute()会先判断 widget 是否为 v3,若 v3 且不在V3_Widget_Map_Registry支持范围内,会直接返回elementor_v3_not_supported(HTTP 400)错误,提示这是遗留 V3 widget,请直接在 Elementor 编辑器中编辑;只有 v3 且被桥接注册表支持时才会返回上述信息性 Schema。换言之,回退输出并非无条件可达,它受 v3 支持映射的实验开关约束,这一点在引用本文结论时应作为适用前提。六、错误契约错误码触发条件HTTP 状态invalid_input缺少widget_type400(BAD_REQUEST)elementor_not_found未知类型,或 widget 的meta.llm_support: false404(NOT_FOUND)elementor_v3_not_supportedv3 widget 且不在 V3 支持映射内(源码补充)400(BAD_REQUEST)其中未知类型与显式关闭 llm_support在execute()中被合并为同一条分支:只要get_widget_config()返回空、或is_widget_eligible_for_llm()判定为假,即返回elementor_not_found。资格判定逻辑(见 widget-context-helper.php#L94-L108)分三层:meta.llm_support显式为false即排除;title 恰为Component的组件 widget 被排除;满足后,只要存在atomic_props_schema即合格,否则要求controls非空(即具备 v3 能力)。get_widget_config()的实例检索经由Atomic_Elements_Utils::get_element_instance(),同时覆盖 widgets_manager 与 elements_manager 两个注册表。七、扩展点:让自定义 widget 进入 MCP Schema 体系文档 Extension 一节给出的路径,对 widget 作者而言就是三件事:在 widget config 的meta中声明llm_support(置为false可主动退出 MCP 可见性,默认不退出);实现define_props_schema(),提供atomic_props_schema,从而进入 v4 分支;如需调整 Schema 形状,挂elementor/atomic-widgets/llm-json-schema过滤器。从源码结构看,还有一个文档未展开但实际生效的机制:refine_from_prop_type()(见 widget-context-helper.php#L243-L316)会递归遍历 Prop_Type 树,在Pro 未激活时剥除meta(pro) true的对象字段,并按meta(pro)列出的枚举值从enum中剔除 Pro 专属选项;Pro 激活时则补全完整enum。也就是说,同一个 widget 在免费/Pro 环境下,get-widget-schema返回的可选值集合是不同的——这保证了 Agent 永远不会看见当前环境不可用的选项。八、Internals:完整调用链把文档 Internals 小节与源码对齐后,一次成功的 v4 调用完整链路为:Get_Widget_Schema_Ability::execute()—— 清洗widget_type,做资格与版本分流;Widget_Context_Helper::get_widget_config()—— 取实例并返回get_config()(必要时先初始化 v3 controls 栈);Widget_Context_Helper::is_widget_eligible_for_llm()—— 检查llm_support、排除 Component widget;get_widget_version()—— 以是否有atomic_props_schema区分v3/v4;build_parents_index()build_widget_schema()—— 组装properties(经Plain_Llm_Schema_Converter拍平)与llm_guidance(Llm_Guidance_Builder生成)。该链路的自动化验证见单元测试 tests/phpunit/elementor/modules/mcp/test-get-widget-schema-ability.php,其中直接实例化Get_Widget_Schema_Ability进行断言;test-list-widget-schemas-ability.php 则交叉覆盖了批量发现与单查两个 Ability 的一致性。九、配套阅读docs/atomic-builder/mcp/abilities/list-widget-schemas.md —— 批量发现可用 widget 类型(summary 模式/全量模式);docs/atomic-builder/mcp/abilities/build-composition.md —— 消费本 Schema 的组合构建流程,其element_config取值直接以本文输出为准;docs/atomic-builder/fundamentals/prop-types.md —— prop 类型分类体系,是理解properties中每个 Schema 片段的背景知识;docs/atomic-builder/atomic-widgets/elements-catalog.md —— 元素目录快照(二级参考);docs/atomic-builder/atomic-widgets/hooks.md —— 包括elementor/atomic-widgets/llm-json-schema在内的钩子清单。小结:get-widget-schema的价值在于把这个 widget 能接受什么设置、能装什么子元素、哪些值是环境可用的压缩成一份 Agent 可直接消费的 JSON,并以llm_guidance给出何时省略默认值的行为约束。正确姿势是:先用list-widget-schemas发现类型,再对每个类型取一次 Schema,最后按 Schema 的形状填充build-composition的element_config——样式永远留在 CSSstyle输入里。【免费下载链接】elementorThe most advanced frontend drag drop page builder. Create high-end, pixel perfect websites at record speeds. Any theme, any page, any design.项目地址: https://gitcode.com/GitHub_Trending/el/elementor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Elementor Atomic Builder MCP 详解:get-widget-schema Ability 与 Widget JSON Schema、llm_guidance 的生成机制
Elementor Atomic Builder MCP 详解:get-widget-schema Ability 与 Widget JSON Schema、llm_guidance 的生成机制【免费下载链接】elementorThe most advanced frontend drag drop page builder. Create high-end, pixel perfect websites at record speeds. Any theme, any page, any design.项目地址: https://gitcode.com/GitHub_Trending/el/elementor本文围绕 Elementor 官方 MCP 模块中的elementor/get-widget-schemaAbility 展开:它是 Agent 在拼装页面元素之前获取单个 widget 实时 JSON Schema 的唯一入口,返回结果同时包含属性 Schema 与面向 LLM 的llm_guidance(容器判断、嵌套规则、必填子元素等)。读完本文,你可以准确使用该 Ability 的输入输出契约,理解 v4 原子 widget 与 v3 回退 Schema 的分流逻辑,并能从 get-widget-schema-ability.php、widget-context-helper.php 等源码层面追溯每个字段的生成过程。一、它是什么:一个只读的 Schema 查询 Ability文档 docs/atomic-builder/mcp/abilities/get-widget-schema.md 定义的核心信息如下:Ability ID:elementor/get-widget-schema,这是 MCP 宿主侧稳定的标识符;功能定位:返回某一个widget type 的实时 JSON Schema,它是后续build-composition中element_config的事实来源(source of truth);权限要求:调用者需具备edit_posts权限;对应模块:modules/mcp/abilities/get-widget-schema-ability.php。在 get-widget-schema-ability.php#L18-L45 中,get_definition()构造Ability_Definition时为它声明了 MCP 工具注解:readonly: true、idempotent: true、destructive: false—— 即这是一个纯读取、可重复调用、不产生任何副作用的工具,权限校验通过current_user_can( edit_posts )闭包实现。公开 API 摘要(继承自文档):符号签名用途Get_Widget_Schema_Abilityexecute( array $input ): array针对widget_type返回 schema llm_guidanceAbility IDelementor/get-widget-schema稳定的 MCP 宿主标识二、什么时候用它:在 build-composition 之前先取 Schema文档给出的三个典型使用时机:在为build-composition的element_config构造某个 widget type 的配置之前;检查嵌套规则(allowed_child_types、required_direct_children);查看哪些 prop 接受动态标签(dynamic tag)绑定。文档同时给出了工作流建议:对组合中出现的每个 widget type 各调用一次;而有哪些可用类型的发现步骤应先用 list-widget-schemas 完成,再用本 Ability 精确拉取单个 Schema。这一点在工具自带的 Prompt 说明文件 modules/mcp/static-resources/abilities/get-widget-schema.md 中被进一步强化:Useelementor/list-widget-schemaswithsummarytruefirst to discover validwidget_typevalues. Types not returned by that endpoint are not supported by this tool and must be edited directly in the Elementor editor (call fails withelementor_v3_not_supported).即:凡没有被list-widget-schemas返回的类型,本工具都视为不支持,必须回到 Elementor 编辑器内手工编辑。Prompt 文件还约定了设置值的传输形状——纯 JSON,标量保持标量,动态标签写作{ name, settings };只有properties下列出的 key 会被接受;所有视觉样式一律放进style(CSS)输入中,而不是element_config。该 Prompt 经由 prompt-loader.php 加载,且支持在 Pro 的static-resources-extra/abilities/目录下合并同名.md追加说明,因此外部使用者看到的工具描述就是核心说明 可选 Pro 扩展说明的拼接。下游消费方 build-composition 的element_config字段注释中直接写明 plain widget settings (seeget-widget-schema),印证了先查 Schema、再填配置的调用顺序。三、输入参数字段必填说明widget_type是注册表标识符,例如e-heading、e-flexbox在 get-widget-schema-ability.php#L47-L57 中,execute()对输入做了两层防护:非数组输入被归一为空数组,widget_type经sanitize_key()清洗;为空时直接返回invalid_input错误。这与下方错误小节一一对应。四、v4 输出结构:属性 Schema llm_guidance对于带有atomic_props_schema的 v4 原子 widget,返回结构为(完整继承文档示例):{ type: object, properties: { /* prop key → JSON schema */ }, description: Widget description from meta, llm_guidance: { can_have_children: true, instructions: ..., default_styles: { }, default_settings: { }, nesting: { allowed_child_types: [e-heading, e-button], allowed_parents: [e-flexbox, document] }, required_direct_children: [e-tab-content] } }各字段的含义(文档 llm_guidance fields 表格):字段含义can_have_children该 widget 是否为容器(取自meta.is_container)instructions何时应从element_config中省略default_styles/default_settingsdefault_styles基础样式的 CSS 映射——仅在需要时覆写default_settings基础设置——除非用户要求修改,否则不要写入element_confignesting.allowed_child_types合法的子 widget 类型nesting.allowed_parents合法的父类型(来自 parents index)required_direct_children必须作为 XML 直接子节点出现的子类型源码印证:Llm_Guidance_Builder 的生成逻辑从源码结构看,llm-guidance-builder.php 中的Llm_Guidance_Builder::build()按有则输出、空则剔除的原则逐字段构造 guidance:can_have_children直接取! empty( $config[meta][is_container] );default_styles由 widget 的base_styles各变体的 props 合并后,经Style_Props_To_Css::to_map()转成 CSS 映射;一旦存在,instructions即固定输出 These are the default styles applied to the widget. Override only when necessary.(见 llm-guidance-builder.php#L13-L47);nesting由allowed_child_types与 parents index 中的反查结果组成。一个容易被忽略的细节是 llm-guidance-builder.php#L63-L64:只有当 widget 未设置show_in_panel时才会输出allowed_parents——即面板中不可见的系统型 widget才需要父级提示;required_direct_children来自 widget 的default_children配置,经Default_Children_Utils::get_required_child_types()提取必须出现的子类型(对应 default-children-utils.php)。parents index 本身在 widget-context-helper.php#L144-L154 中由build_parents_index()预计算:遍历所有 LLM 可用 widget 的allowed_child_types,建立child_type parent_types[]的反向索引,从而让单次allowed_parents查询变为 O(1) 数组取值。属性过滤:NON_CONFIGURABLE_PROP_KEYS 与 llm_configurable 逃生门文档强调:位于NON_CONFIGURABLE_PROP_KEYS(classes、attributes等)中的 prop 默认被排除,除非其 meta 显式设置了llm_configurable;而 base settings 类 prop 会在其 schema 描述中带有提示。源码确认了这一机制的两处细节(见 widget-context-helper.php):黑名单常量完整值为[_cssid, classes, attributes, display-conditions](第 26 行);is_prop_key_configurable()(第 318-324 行)的逻辑是:非黑名单 key 一律可配置;黑名单 key 仅当$prop_type-get_meta_item( llm_configurable, false )为真时放行。此外,在build_configurable_properties_schema()(第 204-223 行)中,对接受转义 HTML 的 prop,Schema 会附加allowed_html_tags字段(来自Escaped_Html_Prop_Type::get_allowed_html_tags_for_prop()),把该字段允许哪些 HTML 标签直接告诉模型,便于生成合规内容。从 Prop_Type 到LLM 友好Schema 的转换链v4 分支的转换链路是:$prop_type-to_json_schema()→apply_filters( elementor/atomic-widgets/llm-json-schema, $schema )→Plain_Llm_Schema_Converter::convert()(见 widget-context-helper.php#L231-L235,转换器实现在 plain-llm-schema-converter.php)。这条链解释了文档 Extension 一节提到的 Schema 过滤器elementor/atomic-widgets/llm-json-schema的作用点:第三方在该过滤点拿到的是标准 JSON Schema,可以在交给Plain_Llm_Schema_Converter拍平之前做自定义改写。钩子的完整清单见 docs/atomic-builder/atomic-widgets/hooks.md。五、v3 回退:没有 atomic_props_schema 时的信息性输出对于没有atomic_props_schema但带有传统 controls 的 v3 widget,build_widget_schema()走另一条分支,返回:{ widget_version: v3, message: This widget exists in the editor but has no atomic props schema (V4)..., fields_note: All settings are optional..., properties: { /* control_metadata hints */ } }文档的定性是:build-composition面向 v4 元素,v3 回退输出仅供信息参考。结合源码可以进一步弄清它的边界(见 widget-context-helper.php#L34-L45):V3_FALLBACK_MESSAGE的完整文案是:propertieslists the only keys accepted inelement_config/manage-elements.settingsfor this widget. Put all visual styling in thestyle(CSS) input.——即 properties 中列出的 key 是该 widget 唯一接受的设置键,其余视觉表现全部走style输入;V3_FALLBACK_FIELDS_NOTE声明所有属性均为可选,对象类型属性描述的是常见形状而非穷尽式内部校验;源码中存在一个白名单V3_ALLOWLIST(nav-menu、theme-post-content、theme-post-title、theme-post-featured-image、theme-post-excerpt、theme-archive-title),这些主题类 widget 的 controls 栈会被强制初始化,以便其 v3 controls 能参与 Schema 构建。需要指出一个文档与源码行为上的差异:在 get-widget-schema-ability.php#L70-L82 中,execute()会先判断 widget 是否为 v3,若 v3 且不在V3_Widget_Map_Registry支持范围内,会直接返回elementor_v3_not_supported(HTTP 400)错误,提示这是遗留 V3 widget,请直接在 Elementor 编辑器中编辑;只有 v3 且被桥接注册表支持时才会返回上述信息性 Schema。换言之,回退输出并非无条件可达,它受 v3 支持映射的实验开关约束,这一点在引用本文结论时应作为适用前提。六、错误契约错误码触发条件HTTP 状态invalid_input缺少widget_type400(BAD_REQUEST)elementor_not_found未知类型,或 widget 的meta.llm_support: false404(NOT_FOUND)elementor_v3_not_supportedv3 widget 且不在 V3 支持映射内(源码补充)400(BAD_REQUEST)其中未知类型与显式关闭 llm_support在execute()中被合并为同一条分支:只要get_widget_config()返回空、或is_widget_eligible_for_llm()判定为假,即返回elementor_not_found。资格判定逻辑(见 widget-context-helper.php#L94-L108)分三层:meta.llm_support显式为false即排除;title 恰为Component的组件 widget 被排除;满足后,只要存在atomic_props_schema即合格,否则要求controls非空(即具备 v3 能力)。get_widget_config()的实例检索经由Atomic_Elements_Utils::get_element_instance(),同时覆盖 widgets_manager 与 elements_manager 两个注册表。七、扩展点:让自定义 widget 进入 MCP Schema 体系文档 Extension 一节给出的路径,对 widget 作者而言就是三件事:在 widget config 的meta中声明llm_support(置为false可主动退出 MCP 可见性,默认不退出);实现define_props_schema(),提供atomic_props_schema,从而进入 v4 分支;如需调整 Schema 形状,挂elementor/atomic-widgets/llm-json-schema过滤器。从源码结构看,还有一个文档未展开但实际生效的机制:refine_from_prop_type()(见 widget-context-helper.php#L243-L316)会递归遍历 Prop_Type 树,在Pro 未激活时剥除meta(pro) true的对象字段,并按meta(pro)列出的枚举值从enum中剔除 Pro 专属选项;Pro 激活时则补全完整enum。也就是说,同一个 widget 在免费/Pro 环境下,get-widget-schema返回的可选值集合是不同的——这保证了 Agent 永远不会看见当前环境不可用的选项。八、Internals:完整调用链把文档 Internals 小节与源码对齐后,一次成功的 v4 调用完整链路为:Get_Widget_Schema_Ability::execute()—— 清洗widget_type,做资格与版本分流;Widget_Context_Helper::get_widget_config()—— 取实例并返回get_config()(必要时先初始化 v3 controls 栈);Widget_Context_Helper::is_widget_eligible_for_llm()—— 检查llm_support、排除 Component widget;get_widget_version()—— 以是否有atomic_props_schema区分v3/v4;build_parents_index()build_widget_schema()—— 组装properties(经Plain_Llm_Schema_Converter拍平)与llm_guidance(Llm_Guidance_Builder生成)。该链路的自动化验证见单元测试 tests/phpunit/elementor/modules/mcp/test-get-widget-schema-ability.php,其中直接实例化Get_Widget_Schema_Ability进行断言;test-list-widget-schemas-ability.php 则交叉覆盖了批量发现与单查两个 Ability 的一致性。九、配套阅读docs/atomic-builder/mcp/abilities/list-widget-schemas.md —— 批量发现可用 widget 类型(summary 模式/全量模式);docs/atomic-builder/mcp/abilities/build-composition.md —— 消费本 Schema 的组合构建流程,其element_config取值直接以本文输出为准;docs/atomic-builder/fundamentals/prop-types.md —— prop 类型分类体系,是理解properties中每个 Schema 片段的背景知识;docs/atomic-builder/atomic-widgets/elements-catalog.md —— 元素目录快照(二级参考);docs/atomic-builder/atomic-widgets/hooks.md —— 包括elementor/atomic-widgets/llm-json-schema在内的钩子清单。小结:get-widget-schema的价值在于把这个 widget 能接受什么设置、能装什么子元素、哪些值是环境可用的压缩成一份 Agent 可直接消费的 JSON,并以llm_guidance给出何时省略默认值的行为约束。正确姿势是:先用list-widget-schemas发现类型,再对每个类型取一次 Schema,最后按 Schema 的形状填充build-composition的element_config——样式永远留在 CSSstyle输入里。【免费下载链接】elementorThe most advanced frontend drag drop page builder. Create high-end, pixel perfect websites at record speeds. Any theme, any page, any design.项目地址: https://gitcode.com/GitHub_Trending/el/elementor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考