Running an MCP Server for Your Own Store

The question arriving from technical store owners this quarter is whether to stand up an MCP server so assistants can shop the catalogue. It is reasonable now in a way it was not six months ago, because both major ecommerce platforms have shipped something real and the specification has moved. The answer for most stores is still no, for a specific reason rather than as a general caution.

What an MCP server actually exposes

The Model Context Protocol standardises how an application hands context and capability to a model, and its current specification version is 2026-07-28. The architecture is three-part: hosts initiate connections, clients are the connectors inside them, and servers are “services that provide context and capabilities”. Communication runs over JSON-RPC 2.0 with per-request capability negotiation.

A server offers three things. Resources are “context and data, for the user or the AI model to use”. Prompts are templated messages and workflows. Tools are “functions for the AI model to execute”. For a store the tools matter: a named search_products with typed inputs is a different proposition from an agent parsing your category page and hoping the price it read was the sale price.

The specification is blunt about the risk that creates. Tools “represent arbitrary code execution and must be treated with appropriate caution”, and descriptions of tool behaviour “should be considered untrusted, unless obtained from a trusted server”. The protocol is saying, in its own security section, that exposing a tool exposes an execution path.

The three extensions that changed what is buildable

Beyond the base protocol, the MCP specification now defines optional extensions, negotiated during initialisation and always opt-in. Three are named as notable, and one of them matters disproportionately for commerce.

• Tasks — “asynchronous execution of long-running operations, with polling, mid-flight input, and durable handles”. A checkout that waits on a payment processor is exactly this shape, and before it existed the honest options were a blocking call or a bespoke polling hack.
• Skills over MCP — “rich, structured instructions for agent workflows, discovered and consumed through MCP”.
• MCP Apps — “interactive UI elements (charts, forms, video players) rendered inline within conversations”, which is how a product card gets rendered rather than described.

MCP is the substrate, UCP is the commerce layer

The expensive mistake here is implementing the wrong layer. MCP defines how an agent talks to a tool server. It says nothing about what a cart is, how a variant maps to a price, or what an order confirmation contains. Those belong to a commerce protocol on top.

Shopify’s changelog shows the division enforced in practice. On 24 June 2026 it recorded that “Storefront MCP cart tools are being deprecated in favour of UCP Cart MCP” — the transport stayed, the commerce semantics moved. On 5 August 2026 it shipped WebMCP support for Liquid and Hydrogen storefronts, and on 4 September 2026 that storefronts now support UCP 2026-08-25. Anyone with bespoke cart tools built against the earlier arrangement rewrote them inside three months.

Where WooCommerce actually is

WooCommerce published reference code for a commerce agent on 16 September 2026, and the architecture is more instructive than the announcement. It is not an MCP server and not built on the Abilities API. It runs as a self-hosted Python service alongside WordPress, talks to the store over the REST API, and uses a bridge plugin to connect the assistant’s cart to the normal checkout flow.

The stated limitations are the useful part, and WooCommerce does not soften them. The code is “built for experimentation and growth, and are not maintained within official capacity”. There is “no undo”. Retrieval is keyword search, so the agent cannot reason about products the search did not return. And most pointedly: “No authentication. Anyone who can reach the services can use them.”

That last line should be read next to what you already know about what your REST API exposes. A reference implementation with no authentication is a demonstration of a shape, not a deployment target, and treating it as one would put an unauthenticated write path next to a live catalogue.

Whether you should build one yet

For a store on Shopify or WooCommerce, the platform is doing this work and will do it better, because it owns the cart and the checkout and you do not. Your own MCP server duplicates that and inherits the maintenance when the commerce layer underneath moves — as it did twice in three months on Shopify alone.

The case changes if you are a platform rather than a merchant, if your catalogue has structure no feed expresses, or if you have an internal use for tool access that has nothing to do with shoppers. Otherwise the higher-value work is upstream: accurate feeds, correct availability, and product data that holds up when something reads it without a human in the loop. That is the same conclusion reached from a different direction in product-feed SEO, and the behaviour it has to survive is described in agentic browsers and shopping agents.