WooCommerce 10.9 Is Now Agent-Ready With Native MCP

WooCommerce 10.9 makes WordPress stores natively addressable by AI agents — the release ships seven canonical domain abilities exposed through the WordPress MCP Adapter, so any Model Context Protocol client can query and update products and orders against a live store. It landed on the WooCommerce developer blog on June 23, 2026, and reached WordPress dashboards a day later.

The significance is the hosting footprint behind it. WordPress powers 42.5% of all websites as of April 2026, and WooCommerce sits on millions of those installs. That entire surface just gained an agent-control layer without anyone switching platforms — and without shoppers seeing a single new feature. What 10.9 ships is plumbing, not a button.

This guide covers exactly what landed, the seven abilities and their safety properties, how to connect Claude Code or any MCP client, how WooCommerce’s management-layer approach differs from Shopify’s buyer-journey UCP, and the developer-preview caveats you should weigh before trusting an agent with a production store. Every figure below is sourced from the official WooCommerce and WordPress developer documentation.

MCP first arrived in WooCommerce as a beta in version 10.3, released October 21, 2025. WooCommerce 10.9 marks the step up from that beta to a canonical, schema-defined abilities layer — a stable contract for what an agent is allowed to do, rather than an experimental endpoint. The release itself was built by 65 contributors across 464 pull requests and requires a database update, though it stays backwards compatible.

The abilities layer is described by the WooCommerce team as transport-neutral: the same canonical ability can be exposed through MCP, the WordPress REST API, WP-CLI, admin tooling, and future agent surfaces. One implementation, many surfaces. That design choice matters more than the MCP endpoint itself, because it means WooCommerce is not locked to MCP’s current spec version — when the protocol evolves, the registered abilities survive.

Two further experimental pieces shipped in 10.9 that are worth knowing about but easy to over-read. A dual API (PHP 8.1+) auto-generates a GraphQL schema from PHP class definitions for products and coupons only — the team describes it explicitly as a proof of concept with no backward-compatibility guarantee, so it is not a stable production feature. And color swatches (a new wc-visual attribute type) let merchants attach HEX colors or images to attribute terms, but only on block themes and only behind a feature flag — classic-theme stores do not get them. For broader context on where this sits in the agent-protocol landscape, see our map of how MCP fits into the broader agent-protocol landscape.

The heart of 10.9 is a set of seven canonical, schema-defined domain abilities in the woocommerce/ namespace. Each declares whether it reads or writes, whether it is idempotent, and whether it is destructive — so a client knows the blast radius before it runs anything. One detail worth flagging up front: the consumer-facing WooCommerce blog refers to nine built-in abilities, counting list and retrieve operations separately. The developer documentation defines seven canonical abilities, and that is the count we use throughout. The table below is the full reference.

Read these properties as an agent-permission model, not a feature list. The two query abilities are the ones you can hand to an agent with low risk — they only read. The destructive ability is product-delete, and even that is defanged by the soft-delete default. The remaining write abilities edit state but never erase it. This is the difference between a raw REST credential, which grants blanket read-and-write, and an abilities layer, where each operation carries its own declared semantics.

Enabling the integration is deliberately small. There are two moving parts — a feature flag and an authenticated endpoint — and then any MCP-compatible client can connect.

1. Enable the feature flag

The MCP integration is gated behind a feature flag. Turn it on programmatically via the woocommerce_features filter, or from the command line with WP-CLI:

wp option update woocommerce_feature_mcp_integration_enabled yes

2. Generate REST credentials and point a client at the store

The REST API MCP endpoint is /wp-json/woocommerce/mcp, authenticated via an X-MCP-API-Key header in consumer_key:consumer_secret format, with HTTPS enforced by default. (The newer WordPress Abilities API adapter endpoint is /wp-json/mcp/mcp-adapter-default-server.) Generate WooCommerce REST API keys in the store admin, then register the server with your client. The official Claude Code command:

claude mcp add woocommerce_mcp \
  --env WP_API_URL=https://yourstore.com/wp-json/woocommerce/mcp \
  --env CUSTOM_HEADERS='{"X-MCP-API-Key": "KEY:SECRET"}' \
  -- npx -y @automattic/mcp-wordpress-remote@latest

The same remote bridge works with Cursor, VS Code, and any MCP-compatible client. Minimum requirements per the docs: WooCommerce 10.7+ (10.3+ at the floor), WordPress 6.9+, and Node.js 22+. If you want to build store-specific operations beyond the seven canonical abilities, our walkthrough on how to build your own MCP server for custom store operations is the next stop.

WooCommerce 10.9 ships no AI feature a shopper will ever see. What it ships is governance infrastructure that makes agents safe to operate against a live store — and that is precisely why it matters. The hard problem in agentic commerce is not getting a model to call an API; it is letting a probabilistic system act on real inventory and real orders without catastrophe. The abilities layer answers that with four concrete mechanisms.

The most important of these is the first. Because schema validation happens before execution, the abilities layer catches an AI hallucination — an invented field, a made-up status value — at the permission boundary rather than at the database. The error surfaces as a rejected call, not a corrupted record. That is a categorically safer failure mode than a raw REST endpoint that faithfully writes whatever malformed payload an over-confident model hands it.

The design intent runs deeper than safety, though. Because the ability contract is defined and owned by the code that registers it, the rules travel with the implementation rather than being bolted on by whoever wires up the agent. That is the structural reason an abilities layer is more durable than ad-hoc agent integrations — the contract has a clear owner.

Announced June 1, 2026, the abilities surface extends past core into 20+ official extensions spanning seven domains — gift cards, add-ons, purchase rules, product composition, recommendations, subscriptions, payments, shipping, tracking, marketing, and automation. WooPayments, WooCommerce Subscriptions, Stripe for WooCommerce, PayPal Payments, AutomateWoo, Shipment Tracking, Gift Cards, and more than a dozen others now register abilities of their own.

Every extension ability in this first pass is intentionally read-only by design. An agent can read your subscription status or your payment-account configuration without being able to touch it. Write access is a separate, future decision the merchant makes deliberately — which is a meaningful contrast with a typical REST credential, where read and write are a single grant. Read this as a safety ladder, not a limitation: you can let an agent observe your most sensitive surfaces long before you let it act on them.

The version thresholds matter operationally: an extension that predates its threshold simply will not expose abilities, so an agent-readiness upgrade is really a coordinated bump across core and every extension you want addressable. Audit your extension versions before you promise an agent visibility into, say, subscription churn — the data is only there if the extension is current. To benchmark where your store sits today, our guide to assess your store’s agent-readiness baseline is a useful starting frame.

The instinct is to frame this as WooCommerce catching up to Shopify on agentic commerce. That framing is wrong, and the distinction is worth getting right because it changes which platform is the answer for a given job. Shopify’s Universal Commerce Protocol (UCP), co-developed with Google, operates at the commerce-protocol level — it governs the full buyer journey of discovery, cart, checkout, and post-purchase, and is supported by retailers including Etsy, Target, Walmart, and Wayfair. WooCommerce’s abilities operate at the store-management level — products, orders, and extension data, with agent-facing semantic operations. They solve adjacent but different halves of the problem.

The practical read: if your goal is to let a buyer’s agent discover, add to cart, and check out, Shopify’s UCP is the purpose-built layer for that, and MCP is one of several transports it is supported by. If your goal is to let your own operational agents manage the store — bulk-edit catalog, triage and progress orders, read extension data — WooCommerce’s abilities are the cleaner fit, and they run on the WordPress install you already own. For the full feature-by-feature picture beyond agent-readiness, see our WooCommerce vs Shopify feature comparison, and for the consumer-agent side of Shopify’s push, our writeup of Shopify’s Spring ’26 agentic commerce capabilities.

This is genuinely significant infrastructure, and it is also early. Several pieces carry explicit preview or experimental labels in the official docs, and conflating them with production-stable features is the easiest way to over-promise to a client. Here is the honest ledger.

The right response to a developer-preview release is neither to ignore it nor to wire an agent into production checkout on day one. It is to build the muscle now, on safe surfaces, so you are ready when the preview labels come off. Here is how we’d sequence it by team posture.

Looking forward, the read-only extension pass and the transport-neutral abilities layer both point the same direction: this is the start of a multi-release arc, not a finished product. Expect write abilities to roll across extensions in future passes, expect the preview labels to come off core MCP before the experimental dual API does, and expect the canonical-abilities pattern to spread to other WordPress plugins now that the WordPress Abilities API gives them a shared foundation. The teams that pilot now will be the ones running unattended store automation when that maturity lands. If you want help designing that rollout safely, our eCommerce engagements and AI transformation work start with exactly this kind of staged agent-readiness plan; for automating the marketing side, see how teams are automating marketing workflows via MCP skills.