MCP for online stores: letting AI assistants use your shop as a tool

Short answer: the Model Context Protocol (MCP) is an open standard, introduced by Anthropic in 2024 and now supported across AI assistants and developer tools, that lets an assistant call outside tools and data. For an online store, an MCP server turns the shop into a set of tools an assistant can use directly: search the catalogue, read a product, build a checkout, check an order. Running one well means deciding what assistants may do, authenticating them, keeping answers small and accurate, and staying in step with the commerce protocols that define their own MCP tools.

This is the third of our guides to the agent commerce protocols, after Google’s UCP and ACP.

What MCP is, in shopping terms

Without MCP, an assistant has to read your web pages and guess. With MCP, it can ask your store directly: “search for waterproof jackets in medium under £100”, “is this one in stock?”, “start a checkout with these items”. The store answers with exact, structured data, and the assistant tells the shopper.

An MCP server publishes tools (each with a name, a description and a schema for its inputs and outputs) over a transport the assistant connects to, typically Streamable HTTP for a server on the web.

What a store’s MCP server has to handle

1. Which tools, and who may use them

Reading the catalogue is low-risk; creating checkouts and reading orders isn’t. A store needs to decide which tools are open to any assistant, which need a key, and which are off, then enforce that on every call, with rate limits and a log of who did what.

2. Authentication that assistants can actually use

Developer tools can usually send an API key. Some consumer assistants’ connector screens only support OAuth, so serving them means running OAuth 2.1 (with dynamic client registration) in front of your own keys. Both need revoking, rotating and limiting per agent.

3. Answers that fit in an assistant’s context

Full commerce schemas run to tens of kilobytes per tool, far too much for a model to read on every call. Tool definitions have to be compact enough for an assistant to use well, while the server still checks every request against the full schema.

4. Sessions over the web

Streamable HTTP sessions have to work across restarts and more than one server, with session IDs that can’t be forged. Errors have to come back in a form the assistant understands: business outcomes (out of stock, address needed) in the tool result, transport faults as protocol errors.

5. The commerce protocols’ own MCP tools

Both UCP and ACP define MCP bindings: thirteen catalogue, cart, checkout and order tools for UCP, five checkout tools for ACP, each with its own metadata (for example the agent’s platform profile on every UCP call) and idempotency rules. A store that wants to work with every assistant ends up serving its own general-purpose tools and both protocol bindings, all backed by the same catalogue and checkout.

6. Discovery

Assistants need to find the server. UCP and ACP profiles can advertise their MCP endpoints, and a store can point to it from its pages and its llms.txt, but there’s no single registry every assistant reads.

What you can do today

1. Fix the product data first. An MCP server answers from your catalogue, so names, prices, stock, variants, GTINs and images need to be complete. It’s also what AI assistants read on your pages today: see structured product data for AI agents.
2. Run the free check. Its protocol readiness section looks for a discoverable MCP server, a UCP profile and an ACP checkout.
3. Let Proxa Monitor watch your endpoints once they’re live.
4. Proxa Connect (coming soon). Connect will run an MCP server for your store, alongside UCP and ACP, starting with WooCommerce: catalogue search, products, checkout and orders, with per-agent keys, limits and logs. It isn’t available yet: tell us you’re interested and we’ll let you know when it launches.