Does this expose WooCommerce administration?

No. The public Bridge MCP tools are read-only and limited to intentionally published catalog facts.

Is this the same MCP server included in WooCommerce 10.9?

No. Native WooCommerce abilities are permission-checked management capabilities. Bridge provides a separate shopper-facing catalog boundary.

Do public agents need WooCommerce consumer keys?

No. The public catalog surface does not grant administrative WooCommerce authority.

Can an agent create an order or issue a refund?

No. Checkout, customer identity, orders and post-purchase actions remain outside the public Bridge MCP contract.

Will every AI assistant discover the server?

No. The endpoint is available to compatible clients, but each platform decides what it discovers and supports.

Is MCP enough if the catalog data is incomplete?

No. MCP transports structured calls; it cannot invent reliable brands, identifiers, prices or purchasable variants that the store does not maintain.

KaliCart Bridge · Technical solution

WooCommerce MCP Server for AI Shopping Agents

Expose a public, read-only WooCommerce catalog through MCP so compatible shopping agents can discover products, search economically and verify current offer facts—without receiving administrative credentials.

The direct answer

KaliCart Bridge gives a WooCommerce store a shopper-facing MCP surface on the merchant’s own domain. A compatible client can discover catalog tools, search bounded product summaries and retrieve current detail for a selected item. The public contract remains read-only: it does not expose customers, private orders, product editing or store administration.

Which WooCommerce MCP do you mean?

WooCommerce 10.9 and KaliCart Bridge both use MCP, but they serve different callers and trust boundaries. Treating them as interchangeable creates either an unusable public interface or an unsafe administrative one.

Native WooCommerce abilities	KaliCart Bridge MCP	How they fit together
Seven canonical, schema-defined and permission-checked abilities for products and orders. They are intended for authenticated store operations through the WordPress Abilities API and MCP Adapter.	A deliberately public catalog-reading surface for unknown shopping agents. It exposes only merchant-published product facts and keeps write authority outside the protocol.	A merchant may run both. Authorized assistants use native abilities for store work; public shopping agents use Bridge for discovery and verification. Credentials, policies and logs remain separate.

What a shopping agent can do

1. Discover the store’s catalog tools

The MCP client can identify the available read-only catalog capabilities without guessing WooCommerce REST routes or scraping theme navigation.

2. Search compact product records

Bounded queries narrow the catalog by text and supported filters. Compact results reduce tokens, bandwidth and origin work.

3. Verify one selected product

A detail call checks identity, current price, currency, stock state, canonical URL and purchasable variants against the merchant-controlled store.

4. Continue through merchant checkout

The agent returns the shopper to the canonical product or checkout path. WooCommerce remains responsible for option selection, destination-dependent totals, payment and the final order.

Commerce signals exposed for product decisions

Signal	Why it matters
Stable identity	Product ID, SKU and canonical URL help agents distinguish candidates and avoid accidental duplication.
Classification	Name, categories, brands and structured attributes support search, filtering and comparison.
Offer facts	Current price, currency, availability and purchasability state what WooCommerce presently publishes.
Variant detail	Purchasable variations prevent an agent from promising a size or option that only appears in prose.
Media and description	Richer detail is available for finalists without forcing every broad search to return the full record.
Action boundary	Canonical URLs and purchase state show what is known and where the merchant-controlled flow must take over.

Why search and verification are separate

An agent rarely needs every field for every product. Bridge separates low-cost discovery from detailed verification: broad searches return compact candidates; full facts are requested only for the shortlist. This reduces unnecessary traffic while preserving a route back to live WooCommerce data before a recommendation.

Boundaries designed for a public endpoint

Read-only tools: no product writes, customer records, private orders or administrative actions.
Bounded pagination and request ceilings: a single call cannot demand an unlimited catalog export.
Rate-limit responses and retry guidance: compliant clients can slow down instead of hammering the origin.
Merchant-controlled publication: only intentionally public WooCommerce catalog data belongs on the surface.
No shared administrator secret: public discovery never requires WooCommerce consumer keys or an admin session.

How this relates to WooCommerce 10.9

WooCommerce 10.9 replaced the earlier REST-derived nine-tool architecture with seven canonical domain abilities: product query, create, update and delete; order query, status update and note creation. The former WooCommerce-specific MCP endpoint remains a deprecated transition path. Those abilities are an important authenticated management layer, but they are not automatically a public shopping interface.

Bridge does not replace or criticize that work. It adds the separate public projection a shopping agent needs when it arrives without a preconfigured store-management connection.

Discovery does not guarantee adoption

Publishing a valid MCP server makes the interface available to compatible clients. It cannot force ChatGPT, Google, a marketplace or any other assistant to discover, index, rank or call the store. Platform eligibility and client behavior remain outside the plugin’s control.

What this solution does not promise

No automatic support from every AI platform or MCP client.
No agent identity, consumer authorization, payment authority or post-purchase control.
No public access to WooCommerce customers, orders or administration.
No automatic repair of incomplete brands, identifiers, attributes or variation data.
No replacement for the merchant’s checkout, shipping, tax or payment logic.

Who this solution is for

Independent WooCommerce merchants and implementers who want MCP-compatible product discovery without turning an administrative API into a public endpoint. It is especially useful when the store needs a bounded, self-hosted source that agents can verify after finding a product through a feed, index or conversation.

Common questions

Does this expose WooCommerce administration?: No. The public Bridge MCP tools are read-only and limited to intentionally published catalog facts.
Is this the same MCP server included in WooCommerce 10.9?: No. Native WooCommerce abilities are permission-checked management capabilities. Bridge provides a separate shopper-facing catalog boundary.
Do public agents need WooCommerce consumer keys?: No. The public catalog surface does not grant administrative WooCommerce authority.
Can an agent create an order or issue a refund?: No. Checkout, customer identity, orders and post-purchase actions remain outside the public Bridge MCP contract.
Will every AI assistant discover the server?: No. The endpoint is available to compatible clients, but each platform decides what it discovers and supports.
Is MCP enough if the catalog data is incomplete?: No. MCP transports structured calls; it cannot invent reliable brands, identifiers, prices or purchasable variants that the store does not maintain.