WordPress and WooCommerce

These are the only tools on the RankX AI MCP server that change something outside RankX AI, and everything about them follows from that. They edit a live, publicly visible website using the WordPress Application Password you connected, so every write dry-runs first, every write is verified by reading the object back, and a write that cannot be done safely is refused rather than attempted.

The table above is generated from RankX AI itself rather than written by hand, as at 19 August 2026 (source 377ef780). When the product changes, this page changes with it.

Call wp_describe_site first

A WordPress site only exposes what its plugins and the connected account allow, so nothing about it can be assumed. wp_describe_site reports which content types exist and are editable, which taxonomies exist, whether SEO fields are writable, whether WooCommerce is present, and whether a page builder is in use.

Everything else here reads better with that answer in hand, and several of the tools' refusals only make sense once you have it.

Three scopes, and none of them is write

The reads are gated too, which deviates from the usual rule that enumerating is not mutating. Two reasons: these reads spend your stored WordPress credential against a third-party system, and one of them returns prices and stock for a whole catalogue.

And scopes are immutable at issue. A credential created before these tools existed was granted on the understanding that it acts inside RankX AI and that everything it does is reversible. Folding these into an existing scope would have handed every credential already in the wild a capability its owner never agreed to.

The five rules

1. Every write dry-runs by default. An assistant must opt in to changing a live site. The dry run runs the identical pipeline as the real write, so the warnings it produces are the warnings the write will produce.

2. Explicit ids only. No tool resolves a target by title or fuzzy match. That is how the wrong live article gets edited. Get the id from wp_list_content or wp_list_products, never by guessing.

3. Page-builder pages are refused, not damaged. A page whose builder stores content outside the page body is listed as not writable and refuses a body write, and there is no override from MCP, ever. An unrecognised builder namespace is classified the same restrictive way, deliberately: refusing by shape rather than by name keeps the guard working for a builder RankX AI has never seen.

4. Writes are verified by reading the object back, never by a success response. Plugins that return success while persisting nothing are common enough that a status code proves nothing. The read-back bypasses the site's page cache, without which a successful write reports as failed on most managed hosts.

5. Nothing you send is discarded. A body the converter cannot map to native blocks is preserved verbatim in a raw HTML block and reported.

Choosing the right write tool

This is where most integrations go wrong, and the rule is simple: prefer the smallest edit that does the job.

wp_patch_content is the default for editing an existing page. It changes exact text inside existing blocks and nothing else, so it is safe on a page long enough to be truncated on read, and far cheaper than resending the whole body. If any of its edits fails to match, nothing is written at all.

wp_update_content replaces the whole body. That makes it unsafe after a truncated read: wp_get_content truncates a very long body and says so, and sending that back would delete the part you did not see. The tool says this in its own description, and it is the single most damaging mistake available here.

wp_edit_blocks has a free outline action that lists every block with its id, index, depth and a text preview. Call it before targeting a block, because guessing an index is how the wrong thing moves. Prefer its structured block input over raw markup: it builds correct markup from a media id, URL and alt text, and keeps the copies a builder block stores of its own id and alt text consistent. Hand-written markup that gets those wrong is the usual way a block ends up flagged invalid in the editor.

Bulk edits are refused without their dry run

wp_bulk_update applies one change across an explicit list of ids, and its live call is refused unless it carries the batch id the dry run returned for exactly that list. Change the list and you need a new dry run.

It returns per-item results, always. Report failures individually rather than summarising the run as a success.

SEO metadata depends on the plugin

wp_update_seo sets the SEO title and meta description. Whether it can depends entirely on how the site's SEO plugin stores them and whether it exposes them. Some plugins expose them by default, some only per content type, some not at all until a small registration is added, and one stores them in its own database tables where no configuration can help.

When a write is not possible, RankX AI does not report a flat "cannot write". It names which case applies and, where a registration would fix it, returns the snippet with the site's actual field names in it. The remedy travels with the refusal, on the tool that hit the wall, rather than living on a different tool the caller never reached.

Open Graph and Twitter fields cannot be set on any site and are refused everywhere.

What these tools deliberately cannot do

Permanent limits, not a roadmap:

• No user writes at all, and no application-password creation.
• No plugin or theme install, activation or update. Read only.
• No redirects. The common SEO plugins either expose no redirect route or expose a write that cannot be verified, and RankX AI does not ship an unverifiable write.
• No permanent deletion. wp_delete_content moves a post to the trash, and there is no flag that changes that.
• No price, stock, status or slug change on a product. wp_update_product is given no input for any of them, and the price is reported before and after so you can confirm it did not move.
• wp_create_product always creates a draft. Publishing makes a product buyable, and that is a human decision.
• No order, customer or refund writes. Reads only, by construction.

The escape hatch

wp_advanced_request sends one arbitrary REST request, for a plugin's own endpoints that no named tool covers. Three things bound it:

It is off unless an administrator switches it on for that connection, and it is hidden from the tool list until they do. Some routes stay blocked whatever the setting: creating application passwords, permanent deletion, plugin and theme changes, user changes, refunds, and changing the site address.

And its result cannot be verified afterwards, because the meaning of an arbitrary route is not knowable. That is the one place RankX AI's verification guarantee does not reach, which is exactly why it dry-runs, shows the exact request, and asks.

Products

wp_list_products reports prices, stock status and how much description each product carries, and flags the ones too thin to sell or rank. wp_update_product rewrites descriptions and SEO fields only.

One caution the tool states itself: products have no revision history in WordPress, so a product edit cannot be rolled back from the site. Check wp_list_revisions before proposing a change someone may want to undo; it reports plainly when a content type has none.

Example prompts

"Describe my connected WordPress site. What can actually be edited?"

"List the pages with thin meta descriptions, then dry run a fix for the worst five and show me the diffs."

"Change the phrase 'AI monitoring' to 'AI visibility tracking' on page 412. Dry run first."

"Show me the block outline of page 88, then insert an image after the second heading using media id 3391 with alt text describing the dashboard."

"Which of my media library images have no alt text? Report the scanned and total figures with the count."

"List WooCommerce products whose description is too thin, and rewrite the top three. Confirm the prices did not change."

Where to go next

• The WordPress integration for connecting and for the SEO-plugin detail.
• WooCommerce for the product side.
• Troubleshooting connections when a write is refused.