Release story March 26, 2026

Respira

Respira 5.2 Elemental: AI That Speaks Your Builder’s Language

151 MCP tools — 65 new in Elemental. Surgical element-level editing that targets a single widget without downloading the page. Declarative page creation in one call. Per-builder intelligence for 11 builders. Stock images. Tool governance. A coordinated Plugin + MCP release.

Plugin 5.2.0 MCP Server 5.2.0 65 new tools
Total MCP tools
151
New in Elemental
65
Builders with intelligence
11
Coordinated release
Plugin 5.2.0 + MCP 5.2.0

Problem 1

Editing a heading means downloading the entire page

Shipped fix

Surgical element-level ops — find, update, move, duplicate, remove any widget directly

Problem 2

AI edits destroy builder layouts

Shipped fix

Per-builder intelligence preserves section/column/widget structure

Problem 3

Building a page requires dozens of API calls

Shipped fix

build_page creates a complete page from one declarative structure

Shaped by the community

Glen & Dave — Beaver Builder bug reports  ·  Sam — Bricks builder intelligence  ·  Jeroen — license & admin bugs  ·  William — site-level compatibility  ·  Yoliveras — MCP schema compliance  ·  Rixxter — HTML-to-builder conversion  ·  Sergei — built-in AI workflow guide  ·  Walter — Chinese character support

The story

Changing one heading used to mean downloading the entire page. Not anymore.

Before Elemental, every AI edit followed the same pattern: download the entire page structure, find the element you want to change, modify it, upload the entire page back. For a page with 200 widgets, changing a single heading meant moving the entire page over the wire twice. It was slow, token-expensive, and created unnecessary risk — the more data you move, the more chances for something to break.

The first breakthrough in Elemental is surgical element-level editing. Five new MCP tools — find_element, update_element, move_element, duplicate_element, remove_element — let AI agents target individual widgets by ID, type, CSS class, or text content. The page structure stays on the server. Only the changed element moves over the wire. For a heading change, that is roughly 50 tokens instead of 5,000.

The second breakthrough is builder intelligence. Each of the 11 supported page builders gets its own intelligence module that reads and writes in the builder's native format. When an AI agent edits an Elementor page, it works with the actual JSON widget tree — not a lossy HTML round-trip. A Discord user named Rixxter reported that sections were being dropped and styles lost. That report led to all of this.

The third is build_page — creating a complete page from a single declarative structure instead of dozens of individual API calls. Combined with 27 widget shortcuts and batch operations for up to 100 pages, Elemental turns Respira from a careful page editor into a full site construction platform.

What changed

AI changes a heading on an Elementor page — only the heading widget moves over the wire, not the entire 200-widget page structure.

AI creates a landing page — one build_page call with a declarative structure, instead of 30+ individual API calls.

An admin disables the delete_page tool — no AI agent can delete pages through any access path, period.

AI searches for a hero image — Openverse results with CC attribution, sideloaded directly into the media library.

Every scenario above works automatically in 5.2. The intelligence module is selected based on the detected builder.

Problem 1 to Fix 1

Changing one heading required downloading and reuploading the entire page.

Every MCP edit — even changing a single word in a heading — required downloading the full page structure, parsing it, making the change, and uploading it all back. For a page with 200 Elementor widgets, that is thousands of tokens round-tripped for a one-line change.

  • What the user experienced

    Slow edits, high token consumption, and occasional data corruption when the full-page round-trip hit a conflict or timeout.

  • Why it happened

    The only edit path was read_page → modify in memory → update_page. No way to target a specific element without moving the entire page structure.

  • What we shipped

    Five element-level operations: find_element (search by ID, type, class, or content), update_element, move_element, duplicate_element, remove_element. The page stays on the server. Only the targeted element moves over the wire.

  • Benefit

    ~50 tokens for a heading change instead of ~5,000. Faster edits, lower cost, zero risk of collateral damage to other elements on the page.

Edit approach comparison

Changing a heading: full-page vs element-level

New in 5.2
Before (full-page round-trip) Token cost
read_page(42)

Download 200 widgets, all settings, all structure

~4,000
Modify heading in memory

Find the widget, change the text

~200
update_page(42, full_structure)

Upload entire page back with one changed heading

~4,000

~8,200 tokens, 3 API calls, full page at risk of corruption during write-back.

After (element-level) Token cost
update_element(42, "heading", {title: "New Title"})

Target the heading widget directly, change only the text

~50

~50 tokens, 1 API call, only the heading widget is touched. Everything else stays exactly as it was.

Element-level operations work across all 11 supported builders. Each builder's intelligence module handles the native data format — Elementor JSON, Divi blocks, WPBakery shortcodes, etc.

Problem 2 to Fix 2

Builder Intelligence — Each builder gets its own brain.

AI treated all page builders the same — generic HTML in, HTML out. Every edit stripped away the builder-specific data that made your design work: container settings, responsive breakpoints, hover states, widget configurations, and custom CSS classes.

  • What the user experienced

    After an AI edit, Elementor container settings were gone, responsive breakpoints reset to defaults, and hover states vanished.

  • Why it happened

    The AI read rendered HTML and wrote HTML back. Builder-specific data stored in JSON meta fields was never read or preserved.

  • What we shipped

    Per-builder intelligence modules that understand widget types, container hierarchies, and builder-specific patterns. Each module reads and writes in the builder's native format.

  • Benefit

    AI edits preserve 94% layout fidelity. Container settings, responsive rules, hover states, and custom CSS all survive the edit.

Edit approach comparison

Same AI edit, different outcome for your layout

New in 5.2
Before (generic HTML) Edit result
AI reads rendered HTML

Builder meta fields ignored

Read
AI writes HTML back

Container settings, breakpoints lost

Write

Elementor container settings, responsive breakpoints, hover states, and custom CSS are all stripped during the HTML round-trip.

After (native format) Edit result
AI reads native Elementor JSON

All widget data, settings, and structure visible

Read
AI writes native Elementor JSON

Container settings, breakpoints, hover states preserved

Write
Schema validation before save

Invalid structures caught before writing

Validated
The intelligence module is selected automatically based on the detected page builder. No configuration needed — Respira detects Elementor, Divi, WPBakery, Beaver Builder, Bricks, and Gutenberg automatically.
Respira Builder & Theme Detection — 11 builders detected with Full Intelligence, Smart Defaults, and Basic Support levels
The Builder & Theme Detection panel shows every detected builder with its support level, version, and module count.

Problem 3 to Fix 3

HTML designs lost sections and styles when converted to builder elements.

Converting HTML designs to builder elements — for example, taking a Tailwind template and turning it into an Elementor page — lost sections, styles, and responsive settings. Entire sections would vanish. Colors would reset. Spacing would collapse.

  • What the user experienced

    Discord user Rixxter reported Elementor sections being dropped and styles lost during HTML-to-builder conversion. The AI made the right content changes, but the design was destroyed.

  • Why it happened

    HTML sections did not map cleanly to builder containers. Inline styles and CSS classes had no corresponding builder settings. The conversion was a best-effort guess.

  • What we shipped

    A three-stage content filter pipeline: CSS extraction pulls all styles, section mapping creates the builder hierarchy, and style mapping applies colors, spacing, and typography to native builder settings.

  • Benefit

    HTML designs convert to native builder elements with proper section hierarchy, preserved styling, and correct responsive settings.

Conversion pipeline

From raw HTML to native builder elements in four stages

New pipeline
Before 5.2 Direct conversion
HTML input

Raw HTML with inline styles and classes

Input
Best-effort mapping

Sections dropped, styles lost, responsive ignored

Output

Sections vanish, colors reset, spacing collapses. The conversion guesses at structure and often guesses wrong.

After 5.2 Pipeline stages
1. CSS Extraction

Pull all inline styles, class definitions, and computed values

Stage 1
2. Section Mapping

HTML sections become builder containers with proper hierarchy

Stage 2
3. Style Mapping

Colors, spacing, typography mapped to builder settings

Stage 3
4. Native Builder Elements

Complete builder-native output with all settings applied

Output
The pipeline processes HTML through discrete stages, each responsible for one aspect of the conversion. This came directly from Rixxter's bug report — the old approach tried to do everything in one step and failed silently.

Problem 4 to Fix 4

Structural errors in AI edits could corrupt builder data silently.

When an AI agent wrote invalid builder data — a widget type that does not exist, a broken container hierarchy, or a missing required field — the edit would save successfully and the corruption would only show up when the user opened the page in the visual builder.

  • What the user experienced

    The AI reported a successful edit, but opening the page in Elementor showed broken widgets, missing sections, or the builder recovery mode prompt.

  • Why it happened

    No validation layer existed between the AI output and the database write. Any structurally valid JSON would be accepted, even if it was not valid builder data.

  • What we shipped

    Schema validation that runs before every save. Widget types are checked against registered widgets, container hierarchies are verified, and required fields are validated. Invalid edits are blocked with specific error messages.

  • Benefit

    Structural errors are caught before they reach the database. The AI gets specific feedback about what is wrong, so it can fix the issue and retry.

Validation behavior comparison

Same invalid edit, different outcome for your site

New in 5.2
Before 5.2 No validation
AI writes invalid widget type

"super_heading" is not a registered Elementor widget

Saved
User opens page in builder

Broken widget, recovery mode, or missing section

Broken

Invalid data was saved to the database. The user discovered the problem later, with no clear path to fix it.

After 5.2 Schema validation
AI writes invalid widget type

"super_heading" is not a registered Elementor widget

Caught
Validation error returned to AI

Use "heading" instead of "super_heading" (registered widgets: heading, text-editor, image...)

Fixed
AI retries with valid widget type

Edit passes validation and saves correctly

Saved
Schema validation runs on every AI edit. Widget types, container hierarchies, and required fields are all checked. The AI receives actionable error messages so it can self-correct without user intervention.

Closing

The AI now speaks your builder's language. Your design intent survives.

Before Elemental, every AI edit was a translation exercise. The builder's native data went through HTML and back, losing information at every step. The more complex your layout, the more you lost. Responsive rules, hover states, custom CSS, container settings — all casualties of a format that was never designed to carry them.

Now the AI reads and writes in the builder's native format. Elementor JSON stays Elementor JSON. Divi blocks stay Divi blocks. When you do need HTML-to-builder conversion, the new pipeline handles it in discrete stages instead of one lossy step. And schema validation catches structural errors before they reach the database.

This release started with one user's bug report about dropped Elementor sections. It ended with intelligence modules for ten page builders, a conversion pipeline that preserves what the old approach was destroying, and a validation layer that catches errors before they corrupt your site.

Respira 5.2 Elemental — AI intelligence modules connected to page builder icons in a craftsman workshop

What shipped in 5.2

Ten builder modules, a conversion pipeline, and a new dashboard.

The builder intelligence modules are the headline, but the dashboard redesign matters for daily use. The new edit counter, agent breakdown chart, and guided setup stepper give you visibility into what AI is doing on your site without checking logs.

Feature 1

Surgical element-level editing

Before Elemental, changing a single heading meant downloading the entire page structure, modifying it, and uploading it back. Now AI agents can find_element, update_element, move_element, duplicate_element, and remove_element — targeting individual widgets by ID, type, or content. The page structure stays on the server. Only the changed element moves over the wire.

  • Edit one widget without touching the rest of the page
  • Find elements by ID, type, CSS class, or text content
  • Move, duplicate, reorder — all without full-page round-trips

Feature 2

build_page: one call, complete page

Instead of creating a page and adding elements one by one, AI agents can now send a single declarative structure and get a complete page back — sections, columns, widgets, styling, all rendered by the builder. Plus 27 widget shortcuts (add_heading, add_image, add_button, add_text, add_video...) for quick single-element additions.

  • Declarative structure → complete builder page in one call
  • 27 widget shortcuts for fast single-element additions
  • Builder auto-detection — send the structure, Respira picks the right builder

Feature 3

Stock images, governance, and dynamic schemas

Search Openverse for stock images and sideload them with proper CC attribution — SSRF-safe with domain allowlisting. Control which MCP tools are available per-site from the admin UI. And for Elementor sites, schemas are generated at runtime from the actual widget registry — AI always knows the exact settings available.

  • Stock image search + sideload with Creative Commons attribution
  • Admin toggle for every MCP tool — disable what you don't need
  • Runtime schema generation from Elementor's control registry
Respira Tool Governance — category-based toggles for Pages, Posts, Media, and Builder tools
Tool Governance lets admins disable any MCP tool per-site — one toggle blocks REST, MCP, and WebMCP access paths.
Respira API Key generation with Access Profiles — Full Access, Read Only, Content Editor, Builder
API Key Access Profiles scope each key to the tools it needs — Full Access, Read Only, Content Editor, or Builder.
Respira Settings page with risk-based zones — green for safe options, yellow for workflow changes, red for dangerous settings
Settings grouped by risk level — safe options are always visible, dangerous settings require confirmation.
Respira Undo Button — snapshot storage stats and version history per page
Every AI edit creates a snapshot. Browse versions, compare diffs, and restore with one click.
Respira Integrations — WebMCP and Angie AI agent configuration
Integrations panel for WebMCP browser connections and the Angie AI agent.
  • Batch operations with rate limiting

    Update up to 100 pages in a single call. Respira processes them sequentially with built-in rate limiting (3 bulk ops per hour) and captures snapshots before each mutation. Ideal for site-wide content updates, SEO meta changes, or holiday banner rollouts.

  • Tool governance admin UI

    Every MCP tool can now be enabled or disabled from the WordPress admin. If you don't want AI agents deleting pages or modifying plugins, turn those tools off. The governance layer blocks all access paths — REST, MCP, WebMCP — so disabled means disabled.

  • Dual tool naming for backward compat

    New respira_* tool names work alongside the existing wordpress_* names. Existing MCP configs and AI workflows keep working. The old names are deprecated but will be supported for at least two major versions.

  • Version migration engine

    The new Respira_Upgrader class runs safe migrations on plugin update. Upgrading from any previous version to 5.2.0 automatically creates new tables, sets default options, schedules crons, and adds database indexes — no manual steps.

  • Dashboard redesign

    Edit counter with monthly tracking, 6-metric grid (pages, posts, API calls, snapshots, pending changes), AI agent breakdown chart showing which tools edit your site, guided setup stepper with progress tracking, and a refined pine green design system.

  • API key access profiles

    Generate API keys with scoped permissions. Choose from Full Access, Read Only, Content Editor, or Builder profiles — each key only gets the tools it needs. Works alongside site-wide governance for a two-layer security model.

  • Built-in AI workflow guide

    The MCP server now ships a comprehensive instructions prompt that teaches AI models how to use Respira — per-builder content formats, common task recipes, and a clear "never touch SQL" rule. Models learn the right workflow (find_element → update_element) instead of hacking the database.

Try it

Example prompts you can use today

These are real prompts you can paste into Claude, Cursor, or any MCP-connected AI agent. Each one maps to one or more Elemental tools under the hood.

HTML → Builder conversion

convert_html_to_builder

Prompt

I designed a landing page in ChatGPT and it gave me the full HTML. Convert this HTML into native Elementor widgets on my WordPress site. Keep all the colors, spacing, and fonts. Create it as a draft so I can review it first.

What happens

  1. CSS Extractor pulls all inline styles, classes, and design tokens
  2. Section Mapper identifies hero, features, testimonials, CTA blocks
  3. Style Mapper translates CSS properties to Elementor widget settings
  4. Fidelity Checker reports what converted and what needs manual review

Surgical element editing

find_element + update_element

Prompt

On my homepage, find the hero heading and change it to “Ship faster with AI”. Also update the subheading font size to 18px. Don't touch anything else on the page.

What happens

  1. find_element locates the heading widget by type and position
  2. update_element changes the title text — only 50 tokens over the wire
  3. A second update_element adjusts the subheading font size
  4. The rest of the 200-widget page is never downloaded

Build a complete page

build_page

Prompt

Create a pricing page with three tiers: Starter at $9/mo, Pro at $29/mo, and Agency at $99/mo. Each tier should have a feature list, a CTA button, and the Pro tier should be highlighted. Use my site's existing color scheme.

What happens

  1. build_page sends one declarative structure with sections, columns, and widgets
  2. Respira detects your active builder and generates native elements
  3. The page is created as a draft with edit URL and preview URL returned
  4. One API call instead of 30+ sequential widget additions

Stock images + sideload

search_stock_images + sideload_image

Prompt

Find a hero image for my SaaS landing page — something with a clean desk setup and a laptop. Add it to my media library with proper attribution.

What happens

  1. search_stock_images queries Openverse with your description
  2. Results include license info, dimensions, and preview URLs
  3. sideload_image downloads the chosen image to your Media Library
  4. CC attribution is automatically set as the image caption

Bulk site-wide update

bulk_pages_operation

Prompt

Across all 47 pages on my site, find every instance of “Acme Corp” and replace it with “Acme Inc.” Show me what would change first before actually doing it.

What happens

  1. bulk_pages_operation runs in dry_run mode first — shows changes per page
  2. You review the preview, then confirm to execute
  3. Each page gets a snapshot before modification (automatic, non-optional)
  4. Rate-limited to 3 bulk ops per hour with concurrent execution lock

Move and reorganize

move_element + reorder_elements

Prompt

On my About page, move the testimonials section above the team section. Then reorder the team members so the CEO is first.

What happens

  1. move_element relocates the testimonials container to a new position
  2. reorder_elements rearranges children within the team container
  3. Both operations target specific elements — no full-page download
  4. Builder hierarchy (section → column → widget) is preserved

Technical details

What shipped

  • Element-level editing — find_element, update_element, move_element, duplicate_element, remove_element without downloading the page
  • build_page — create a complete page from a declarative structure in one call
  • 27 widget shortcuts — add_heading, add_image, add_button, add_text, add_video, and 22 more
  • Batch operations — update up to 100 pages in a single call with rate limiting
  • Stock images — search Openverse, sideload with CC attribution, SSRF-safe
  • Tool governance — admin UI to disable/enable any MCP tool per-site
  • Dynamic schemas — runtime widget schema generation from Elementor control registry
  • Schema validation — catches structural errors before save
  • Elementor intelligence — 167 widgets, container support, responsive breakpoints
  • Divi 5 intelligence — block-based storage, section/row/module hierarchy
  • WPBakery intelligence — shortcode mapping with 70+ elements
  • Beaver Builder intelligence — flat node map with 27 modules
  • Bricks intelligence — JSON structure with nestable elements
  • Gutenberg intelligence — 240+ blocks, FSE compatible
  • Oxygen, Brizy, Thrive Architect, Visual Composer — base intelligence
  • HTML→Builder content filter pipeline with CSS extraction, section mapping, style mapping
  • Dual tool naming — respira_* alongside deprecated wordpress_* for backward compat
  • Dashboard redesign — edit counter, 6-metric grid, AI agent breakdown, guided setup stepper
  • Version migration engine — safe upgrades from any previous version
  • UTF-8 passthrough — Chinese, Japanese, Arabic, and other multibyte characters preserved in API responses instead of \uXXXX escapes
  • Frontend cache purge — automatic invalidation of WP Super Cache, W3TC, LiteSpeed, Cloudflare, and 6 more on live edits and approvals
  • API key access profiles — generate keys with scoped permissions (Full Access, Read Only, Content Editor, Builder) for layered security alongside governance
  • Admin UI/UX polish — transparent logo, alternating row colors, improved settings readability, builder support badges
  • Beaver Builder HTML conversion — full pipeline with type mapping, multi-column layouts, and BB-native content merging
  • Builder cache invalidation on approval merge — Bricks CSS regen, Elementor file cache, Beaver asset cache, Divi resource clear
  • Direct edit mode — when enabled, AI writes go straight to the original post without queuing a duplicate
  • Gemini/Antigravity MCP compatibility — strict JSON Schema compliance for array types
  • Builder name resolution — single-word identifiers like "beaver" now match multi-word names like "Beaver Builder" across all 11 builders
  • Validation-before-confirmation — inject_builder_content validates the builder before showing the edit confirmation prompt
  • Gutenberg block format flexibility — validator accepts both simplified (type) and native (blockName) fields, and unwraps {blocks: [...]} wrappers
  • Built-in AI workflow guide — MCP server instructions teach models per-builder content formats and common task recipes

Breaking changes

None in this release

  • No breaking changes. Builder intelligence activates automatically for detected builders.
  • All new tools work on existing pages. The upgrade does not modify any stored content.
  • All existing Respira settings, snapshots, and configurations are preserved.

Migration guide

What to do next

  • Update the plugin to 5.2.0 from your WordPress dashboard.
  • Update MCP server: npm i -g @respira/wordpress-mcp-server@5.2.0
  • Builder intelligence activates automatically for detected page builders.
  • All new tools work on existing pages — the upgrade does not modify any stored content.
  • New respira_* tool names work alongside existing wordpress_* names — no config changes needed.

How to upgrade

Coordinated release — update both plugin and MCP server.

Plugin

WordPress Admin -> Plugins -> Update Respira for WordPress to 5.2.0

MCP Server

# Update to 5.2.0 for new tools + dual naming
npm i -g @respira/wordpress-mcp-server@5.2.0
# Or use npx (always runs latest):
npx -y @respira/wordpress-mcp-server

Verify builder detection

  1. Update to 5.2.0 from your WordPress dashboard.
  2. Open the Respira dashboard and check the builder detection status.
  3. Make a test AI edit on a builder page and verify layout fidelity.
  4. Check the new edit counter and agent breakdown on the dashboard.

Previous release

Before 5.2 taught AI to speak builder, 5.0 gave every edit an undo button.

If 5.2 is the builder intelligence release, 5.0 was the safety release — automatic snapshots on every edit, a Changes page to browse and restore, and merge mode that preserves your URLs.

Thank you

Built with our early adopters

Every fix in this release traces back to someone who took the time to report what wasn’t working. We’re grateful to our early adopters who submit bug reports, share feedback, and help make Respira better for everyone. This release is yours as much as ours.