Automattic ran a sprint called Radical Speed Month (RSM), and one of the things that came out of it is WooCommerce for Claude. It is not a feature announcement and there is no roadmap commitment behind it. It is an experiment in what an LLM can do when you hand it a structured model of a store instead of a pile of endpoints.
In 14 years of WordPress work I have lost count of the “AI plugins” that amount to a chat box bolted onto a site. They treat the store as a flat table of rows, so they never get past generic answers. This experiment starts somewhere else: what happens if the model knows the shape of the merchant’s business before it does anything? The bridge for that is the Model Context Protocol (MCP).
Why WooCommerce for Claude is different from simple REST
The default assumption is that hooking AI up to Woo means letting it call REST endpoints. In practice that gets you hallucinated numbers and concurrent writes stepping on each other. WooCommerce for Claude puts a few layers in between:
- Analytics skills: the AI reads pre-aggregated analytics lookup tables instead of querying raw
wp_posts, so questions about coupon performance or what is driving sales come back with real numbers. - A knowledge layer: the store profile, catalogue schema and policies are exposed as MCP resources, so the model has context before its first tool call.
- AI-readiness scoring: an engine that scores the store from 0 to 100 on product completeness and schema coverage, then ranks the fixes worth doing.
All of it goes through one endpoint, /wp-json/woocommerce-claude/mcp. The plugin runs no background crons and no separate sync process. It does work only when an MCP request arrives, which keeps it off your server the rest of the time. I covered the protocol itself in an earlier post on WooCommerce AI and secure MCP integrations.
Extending the intelligence layer
If you build extensions, the provider pattern is the part that matters. You register your own provider and feed structured knowledge into the layer the model reads. That is how agentic tooling should be built: follow the existing hook patterns rather than patching core.
<?php
/**
* Registering a custom provider for WooCommerce for Claude.
*/
add_action( 'woocommerce_claude_register_providers', function( $registry ) {
// bbioon_ prefix for custom implementation
if ( class_exists( 'My_Extension_Provider' ) ) {
$registry->register( new My_Extension_Provider() );
}
});
I have watched a site fall over because an AI agent tried to walk 50,000 orders through standard REST. The subtler failure is data with no context, where the model confidently suggests actions the merchant has no way to perform. Declaring the boundaries up front, which is what the knowledge layer does, is what stops both. There is more in my post on why context is the missing piece in most AI workflows.
If this WooCommerce for Claude work is eating your dev hours, I can take it off your plate. I’ve been working with WordPress since the 4.x days.
How to test it today
The repository is public. Clone it, run composer install, and activate it locally; npx @wordpress/env is the quickest way to get a clean instance. There is a seed script that generates 24 months of order data, which is what makes the analytics skills worth testing at all. No reason to point this at a production database just to find out whether it can spot your worst refund leak.
Whether this ends up in core or stays a separate plugin is still open. Either way, MCP is where the standardization is happening, so it is worth knowing how Claude and other models read your store data now rather than after that decision is made.
