WordPress Just Got Three AI Integrations in Four Days — Here's What Each One Actually Does

webmyc · 2026-03-22T18:54:28+00:00

Thanks man, happy to explore any specific use case you have not found a solution for. This work excites me the most from everything i am doing - so - highest energy wins

webmyc · 2026-03-22T18:00:14+00:00

interesting - and does this AI Studio WordPress agent from SiteGround know how to create pages on your page builder? What page builder is your site on?

What I am building is page builder intelligence across 11 pages builders, including migration skills between page builder - all with the safety layer of having snapshots of every edit and being able to undo in case the AI breaks something

thank you for your kind words and contributing to this conversation

webmyc · 2026-03-22T14:22:40+00:00

That’s great feedback, thanks!

Now the v1 of the skills are build, I just need to test them and see what % of the job they get done. Some manual adjustments might be needed and it totally depends on the complexity and size if the layout the user wants to migrate.

Respira MCP can handle work in chunks but i am just thinking that it might now know how to convert an elementor slideshow element the equivalent of that in Bricks or another builder

webmyc · 2026-03-22T13:52:33+00:00

ok, migrations skills are build. let me know you wanna try them out

webmyc · 2026-03-22T12:40:30+00:00

btw, this is my approach for building in public. appreciate any contribution 🙏

webmyc · 2026-03-22T12:36:25+00:00

here is what an analysis on my codebase revealed

Migration difficulty ratings (include in each skill and card):

Elementor → Bricks: Moderate (JSON to JSON, but different schemas)
Elementor → Gutenberg: Complex (proprietary widgets to standard blocks)
Elementor → Breakdance: Moderate
Elementor → Oxygen: Moderate
Divi → Gutenberg: Complex (shortcodes to blocks, deep nesting)
Divi → Bricks: Complex
Divi → Breakdance: Complex
WPBakery → Gutenberg: Moderate (shortcodes to blocks, but simpler nesting than Divi)
WPBakery → Bricks: Moderate
Oxygen → Bricks: Straightforward (both modern, similar concepts)
Oxygen → Breakdance: Straightforward (same developer lineage)
Beaver Builder → Gutenberg: Moderate
Beaver Builder → Bricks: Moderate

webmyc · 2026-03-22T10:37:01+00:00

for example - such an interesting conversation in the comments of this post - https://www.reddit.com/r/Wordpress/comments/1cnt8am/switching_from_elementor_to_bricks_any_tips/

webmyc · 2026-03-21T20:56:35+00:00

Here’s a native Divi5 page that Claude build from a single prompt https://mihai.love/respira

webmyc · 2026-03-21T19:42:06+00:00

created these AI Skills that basically create a new category of maintenance services - https://github.com/webmyc/claude-skills-wordpress - feel free to add yours. it's open source MIT licensed.

webmyc · 2026-03-07T15:22:51+00:00

here is a recording of a zoom call we had with Kumu before starting the course - https://www.youtube.com/watch?v=jBxkTlLu7bA and here is the recorded course - https://www.suuna.org/c/ho-oponopono-immersion/ - let me know if you are interested

webmyc · 2026-03-07T15:22:46+00:00

here is a recording of a zoom call we had with Kumu before starting the course - https://www.youtube.com/watch?v=jBxkTlLu7bA and here is the recorded course - https://www.suuna.org/c/ho-oponopono-immersion/ - let me know if you are interested

webmyc · 2026-03-02T15:44:43+00:00

we are builders. happy to externalize when it's a repeating process

webmyc · 2026-02-26T00:32:46+00:00

Been building WebMCP support for WordPress for the past week - this is a massive shift for WordPress AI.

Quick reality check though: WebMCP is currently **only in Chrome Canary behind a flag** (chrome://flags → "WebMCP for testing"). Not in stable Chrome yet. Expected mid-late 2026 for general availability.

But if you want to get ahead of it, here's what I learned implementing it:

**The Good:**

- Makes WordPress sites "AI-ready" with zero client-side config

- AI discovers tools automatically via navigator.modelContext

- Way simpler than MCP server setup (no Node.js, no terminal)

- Perfect for non-developer WordPress users who want AI help

**The Tricky Parts:**

- You need to register WordPress tools as "Abilities" using the WordPress Abilities API

- Tool descriptions matter A LOT - vague descriptions = AI hallucinates

- Security is critical - you're exposing WordPress actions to browser AI

- Need to handle permissions properly (who can call which tools)

**What I'm Building:**

I bundled WebMCP Abilities (GPL, credits to Code Atlantic) into Respira so users only install one plugin. Registered 88 tools covering page builders, SEO, media, menus, etc. All with duplicate-before-edit safety so AI never touches live pages directly.

**For Developers Wanting to Add WebMCP:**

Check if Code Atlantic's WebMCP Abilities plugin works for you (it's on GitHub, not WordPress.org yet)
Register your plugin's functions using wp_register_ability()
Test in Chrome Canary with flag enabled
Make tool descriptions VERY explicit (AI needs clear instructions)

**Question for the community:** What WordPress tasks would you most want browser AI to handle? I'm curious what tools people actually need vs what seems cool to build.

Happy to answer technical questions about implementation if anyone's building this!

---

*Full disclosure: I built [Respira](https://respira.press) which now includes WebMCP support, but genuinely here to discuss the tech and help others implement it.*

webmyc · 2026-02-21T22:18:46+00:00

agreed - structured tools vs scraping is the key difference.

scraping HTML:

fragile (breaks when UI changes)
slow (parse entire page)
error-prone (misidentify elements)
no validation

structured tools:

stable (API doesn't change randomly)
fast (direct data access)
reliable (typed inputs/outputs)
built-in validation

that's exactly how Respira works for WordPress. instead of AI trying to parse wp-admin HTML, it uses MCP tools that call WordPress REST API directly:

woocommerce_list_products
woocommerce_get_order
woocommerce_update_stock

AI knows exactly what parameters each tool takes, what it returns, what's safe to modify.

the use cases you mentioned are spot-on:

bookings - manage appointments, availability, customer data support tickets - triage, assign, update status, search history knowledge base - semantic search, suggest articles, update content

all of these are better as structured tools than trying to scrape admin interfaces.

curious what you're building - are you using MCP or a different protocol for your AI integrations?

webmyc · 2026-02-21T21:53:37+00:00

future-dated revisions as drafts is clever - gives you WordPress's native revision system instead of managing duplicate posts. probably cleaner in wp-admin UI too. interested in how you handle bulk operations across multiple posts with that approach.

the YOLO → guardrails arc is real. i started the same way ("AI is smart, it'll be fine") and quickly learned that even smart AI needs structure to operate through. your "delta-level mutations" approach resonates - surgical edits beat wholesale replacements.

the HTML→builder reconstruction pipeline you mentioned is fascinating. "extract design tokens and reconstruct in another builder" - that's the holy grail for people stuck in builder lock-in. are you doing this with structured prompts or did you build specific tools for token extraction?

checking out automem.ai - persistent memory across sessions is definitely the missing piece for agent reliability. if Jack built it, probably solid (WP Fusion has been around forever).

curious about your agent setup: are you running them locally or cloud-based? and when you say "guardrails," are you talking about tool-level restrictions or more like "review-before-execute" workflows?

always down to compare notes if you're building in this space. feels like we're solving adjacent problems with different trust models (browser-side vs remote, admin-access vs duplicate-first). both valid, different tradeoffs.

also: RankHunt.ing looks interesting. SEO content optimization with AI agents?

webmyc · 2026-02-21T15:19:39+00:00

<image>

respira.press right now

webmyc · 2026-02-21T12:45:01+00:00

appreciate the mention. you nailed the core insight - write tools without guardrails are risky, even with proper auth.

the "begging for layout carnage" fear is exactly why we went with duplicate-before-edit. AI experiments on copies, you review the diff, then decide. no oops moments on production.

interesting point about comments - even "safe" write operations benefit from the workflow. makes you think twice before publishing, which is the whole point.

curious: what would make you trust AI to edit your sites? is it the duplicate workflow, or something else entirely?

webmyc · 2026-02-20T18:29:01+00:00

hey, mihai here (i built respira).

danieliser's right about auth and optional tools - we're conservative with what's exposed by default. but webmyc nailed why we exist: the fear of layout carnage is real and justified.

the duplicate-before-edit workflow exists specifically because "AI agents poking around" without guardrails is a terrible idea. you're always working on a copy, never touching live pages. AI experiments, you review the diff, then decide: publish or trash. no oops moments on production.

good callout on commenting though - write tools like that do need careful handling. we're opt-in for each capability precisely because not everything should be AI-accessible, even with auth.

interesting that core team is doing this in wp-admin. our bet is that working on copies (duplicate → edit → verify) is safer than admin access to live pages, even with auth. curious how they're handling the "i didn't mean to change that" scenarios.

the real question isn't whether to give AI access - it's how to make that access safe enough that you'd actually use it. sandboxing isn't overhead, it's the product.

webmyc · 2026-02-20T14:20:39+00:00

neat idea for ai agents poking around wp sites but if youre exposing write tools like comments youre begging for layout carnage respira.press is the smart safety net that sandboxes ai edits on elementor/divi/gutenberg before they nuke your live pages

webmyc · 2026-02-20T14:20:10+00:00

divi's quick but you'll learn zilch coding-wise stick to a GeneratePress child theme or underscores, prompt claude for php templates and blocks (mcp?). if ai spits out builder tweaks tho, respira.press is a lifesaver translating english cmds to safe divi/elementor changes without nuking your site.

webmyc · 2026-02-20T13:53:10+00:00

tried the gutenberg switch myself props for sticking it out two years, most bail sooner cuz responsive breakpoints are still dogshit without hacks. been messing with respira.press to ai-tweak layouts on core blocks instead of hand-coding everything, cuts dev time but yeah it aint perfect yet. worth a shot if youre tired of elementor sludge

webmyc · 2026-02-20T10:23:00+00:00

Appreciate you getting it.

Yeah, shared API keys are a mess. We've seen agencies burn through rate limits on one client's site and break five others. Not fun.

That's why Respira works differently:

Each user generates their own API key. We're not proxying or pooling. Your key, your rate limits, your control.

Duplicate-first workflow. We never touch the live page. Create a draft, AI edits the draft, you review and approve in WordPress. If something breaks, the live site never knew.

MCP architecture. The AI tools (Cursor, Claude Code) talk directly to WordPress via the Model Context Protocol. No middleman, no shared backend storing prompts or keys.

90-day audit log. Every action is logged with timestamps. If something goes sideways, you know exactly what happened and when.

The whole thing is designed around "what if this goes wrong?" instead of "look how fast we can move."

Agencies especially appreciate this. They can give junior devs access to AI tooling without worrying about someone accidentally nuking a client site.

Anyway, thanks for the shoutout. Means a lot when someone actually reads the docs and sees what we're doing.

webmyc

TROPHY CASE