Elementor Addons

New in v3.6.0. If you build with Elementor addon packs, your AI had a blind spot: it could see Elementor’s own widgets but not one of the hundreds your addons installed. Ask for a pricing table and it would hand-build one out of containers while a finished addon widget sat unused.

These tools close that gap. All three integrations are Pro, and each registers only when its plugin is active.

Plugin	Tools	Shape
Essential Addons for Elementor	essential-addons-read	Discovery only
Premium Addons for Elementor	premium-addons-read	Discovery only
Ultimate Addons for Elementor (UAE)	uae-read / uae-write	Widget pack and template plugin

There are two separate UAE plugins

“Ultimate Addons for Elementor” is two independent plugins, not one, and the integration handles both.

• The free one, formerly Header Footer Elementor. Brainstorm Force renamed it, but the wordpress.org slug is still header-footer-elementor. It supplies the header, footer and block templates and 7 hfe-* widgets.
• UAE Pro (slug ultimate-elementor, “Ultimate Addons for Elementor Pro”), a standalone 40+ widget pack (uael-*). It does not need the free plugin and is often installed on its own. It has no templates.

Either one activates the integration. The template tools (list-templates, get-template, and the whole uae-write tool) appear only when the free plugin is present, because that is what owns the templates. On a UAE-Pro-only site you get widget discovery, which is all UAE Pro provides.

This domain breaks the usual pattern

Most EMCP plugin integrations give you a matching Read/Write pair. This one deliberately does not, and it is worth understanding why.

Essential Addons and Premium Addons get a read tool only. Their widgets register into Elementor’s own widget registry, which means EMCP can already place them with the standard add-free-widget tool. What was missing was never placement, it was discovery: list-widgets serves EMCP’s curated core catalog, so an agent had no way to learn that eael-pricing-table or premium-addon-banner exist at all.

So the workflow is discover, inspect, then place with the normal tool:

// 1. Discover. Filter with `search` or `category`.
essential-addons-read({ operation: "list-widgets", arguments: { search: "pricing" } })
// → { count, widgets: [ { type: "eael-pricing-table", title: "Pricing Table", … } ] }

// 2. Inspect the controls that carry content.
essential-addons-read({ operation: "get-widget-schema", arguments: { type: "eael-pricing-table" } })

// 3. Place it with the ordinary widget tool.
add-free-widget({ post_id, parent_id, widget_type: "eael-pricing-table", settings: { … } })

There is no add-widget operation on these tools, and adding one would only duplicate a path that already works.

Why widget schemas are filtered

Addon widgets are enormous. On a stock install, eael-pricing-table reports 456 controls, eael-adv-accordion 467, and premium-addon-banner 391. Handing all of that to an AI would flood its context window and crowd out your actual instructions.

So get-widget-schema returns only content-bearing controls by default, the ones that hold your text, images, links, prices and repeater rows. Everything else is styling chrome: sliders, switchers, colour pickers, popover toggles.

• Default: the controls you need to populate the widget.
• full: true: every control including styling. Use it when you specifically need a styling control name, and expect a large response.
• types: ["a", "b"]: inspect several widgets in one call.

Each response reports total_controls and shown, so you can always tell when you are seeing a subset.

Use the control names the schema gives you

Elementor stores any setting key you send without complaining. A wrong or invented control name therefore looks like it worked but never actually drives the widget. If a setting seems to do nothing, re-read the schema rather than guessing a variant.

Ultimate Addons for Elementor

UAE is the one integration here that is both shapes at once, because between its two plugins (see the note above) it registers widgets like the packs above (hfe-* from the free plugin, uael-* from UAE Pro) and stores header, footer and block templates with display conditions. So its read tool covers both jobs, and it is the only one with a write tool.

The exact surface depends on what is installed. list-widgets and get-widget-schema are always there. list-templates, get-template and the uae-write tool appear only when the free plugin (the template owner) is active, so a site running only UAE Pro sees widget discovery and nothing template-related.

Read operations (uae-read)

Operation	Purpose
list-widgets	UAE’s registered widgets. Place them with add-free-widget.
get-widget-schema	Content-bearing controls for a widget by type (or types).
list-templates	Templates with type, status and display conditions. Filter with type.
get-template	One template, plus user-role targeting and whether it has content yet.

Write operations (uae-write)

Operation	Purpose
create-template	title + type (header, footer, before_footer, custom).
update-template	Change title, status or type.
set-display-conditions	include, optional exclude, optional user_roles.
delete-template	Requires confirm: true. force: true bypasses trash.

The template record and its content are separate steps

create-template creates the record, it does not build the header. You build the content with the ordinary Elementor tools, using the returned template_id as the post_id:

// 1. Create the record.
uae-write({ operation: "create-template", arguments: { title: "Main Header", type: "header" } })
// → { template_id: 812 }

// 2. Decide where it appears.
uae-write({ operation: "set-display-conditions",
            arguments: { template_id: 812, include: ["entire-website"] } })

// 3. Build the actual header with the normal tools.
add-container({ post_id: 812, … })
add-free-widget({ post_id: 812, parent_id: "…", widget_type: "nav-menu", … })

Safety

uae-write renders site-wide: a bad header or footer affects every page on your site. So it ships disabled by default and must be switched on under EMCP Tools → Tools → Elementor Addons. delete-template additionally requires an explicit confirm: true.

While building, prefer status: "draft" and confirm the display conditions with get-template before you publish.

Using UAE alongside EMCP Themer

EMCP Themer is EMCP’s own builder-agnostic theme builder, and it does the same job as UAE’s header and footer templates. Two systems claiming the same header slot fight at render time, which shows up as a mysterious double header.

If both are active, EMCP Tools shows an admin notice explaining the clash and asks you to pick one. Until you do, it resolves the conflict per slot, with Themer taking priority: where Themer has a matching template, its header or footer renders and UAE’s is skipped. Any slot Themer does not claim still renders from UAE, so an existing UAE-only footer keeps working.

The two are deliberately not wired together, and you should not try to mirror templates between them. Use UAE on sites that already run it; use Themer where it is the site’s theme-building system.