This walkthrough is one job: change the intro of an About page to a Media & Text block, image on the left, without touching the live page until WordPress's own block editor has serialized the tree. The tool is WPPilot, a self-hosted WordPress plugin that turns the site into an MCP server. The Gutenberg workflow is in the free plugin. There are 11 Gutenberg abilities, and none of them require WPPilot Pro.

What you are actually installing

WPPilot Free does not bundle a model. Claude, Cursor, ChatGPT, or another MCP client brings its own. The plugin runs on your host. There is no WPPilot relay in the middle and no per-request fee. Requirements from the docs: WordPress 6.9 or newer, PHP 8.0 or newer, and HTTPS if a remote client connects.

Free is distributed from GitHub releases and from the site download, not from the WordPress.org plugin directory. Install and activate it, then connect the client. The connection guides cover OAuth 2.1 with PKCE and Application Passwords. Start on the Read Only safety profile. That profile is free, and it is the right first setting because a read of the block tree cannot rewrite the page.

The three profiles that ship in Free are Read Only, Production Safe (the install default), and Developer Full Access. Production Safe blocks PHP, WP-CLI, the filesystem, direct database access, and plugin or theme install and delete. You do not need Developer Full Access for this Gutenberg job.

Why the change is staged

The free Gutenberg module does not dump a raw post_content string for ordinary blocks. It keeps a pending batch. A draft batch is recoverable and does not alter the saved page. Static and native blocks are finalized inside a hidden editor frame so the blocks' own JavaScript can serialize them. Only blocks that WPPilot itself owns, and that are dynamic-only, may use the direct write ability. A Media & Text block is a core block, so it takes the queue.

Pro block-library modules (GenerateBlocks, Kadence Blocks, Spectra, and others) can expose catalogues and schemas. They still land through this same free queue. You do not need those modules to replace one core section.

The six calls, in order

Open the Block Editor Queue screen in wp-admin and leave that tab open. Then ask the agent to follow this sequence. Names below match the Gutenberg ability reference.

1. gutenberg-get-finalizer-runtime
   Confirms the queue page is open and heartbeating. If it is offline, the ability returns the admin URL to open. Do not queue a static block change while this reports offline.

2. gutenberg-get-content
   Reads the saved content of the About page as a compact block tree, and says whether a non-finished queue item already exists for that page. It does not return the queued spec itself. Pending work is summarized separately.

3. gutenberg-create-pending-batch
   Creates an empty draft batch. Draft batches cannot be finalized yet. That is intentional.

4. gutenberg-add-pending-change
   Adds one replace-content target: the About page, with a block tree whose intro is a Media & Text block and whose other sections you copied from the read in step 2. Queued is not live.

5. gutenberg-enable-batch-finalization
   Marks the batch ready only after every target you care about is queued. A half-built batch should not be marked ready. If the queue tab is open, it can pick the batch up. The response includes status URLs an agent can poll.

6. Read it back
   Use gutenberg-get-pending-batch until the batch reports finalized, then gutenberg-get-content again, and look at the editor and the front end. Do not tell anyone the intro changed because the queue accepted the spec.

Two more reads help when something sticks: gutenberg-list-pending-batches for the compact queue, and gutenberg-get-finalization-url for the admin page of one ready or failed batch. Two cancels remove queued work without editing the page: gutenberg-delete-pending-change for one item, and gutenberg-delete-pending-batch for the whole batch. The eleventh ability, gutenberg-write-content, is the direct path and refuses a tree that contains native or static blocks.

That is the full set of 11. Five are reads, and the writes that replace or finalize content ask for confirmation. The product page's representative session shows gutenberg-add-pending-change and gutenberg-enable-batch-finalization as confirmed calls.

A prompt that stays small

Give the agent a target, a block name, and a stop rule. Something like this:

Read the About page with the Gutenberg content ability. If the Block Editor Queue runtime is offline, stop and tell me the URL to open. Create one draft batch. Queue a replacement that changes only the intro to a Media & Text block with the image on the left, and keep every other block from the current tree. Do not enable finalization until you have shown me the queued target list. After I agree, enable finalization, poll until the batch is finalized, and read the content back.

That prompt refuses the failure mode where the model rewrites the whole page because "refresh the intro" was vague.

What "done" is not

A full-content replacement is still destructive even though it sits in a queue first. Read the tree, stage it, and keep a normal backup. The change ledger in Free records supported writes with a redacted before and after, and reversible operations can be rolled back. Rollback is not universal. Do not treat the ledger as a hosting backup.

Also do not confuse this with WPPilot Pro's approval queue. When that Pro switch is on, every write waits for a person and the admin can be emailed. Reads still run. This About-page job does not need that switch. Production Safe plus an explicit finalization step is enough for a single section.

If a batch fails or conflicts, cancel it with gutenberg-delete-pending-batch and start a new draft batch. Cancelling does not rewrite the About page.

Where this sits next to the rest of the plugin

The same free plugin also exposes WordPress core abilities (posts, media, comments, menus) and a free Elementor set. Deeper plugin integrations, including SEO metadata tools and the page-builder catalogues, are Pro. WooCommerce abilities are Pro and are not part of this Gutenberg flow. The free safety profiles, the preview-before-write path for ordinary post edits, and the change ledger apply around the queue. They do not replace the Block Editor Queue for static blocks.

The longer map of the 11 abilities, with the queue rules, is the Gutenberg MCP guide. Safety profile behaviour is documented under safety profiles. The free plugin source and releases are on GitHub.

If you try this, do it on a draft or on a page you can revert, with the queue tab actually open. The interesting part is not that an agent can invent block JSON. It is that the live page stays unchanged until WordPress's own editor accepts the batch.

For Elementor sites those questions are harder than they look, because Elementor doesn't store pages where most WordPress tooling expects them. This article covers why, what a safe element-level edit looks like over the Model Context Protocol (MCP), and, most importantly, where rollback does and doesn't cover you. Some of these limits surprised me when I read the documentation closely.

The examples use WPPilot, a GPL plugin that turns WordPress into an MCP server and ships Elementor editing abilities in its free edition. If you want a broader walkthrough of connecting a client and the everyday jobs you can hand to an agent, I covered that in a beginner's guide on DEV. This article focuses on Elementor only.

The silent-success problem

A classic WordPress post keeps its body in post_content. Elementor keeps the layout in postmeta, as a typed tree of containers and widgets, and renders from that tree. Beaver Builder works the same way (_fl_builder_data), and so do Oxygen and Bricks with their own trees. Divi, Etch and WPBakery are different: they put their markup in post_content.

So a generic "update the page" call against an Elementor page does something odd. The REST request succeeds, the database changes, and visitors see nothing new. The builder may even overwrite your change from its own tree the next time someone saves in the editor.

WPPilot's changelog describes the fix it shipped: writing post_content to a page built with Elementor, Bricks or Beaver Builder "is now refused instead of silently doing nothing", and the refusal names the builder and the ability that owns the page. You can still force the write for feeds and search with an explicit flag, and the response then says the page itself didn't change.

That behaviour, an honest refusal instead of a fake success, is the first thing I'd test in any AI-for-WordPress tool.

Element-level editing, not document dumps

The alternative is to edit the tree itself, one element at a time. WPPilot Free registers 17 Elementor abilities (in 1.13.0) once Elementor 3.6 or newer is active. Editing has been free since 1.10.0, and the atomic-readiness audit came in 1.13.0. The abilities fall into three groups.

Reads (safe in any profile):

• elementor-check-setup: Elementor and Pro versions, and whether the v4 atomic runtime and its sub-features exist
• elementor-audit-atomic-readiness: how much of the site is v4 atomic vs classic v3
• elementor-get-content: a compact skeleton by default (ids, types, children), with one element's full settings on request
• elementor-find-elements: ids and paths for elements matching a widget type, a setting or text
• elementor-get-widget-params, elementor-get-page-settings, and elementor-get-schema, which lists the widgets and controls on this install

Targeted writes:

• elementor-edit-element: merges new settings into one element
• elementor-add-element, elementor-move-element (keeps id, settings and children), elementor-duplicate-element (fresh ids for the copy), elementor-reorder-children
• elementor-set-page-settings: merged, validated page settings
• elementor-clear-document-cache: clears the rendered-element cache so the next view rebuilds

Destructive, confirmation required:

• elementor-delete-element: the reference says "Permanent - there is no trash for Elementor elements."
• elementor-set-content: replaces a whole document tree. Invalid properties are dropped and named in the response, or you can pass strict to refuse the write instead.

The design choice here is that a typical edit never needs the whole document. An agent that reads a skeleton, finds three ids and patches those three elements uses far fewer tokens. It also can't reformat the other forty widgets while it's at it.

A read-first sequence looks like this:

elementor-check-setup        → v3, v4 atomic, or both on this site?
elementor-get-content        → compact skeleton of post 482
elementor-find-elements      → ids of every button with text "Contact us"
elementor-get-widget-params  → which settings those buttons actually use
elementor-edit-element ×3    → change only the text setting on each id
get-page-view-link           → preview URL to check at desktop / tablet / mobile

You don't have to spell this out in every prompt. WPPilot's discovery call returns a catalogue of the skills saved on the site, with an instruction to load a matching one before starting. The Skills module that manages them is in the free plugin, not Pro. You can also add site-wide instructions, for example "never publish", "keep our heading scale" or "always read the skeleton first".

Now the part people skip: rollback

Every write WPPilot makes lands in a redacted change ledger. The ledger records the ability, the target and the credential that acted: the OAuth client id (stored hashed) or the Application Password's UUID, plus the client name the agent reported. You read it with list-changes and get-change, and reverse supported entries with rollback-change. A rollback checks the current state against a stored before-image fingerprint, so it won't overwrite a human edit made in the meantime.

The key word is supported. For Elementor, here is the rule as the documentation states it:

On Free alone these edits are recorded without a way back; with Pro active the ledger also keeps a copy of the document, so they can be rolled back from the entry.

In practice:

After a Pro rollback, the docs suggest opening the page in Elementor once to confirm the tree looks right.

For context, Elementor isn't the only area where "recorded" doesn't mean "reversible". WPPilot's own use-case pages say SEO metadata edits and WooCommerce product edits are logged with no rollback either. The ledger is an audit trail first and an undo button only for specific operations. It holds at most 500 records and isn't a backup.

A Free-only workflow that doesn't need rollback

If you're on the free plugin, plan so that you never need to undo an Elementor edit:

1. Work on a copy. Duplicate the page, or have the agent create a new draft, and point every edit at that. A draft can simply be deleted.
2. Save the before-state yourself. Ask for elementor-get-content with full settings on the elements you're about to change, and keep that output. It's your manual restore point.
3. Use Read Only for exploration. Setup checks, skeleton reads and element searches all work under Read Only. Switch to Production Safe only for the edit session.
4. Keep writes small. Three elementor-edit-element calls are easy to check. One elementor-set-content is a full replacement that asks for confirmation for good reason.
5. Attach evidence. capture-page stores a screenshot alongside the entry, so the record shows how the page looked at that moment.
6. Verify in two places: the Elementor editor and the front end. A successful tool call isn't a finished page.

Guardrails that apply either way

The server enforces three safety profiles on every call:

• Read Only blocks all writes.
• Production Safe, the installation default, allows content and design edits but blocks raw PHP, WP-CLI, filesystem and database access, and plugin installs.
• Developer Full Access allows everything enabled and belongs on staging.

WordPress capabilities are checked per request, so connect the agent as an Editor-level user, not your admin account. Individual abilities can be switched off, writes are rate-limited per credential, and new content defaults to draft. The details are in the safety profiles documentation.

When Pro is worth it for Elementor work

The free plugin edits Elementor pages. Pro adds three things that matter here:

• the ledger keeps a document copy, so element edits become reversible
• the authoring layer: elementor-build-page for whole-page composition, templates and display conditions, popups, global classes and variables
• a human approval queue that holds every write until someone signs off, and emails the site admin

If agents touch client sites while nobody is watching, the rollback and approval features are the strongest reason to upgrade. Plans differ only by site count; see pricing.

Takeaways

• A tool that edits Elementor through post_content will report success and change nothing. Insist on element-level abilities or an honest refusal.
• Read the skeleton, patch ids, verify visually.
• "It's in the ledger" doesn't mean "I can undo it". On Free, Elementor element edits have no rollback. With Pro active, they do.
• Design your workflow around the undo you actually have: drafts and copies on Free, ledger rollback plus approvals on Pro.

The plugin source, including the Elementor abilities and the safety model, is on GitHub under GPL-2.0-or-later.