MCP for Retailers: What an AI Assistant Sees When It Reads Your Shop

The Model Context Protocol is a standard for letting an AI assistant call external tools and read external data. It is not a commerce protocol — it is a connector — but it is the door through which most assistants will reach a retailer's catalogue, and the design decisions you make on the other side of that door determine whether the assistant can say anything useful about your products.

What follows is about designing the tools themselves. It applies whether you are a retailer exposing your own catalogue, a marketplace, or a service sitting between the two.

A tool is a contract with a reader who cannot ask follow-up questions

The mental model that helps most: you are not designing an API for a developer who will read your documentation. You are designing for a model that gets one description, one schema and one response, and has to decide from those alone what your answer means.

That has an unintuitive consequence. The most important field in your tool definition is often the description string, because it is the only place you can say what a value means rather than what type it is. "price: number" tells a model nothing about whether that price includes delivery, when it was read, or whether the retailer will honour it.

Five design rules that matter

1. Name the freshness in the payload, not the docs

Every price should travel with the time it was obtained. An assistant that receives an undated number will state it in the present tense, because there is nothing in the response telling it not to. Putting the timestamp beside the price — and, better, the age in hours — changes "costs £249" into "was £249 when checked four hours ago", which is both weaker and true.

2. Make refusal a first-class outcome

Your tool needs a way to say "I could not determine this" that is clearly distinct from "no" and from an empty result. Otherwise an assistant will read absence as denial and tell a shopper something false. If you return a verdict, spell out in the schema description that an unresolved case is unchecked rather than refuted, because that is the sentence the model will paraphrase.

3. Never let unknown default to something flattering

Availability is the classic case. If your source did not report stock, the field should be null and the schema should say that null means unchecked and must never be rendered as available. A boolean forces a lie in one direction, and the direction it forces is always the commercially convenient one.

4. State the scope of any superlative

If your tool returns a "cheapest" field, it should also return what was compared: how many offers, how many distinct retailers, and an explicit flag saying the comparison is not exhaustive. Otherwise "cheapest" reads as a claim about the whole market, which no comparison service can support. A field is harder for a model to skip than a sentence in the documentation.

5. Keep ranking independent of what you earn

If you monetise through commission — most commerce tools do — then the ordering logic should have no access to commercial terms. This is worth building as a structural property rather than a policy, because it is the one claim in this category that can actually be verified by inspection.

What to expose

A minimal commerce tool surface that an assistant can genuinely use looks roughly like this.

• Search by text, returning products with identifiers rather than titles alone.
• Lookup by identifier — barcode first, then your own listing id — which is the path that avoids the entire identity problem.
• Offers for a known product, with a price, currency, availability, timestamp and provenance per offer.
• A verification call: given a product and a price someone has asserted, say whether that holds, with an explicit unchecked outcome.

The fourth is the one most commerce tools omit and the one agents increasingly need, because an assistant that has already been told a price by some other source has no way to test it.

What to withhold

Two categories, for different reasons.

Data you are not licensed to redistribute. Retailer APIs and affiliate networks commonly permit price data to be read but not retained, or retained but not republished. Those terms do not evaporate because the recipient is a language model. Check what your agreements allow before you pipe anything into a public tool.

Anything you cannot evidence. Estimated delivery you have not observed, availability nobody checked, prices assembled from more than one moment in time. The temptation with agent surfaces is to fill every field because a complete response looks better. A gap teaches the assistant that the absence means something; a plausible guess teaches it nothing and costs you the credibility of every other field.

How to test it

Connect your server to an assistant and ask it the questions a shopper would ask, then read the answers as a sceptic. Three tests catch most problems.

1. Ask about a product you do not stock. A good tool surface produces a clean "not found"; a bad one produces the nearest thing, which the assistant then recommends.
2. Ask about something whose price you know changed recently. Check whether the answer states its age, and whether the assistant repeats it in the present tense.
3. Assert a wrong price and ask the assistant to check it. See whether the response distinguishes "that is not what we hold" from "we cannot say".

Whatever the assistant says back is your product now. It is worth reading a few of those answers before anyone else does.