What WooCommerce MCP actually provides
WooCommerce includes native support for the Model Context Protocol through the WordPress Abilities API and WordPress MCP Adapter.
Its current purpose-built abilities cover operations such as querying and managing products, querying orders, updating order status and adding order notes. The documented connection flows preserve WooCommerce’s authentication and permission model.
That is important infrastructure. Instead of inventing a proprietary integration for every AI client, WooCommerce can expose discoverable, schema-defined operations through a common protocol.
It is also explicitly marked as a developer preview. The implementation, APIs and integration patterns may still change. The current contract is documented in the WooCommerce MCP integration guide.
Most importantly, the documented use case begins with a known client connecting to a known store using appropriate credentials. That is not the only way AI systems encounter ecommerce data.
Three routes into the same catalog
“AI commerce” currently describes at least three different access patterns.
1. Merchant-supplied feeds
The merchant generates a catalog snapshot and delivers it to a shopping platform according to that platform’s specification.
The platform does not need to discover the store’s MCP endpoint. It receives product data through its own onboarding and delivery process.
2. Configured MCP clients
A merchant, developer or authorized user explicitly connects an AI client to a WooCommerce MCP server.
The client already knows which server to call and can receive capabilities appropriate to its credentials.
3. Autonomous public agents
An agent starts from a merchant domain or product request without a preconfigured connection. It must find an appropriate public interface, retrieve product information and determine which facts it can trust.
These routes can coexist. They may carry information from the same WooCommerce database, but they have different discovery mechanisms, freshness constraints and security boundaries.
Calling all three “MCP access” obscures the actual engineering problem.
Three trust boundaries
The word “agent” also hides three different actors.
A merchant-side agent may be authorized to edit products, inspect orders or perform administrative work.
A public catalog agent needs anonymous, read-only access to intentionally published product information. It should not inherit merchant credentials or see private customer and order data.
A buyer-authorized agent may later receive permission from the customer to perform account, cart or order operations on that customer’s behalf.
These are not merely different tool lists. They are different trust boundaries.
WooCommerce’s own documentation warns that customer and order operations may expose personally identifiable information and recommends least-privilege access. A public product-discovery surface therefore needs a deliberately limited representation of the catalog, separate from administrative abilities.
The protocol can carry each of these interactions. The server must still decide which one is taking place.
What MCP standardizes — and what it does not
MCP gives clients a standard way to connect to servers, list tools and invoke them using declared input schemas.
It does not automatically define:
- which products are publicly eligible;
- which price is authoritative;
- how an active sale should be represented;
- whether inventory is current enough for the requested task;
- how parent products relate to purchasable variations;
- whether a term represents a brand, category, attribute or marketing label;
- which product URL should be treated as canonical;
- which countries the merchant serves;
- which policies apply after product discovery;
- which catalog fields may be exposed without authentication.
Those decisions belong to the commerce domain.
WooCommerce is already moving in this direction. Its documentation distinguishes purpose-built domain abilities from mechanically projecting every REST operation into MCP. The stated goal is a transport-neutral semantic layer with schemas designed for agent workflows.
That is the right distinction: transport tells an agent how to ask; a catalog contract determines what the answer means.
The deceptively simple shopping request
Consider this request:
An agent needs to establish several facts:
- Which products actually qualify as men’s T-shirts?
- Does the €30 limit apply to the parent product, a particular variation or an active sale price?
- Does “in stock” describe the parent product or each selectable size?
- Are sizes represented as purchasable variations or only mentioned in prose?
- Is the returned URL the canonical storefront page?
- When were price and availability last verified?
A generic product query may provide the raw material for some of these answers. It does not guarantee that the answers are deterministic.
If one public representation says €29, another says €39 and the product description contains an old price, the agent has not encountered a protocol failure. It has encountered conflicting source data.
If “Aubade” is stored as a category while the brand field is empty, the agent may infer the intended brand from text. That inference may even be correct. It is still not equivalent to merchant-declared structured data.
If a description says “available from S to XL” but WooCommerce exposes no purchasable size variations, an agent cannot safely promise that every size can currently be ordered.
No transport protocol can resolve those contradictions on its own.
A ten-minute technical audit
Before building another integration, inspect what WooCommerce already exposes.
WooCommerce’s Store API is public, unauthenticated and intended for customer-facing product, cart and checkout experiences. It is a useful baseline for an agent-facing catalog audit — even though it is not, by itself, a complete agent contract.
Set the store domain:
STORE="https://example-store.com"1. Inspect the public product projection
curl -fsS --get \
"$STORE/wp-json/wc/store/v1/products" \
--data-urlencode "search=t-shirt" \
--data "per_page=10" |
jq 'map({
id,
name,
type,
permalink,
price_minor: .prices.price,
currency: .prices.currency_code,
currency_minor_unit: .prices.currency_minor_unit,
in_stock: .is_in_stock,
purchasable: .is_purchasable,
has_options,
brands,
attributes
})'Do not render price_minor directly. WooCommerce returns prices in the smallest currency unit:
displayed amount = price_minor / 10^currency_minor_unitFor EUR, "price": "2990" with currency_minor_unit: 2 means €29.90 — not €2,990.
Check whether every result has:
- a stable ID;
- an HTTPS product permalink;
- a currency and interpretable price;
- explicit stock and purchasability;
- a real brand assignment;
- structured attributes when options exist.
A title containing “Nike” is not equivalent to a populated brand field.
2. Inspect every purchasable variation
The Store Products API excludes variations from the default collection. A parent product marked is_in_stock: true only proves that the product is generally available. It does not prove that every advertised size is available.
Retrieve the actual variations:
PRODUCT_ID=123
curl -fsS --get \
"$STORE/wp-json/wc/store/v1/products" \
--data "type=variation" \
--data "parent=$PRODUCT_ID" \
--data "per_page=100" |
jq 'map({
id,
option: .variation,
permalink,
price_minor: .prices.price,
currency: .prices.currency_code,
in_stock: .is_in_stock,
purchasable: .is_purchasable
})'The sizes an agent may safely report are the variations for which both conditions hold:
is_in_stock == true
is_purchasable == trueDo not derive available sizes from the parent description or from the complete attribute list. Those fields may include options that cannot currently be purchased.
Also verify pagination. A hardcoded per_page=100 is sufficient for many products, but it is not a universal completeness guarantee. Production code must fetch every result page.
3. Count products without a real brand
On current WooCommerce installations, check whether the product_brand taxonomy is available and actually populated. Older stores often keep brands in categories, tags or titles.
With WP-CLI:
wp eval '
if ( ! taxonomy_exists( "product_brand" ) ) {
fwrite( STDERR, "product_brand taxonomy is not registered.
" );
exit( 1 );
}
$query = new WP_Query([
"post_type" => "product",
"post_status" => "publish",
"posts_per_page" => 1,
"fields" => "ids",
"tax_query" => [[
"taxonomy" => "product_brand",
"operator" => "NOT EXISTS",
]],
]);
printf(
"%d published products have no product_brand term.
",
$query->found_posts
);
'List the populated brand terms:
wp term list product_brand \
--fields=term_id,name,slug,count \
--orderby=count \
--order=descA fallback that assigns the store name to every product may be valid for a genuine own-label merchant. It produces false data for a multi-brand retailer. That decision belongs to the merchant, not to an automatic normalizer.
4. Check list-to-detail coherence
A product returned by search should remain retrievable by ID, with the same identity, currency and current price.
PRODUCT_ID=123
curl -fsS \
"$STORE/wp-json/wc/store/v1/products/$PRODUCT_ID" |
jq '{
id,
name,
permalink,
price_minor: .prices.price,
regular_price_minor: .prices.regular_price,
sale_price_minor: .prices.sale_price,
currency: .prices.currency_code,
on_sale,
in_stock: .is_in_stock,
purchasable: .is_purchasable
}'Compare this with:
- the corresponding collection result;
- the visible product page;
- the page’s JSON-LD
ProductorProductGroup; - any generated feed.
A difference is not automatically a defect: collection results may intentionally be compact, and variable products may expose ranges. But contradictory current prices or incompatible availability states require an explicit authority rule.
5. Define the public contract explicitly
Do not expose the authenticated WooCommerce REST API to public agents. Build a limited read-only projection instead.
An illustrative product-detail contract might look like this:
{
"id": "wc_123",
"name": "Example T-shirt",
"url": "https://example-store.com/product/example-t-shirt/",
"brand": {
"name": "Example Brand",
"source": "product_brand"
},
"price": {
"amount": "29.90",
"currency": "EUR"
},
"availability": "in_stock",
"variants": [
{
"id": "wc_124",
"options": {
"size": "M",
"color": "black"
},
"price": {
"amount": "29.90",
"currency": "EUR"
},
"availability": "in_stock",
"purchasable": true
}
],
"provenance": {
"source": "woocommerce",
"source_product_id": 123,
"retrieved_at": "2026-07-04T14:30:00Z"
}
}This is an example, not a proposed standard. The important properties are:
- public fields are deliberately selected;
- money has an explicit amount and currency;
- availability uses a bounded vocabulary;
- variation-level facts are not inferred from the parent;
- provenance identifies the merchant-controlled source.
Do not confuse retrieved_at with the time inventory last changed. The former states when the system observed the value; the latter may not be available.
6. Turn the audit into a gate
Run these checks automatically after changes to WooCommerce, the theme or catalog integrations.
At minimum, fail the gate when:
a search result cannot be retrieved in detail
a product URL is missing or non-HTTPS
a price lacks currency or cannot be decoded
a variation is reported without its parent
a displayed size has no purchasable variation
two public surfaces claim incompatible current prices
private or administrative fields appear in the public projectionA schema-valid response can still be commercially false. Contract tests must check relationships and consistency, not just JSON syntax.
The catalog contract between WooCommerce and agents
A reliable public commerce surface needs to establish at least four things.
Public eligibility
The merchant must decide which products may appear outside the storefront and retain the ability to exclude or withdraw them.
Publication should be intentional, not an accidental consequence of exposing an internal API.
Stable semantics
Identifiers, prices, availability, brands, categories, attributes and variant relationships need explicit meanings.
Google’s product-variant documentation, for example, requires unique identifiers and defined relationships between a product group and its variants. These requirements exist because visual similarity and shared page content are not enough to establish purchasability.
Appropriate projections
Discovery and verification are different operations.
A search result may need only a compact representation for efficient ranking. Once an agent selects a candidate, it may need full attributes, variants and provenance to verify the recommendation.
Returning every field on every call wastes tokens. Returning only summaries makes verification impossible. The useful projection depends on the call, not merely on the client identity.
Authority and freshness
Feeds and indexes are effective discovery mechanisms, but they are snapshots.
For decisions involving current price, availability or selectable variants, an agent should be able to identify the merchant-controlled source of truth and understand when the information was last refreshed.
This does not mean every channel must query WooCommerce live on every request. It means the channel must state what its answer represents instead of silently presenting cached data as current fact.
This is not a criticism of WooCommerce MCP
WooCommerce MCP is solving a real infrastructure problem: how authenticated AI systems discover and invoke store capabilities without every integration inventing a new protocol.
It should not also be expected to repair inconsistent merchant data, define every public-commerce policy or make arbitrary websites discoverable to every external agent.
WooCommerce’s own experimental work acknowledges the distinction. Its WooCommerce for Claude project asks what should sit above basic product and order operations and introduces a knowledge layer containing store profile, catalog structure, policies and enriched product data.
OpenAI’s merchant terms reach the same problem from the distribution side: merchants may be required to remediate discrepancies, formatting inconsistencies, missing fields and technical integration problems in submitted product content.
Different systems are converging on the same conclusion. Connectivity is necessary. It is not the final layer.
A more useful readiness test
Before describing a WooCommerce store as ready for shopping agents, ask which route is being evaluated.
For a product feed
- Does every emitted field follow the destination specification?
- Are required merchant policies present?
- Are variants and identifiers stable?
- Can the snapshot be regenerated consistently?
For a configured MCP client
- Are authentication and permissions appropriate?
- Are tool schemas clear enough for correct selection?
- Are read and write operations separated?
- Can sensitive order data be kept outside product-discovery workflows?
For autonomous public agents
- Is there an explicit route to a public catalog surface?
- Can products be searched without scraping theme navigation?
- Is the public representation deliberately limited?
- Can selected products be verified against merchant-controlled data?
Across all three routes
- Do prices agree?
- Are brands actually stored as brands?
- Are variants purchasable rather than merely described?
- Can the merchant explain where each fact came from?
If those answers are unclear, adding another chatbot does not solve the underlying problem.
The missing component is not another conversational interface. It is a catalog contract that translates WooCommerce’s flexible internal model into representations appropriate to each channel and trust boundary.
The takeaway
MCP makes WooCommerce callable. A catalog contract makes its products reliably purchasable by agents.