The new WooCommerce MCP abilities in 10.9 cover seven product and order operations, and the same release starts retiring the REST-shaped MCP beta that arrived with 10.3. If anything you maintain calls /wp-json/woocommerce/mcp, read this as a migration notice. If nothing does, you can leave things alone for now, which is how I read the announcement on the WooCommerce developer blog.
I agree with the reasoning. The beta wrapped REST endpoints as abilities, so clients had a second name, schema, and permission boundary to keep in sync, and it added no capability of its own. An agent that wants raw REST can already call the REST API. The canonical set starts from the business operation instead: query products, create, update, or delete one, query orders, update an order status, add a note.
What the new WooCommerce MCP abilities do
Seven shipped: woocommerce/products-query, product-create, product-update, product-delete, orders-query, order-update-status, and order-add-note. Each has strict input and output schemas, WooCommerce-aware enums, and a permission callback that runs through the existing permission model.
The defaults suit automated callers. Product delete moves the product to trash and needs force: true to delete permanently, and if trash is disabled on the site, the ability returns an error instead of quietly hard-deleting. orders-query leaves out line items unless you pass include_line_items: true. order-update-status rejects no-op updates.
They register with the WordPress Abilities API on every request, so you can list them at /wp-json/wp-abilities/v1/abilities once 10.9 is live (the list route needs a user with the read capability). The run route picks its HTTP method from the annotations: GET for readonly, DELETE for destructive idempotent writes, POST for the rest.
Is the old WooCommerce MCP endpoint going away?
Yes, but not immediately. /wp-json/woocommerce/mcp stays alive during the transition for consumers of the beta, the surface Automattic opened with the Claude experiment. It still authenticates with REST API keys through the X-MCP-API-Key header. The post says it will be removed in a future version without naming one, so treat it as a deadline without a date.
One change matters if you assumed namespace matching: abilities are no longer pulled into the deprecated endpoint just because they start with woocommerce/. Inclusion now requires the metadata flag below, and the woocommerce_mcp_include_ability filter is still the runtime override. The MCP feature flag gates only the bundled adapter endpoints; ability registration and the Abilities REST routes work regardless.
What can bite you as an extension author
There are two. First, the woocommerce/ prefix is reserved for core and WooCommerce enforces it: if a third party registers a canonical core name before the WooCommerce loader runs, the conflicting ability gets unregistered, a warning lands in the woocommerce-abilities log source, and the core definition wins. 10.9 is scheduled for June 23, 2026, so if you ship plugins that register abilities, check WooCommerce, Status, Logs for that source after you update.
The second is stricter than it looks. Exposure on the deprecated endpoint needs a boolean flag:
'meta' => array(
'expose_in_deprecated_woocommerce_mcp' => true,
),
// must be boolean true; 1 and 'true' do not opt inRegister your own abilities through woocommerce_ability_definition_classes with a class implementing Automattic\WooCommerce\Abilities\AbilityDefinition, use your own prefix, and set category to ‘woocommerce’ when the operation belongs beside the core ones. If agents should find it through the shared MCP adapter, that’s a separate decision: set mcp.public to true. Leave internal abilities without either flag until you mean to expose them.
Moving clients off the old endpoint and registering new abilities cleanly is the kind of work I do for store and plugin clients. I’m happy to look at what you have before 10.9 lands, while there’s still time to fix prefixes without a deadline breathing down your neck.
On a client site this week I’d search the codebase and any integration configs for woocommerce/mcp, leave raw REST integrations on the REST API where they belong, and run the same post-update checks I run every release, including the new log source. Nothing here forces action today, and I’d like more deprecations to work that way.
