WordPress and WooCommerce

The MCP tools that change a live public website, the three scopes they sit behind, and the five rules every one of them obeys.

These tools change something outside RankX AI, and everything about them follows from that. They edit a live, publicly visible website using the WordPress connection you set up, so every edit dry-runs first or acts only on what a person has already approved, every write is verified by reading the object back, and a write that cannot be done safely is refused rather than attempted.

The Shopify tools are the other surface that does this, under the same rules and the same scope. The one difference worth knowing before you read further: WordPress keeps revisions, and on Shopify, which keeps none, RankX AI records the previous value itself.

Tool	Scope	What it does
`get_publication_status`	read	Where a Content Studio article stands on its website after publish_content_item, with each field (body, SEO title, meta description, schema, featured image, categories and tags, author, slug) reported as verified, written, not writable, failed or skipped.
`publish_content_item`	publish	Sends an approved Content Studio article to the connected WordPress site as a draft, scheduled for later or live now, and verifies it by reading the post back. It changes a real public website, spends no credits and refuses an article nobody has approved.
`wp_advanced_request`	site_admin	Sends one specific REST request to a connected WordPress site, for anything the other tools do not cover. Available on every connected WordPress site; WooCommerce customer, order, subscription and checkout routes answer only where an administrator has switched on store customer and order data. Its result cannot be verified afterwards, which is why it dry runs first.
`wp_bulk_update`	publish	Applies one change across an explicit list of ids. The live call is refused unless it carries the batch id the dry run returned for exactly that list.
`wp_create_content`	publish	Publishes a new post or page. It creates a draft unless you explicitly ask to publish, and an idempotency key makes a retry return the original rather than creating a second post.
`wp_create_product`	commerce	Adds a new product to a connected WooCommerce store, always as a draft. It cannot publish, so a human reviews the price and details in WooCommerce first.
`wp_create_term`	publish	Creates one category, tag or custom taxonomy term. A name that already exists under different capitalisation is reported back rather than silently reused, and rename and delete deliberately do not exist.
`wp_delete_content`	publish	Moves a post or page to the trash, where it can be restored. There is no permanent delete and no flag that makes one.
`wp_describe_site`	publish	Describes what a connected WordPress site actually supports: which content types are editable, which taxonomies exist, whether SEO fields are writable, and whether a page builder is in use. Call it first, because nothing about a WordPress site can be assumed.
`wp_edit_blocks`	publish	Adds, places or removes whole blocks on a page, which a text patch deliberately cannot do. Its outline action is free and lists every block with its id.
`wp_get_content`	publish	Reads one post, page or custom object, including whether its body can be rewritten at all. A long body is truncated and says so, which matters because a whole-body write would delete the part you did not see.
`wp_get_schema`	publish	Reads the structured data on a WordPress page: which SEO plugin runs and where a new schema would go, every schema stored for the page, and every other JSON-LD node the live page prints, which is how duplicates show up.
`wp_get_seo_coverage`	publish	Checks which SEO features a WordPress site actually outputs, read as a visitor would, from the title and meta description to structured data, the sitemap, robots.txt and llms.txt, and says for each whether it is printed, missing, partial or printed twice, and where it is fixed.
`wp_list_content`	publish	Lists posts, pages or any custom content type. Every row reports whether its body can be rewritten, so page-builder pages are visible rather than discovered on a refusal.
`wp_list_products`	commerce	Lists WooCommerce products with prices, stock status and how much description each carries, flagging the ones too thin to sell or rank. Read only.
`wp_list_redirects`	publish	Shows which redirect manager a WordPress site uses, the redirects already there with their hit counts and, where the site keeps a 404 log, the missing addresses visitors actually hit.
`wp_list_revisions`	publish	Lists a post or page's WordPress revisions, which is what an edit can be rolled back to. Some content types have none, and it says so plainly.
`wp_list_terms`	publish	Lists categories, tags and custom taxonomy terms. List before creating with wp_create_term: a term that already exists under different capitalisation is not found by name, and near-duplicate terms are hard for a customer to undo.
`wp_manage_redirect`	publish	Adds or removes a redirect on a live WordPress site through its own redirect manager. It only redirects an address that is genuinely missing, to a page on the same site that loads directly, and it dry runs by default.
`wp_media`	publish	Lists media library images, uploads a new one, or sets alt text, caption and title. Its missing-alt list comes from a bounded scan and always reports the scanned and total figures.
`wp_patch_content`	publish	Changes specific text inside an existing page without rewriting the rest of it. Preferred over a whole-body update: it is safe on long pages and far cheaper, and if any edit fails to match, nothing is written.
`wp_site_admin`	site_admin	Inspects a site's settings, menus, users, comments, widgets, templates, plugins and themes. Only site settings and comment moderation can be changed; plugins, themes and users are read only.
`wp_update_content`	publish	Updates the title, body, excerpt, slug, categories, tags or featured image of an existing page. It replaces the whole body, so a small edit belongs in wp_patch_content instead.
`wp_update_product`	commerce	Rewrites a WooCommerce product's description and SEO fields. Price, stock, status and the product URL cannot be changed by this tool and are reported before and after so you can see they were not.
`wp_update_schema`	publish	Adds, replaces or removes one schema on a WordPress page through the site's SEO plugin, never by editing the page body. It dry runs by default and refuses the write if the page's schema changed after wp_get_schema read it.
`wp_update_seo`	publish	Sets the SEO title and meta description of a post or page. Many SEO plugins do not expose these fields at all, and it refuses rather than appearing to succeed.

The table above is generated from RankX AI itself rather than written by hand, as at 30 September 2026 (source b27dec96). 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`

Scope	Reaches
`publish`	Content, taxonomies, media, SEO metadata, structured data, redirects, revisions, bulk edits, and publishing Content Studio articles
`commerce`	WooCommerce products
`site_admin`	Site configuration, comment moderation, and the advanced request escape hatch

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 edit 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. The one write here with no dry run is publish_content_item, and a human decision stands in its place: it refuses an article nobody has approved, and it takes the action (draft, schedule or publish) as an explicit instruction rather than assuming one.

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. Meta-based page-builder pages are protected. 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.

You want to	Use	Not
Change some text on an existing page	`wp_patch_content`	`wp_update_content`
Add, move or remove a whole block	`wp_edit_blocks`	`wp_patch_content`, which refuses
Replace an entire page body	`wp_update_content`	anything, if the page is long
Create a new post or page	`wp_create_content`
Change the same field on many pages	`wp_bulk_update`	a loop of single writes

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. On a site with the optional RankX AI plugin it writes them through every major SEO plugin, All in One SEO included, and on a site with no SEO plugin at all. Without the RankX AI plugin, whether it can depends 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 only once a small registration is added, and All in One SEO keeps them in its own database tables, which the RankX AI plugin reaches and the REST API does not.

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.

wp_update_seo writes the SEO title and meta description only. A request for Open Graph or Twitter fields is refused on every site.

Publishing a Content Studio article

publish_content_item sends an approved Content Studio article to the connected WordPress site, as a draft (saved on the site, not public), scheduled for a time at least two minutes ahead, or published now. It spends no credits.

Approval comes first, and it is a separate step on purpose: approve_content_item records the person's sign-off, and an unapproved article is refused with that as the remedy. The tool is also refused while the same article is already being published, and on a project with several connected WordPress sites it names them rather than choosing one.

It returns at once and the work carries on in the background. Poll get_publication_status until it settles. It reports each field on its own (body, SEO title, meta description, schema, featured image, categories and tags, author, slug) as verified, written, not writable, failed or skipped, which is why "published" alone is not an answer to pass on. A state of unconfirmed means the write may have landed and could not be read back: check the site, and do not publish again.

Structured data goes through the SEO plugin

wp_get_schema reports which SEO plugin runs, where a new schema would be stored, every schema already stored for a page and every other JSON-LD node the live page prints, which is how duplicates show up. wp_update_schema then adds, replaces or removes one schema through that plugin, never by editing the page body. It dry-runs by default, shows the before and after and any duplicate of the same type, and refuses the write if the page's schema changed after it was read.

Redirects go through the site's own redirect manager

wp_list_redirects shows which redirect manager takes new redirects (the Redirection plugin, Rank Math, or the RankX AI plugin itself), or why none can and what fixes that, with the redirects already there and, where the site keeps a 404 log, the missing addresses visitors actually hit.

wp_manage_redirect adds or removes one. It only redirects an address that is genuinely missing, because redirecting a page that still loads would hide it, and the destination must be on the same site and load directly: no chains and not the homepage. It dry-runs by default, and a real run is confirmed by reading the redirect back and following the old address.

Check what the site actually prints

wp_get_seo_coverage reads a site's pages as a visitor would and reports, for the title, meta description, canonical, robots tag, Open Graph, the Twitter card, structured data, breadcrumbs, the XML sitemap, robots.txt and llms.txt, whether each is printed, missing, only on some pages or printed twice, and where it is fixed. It works whatever SEO plugin the site runs, including ones RankX AI has no integration for, and it changes nothing.

What these tools leave to you

These safeguards are built into the tools, and no input changes them:

No user writes at all, and no application-password creation.
No plugin or theme install, activation or update. Read only.
No redirect without a redirect manager it can read back. With none of the three installed, wp_manage_redirect refuses and wp_list_redirects names the fix, rather than writing something it cannot check.
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 available on every connected WordPress site, with no switch to find. The one switch that remains is per store: WooCommerce customer, order, subscription and checkout routes answer only where an administrator has switched on store customer and order data for that connection. Some routes stay blocked whatever the settings: creating application passwords, permanent deletion, plugin and theme changes, user changes, refunds, changing the site address, bulk endpoints, and a query that tries to change the route or method.

And it is checked before it runs rather than after: the meaning of an arbitrary route is not knowable, so a read-back cannot confirm it, and instead 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."

"Which 404s are visitors hitting most? Dry run a redirect for the top one to the page that replaced it."

"Approve content item X, then publish it to my site as a draft and tell me which fields were verified."

"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.

Last updated 1 October 2026

WordPress and WooCommerce

On this page