MCP, agent tool calls and product feeds: the merchant’s guide to what to implement first

What changed in August 2026: Shopify shipped the first surface for you

This guide originally opened by telling you to wrap your read endpoints in an OpenAPI schema, because that was the cheapest way to let an agent search your catalogue. On Shopify Liquid, that advice is now partly obsolete, and it is worth being direct about which part.

Shopify announced WebMCP support for Liquid and Hydrogen storefronts on 5 August 2026, effective 21 August. It is live on every Liquid storefront with no app to install and no admin configuration, which means most Shopify merchants shipped an agent API without doing anything and without being told. An AI agent running inside the shopper’s Chromium browser can call the tools the page declares: catalogue search and browsing (search_catalog, browse_store, get_product, show_variant), cart work (get_cart, update_cart, cancel_cart), checkout and order handling (proceed_to_checkout, manage_orders), and policy lookup (search_shop_policies_and_faqs). Hydrogen support arrived as a developer preview rather than a default.

The mechanism is worth understanding because it shapes what you can and cannot verify. WebMCP tools are registered at runtime through a browser JavaScript API (navigator.modelContext under the Chrome 149 origin trial, document.modelContext from Chrome 150). There is no well-known URL and no global registry, so an agent has to be on the page to see the tools, and you cannot check a competitor’s implementation with a curl. Consumption is currently limited to Chromium under an origin trial, with Gemini in Chrome the main consumer today.

The competitive consequence follows immediately. When every Shopify store gets identical verbs on the same day, the verbs stop being a differentiator, in the same way that having a checkout stopped being one. What separates two catalogues in front of the same agent is the evidence attached to the products: complete structured data, attributable reviews with real ratings and dates, and rights-cleared, product-tagged customer photos and video the engine can quote. Idukki’s llms.txt and MCP output exist to supply exactly that layer, on top of whatever agent-callable commerce layer your platform hands you. The two are complements, not alternatives.

If you want to know whether a given storefront is exposing agent tooling today, our free AI Visibility Check now grades that alongside schema, crawl access and llms.txt, with an explicit caveat about what a server-side fetch can and cannot confirm.

The three surfaces that matter in 2026

You will hear "the AI agents are coming for your storefront" a lot this year. Strip the noise out and there are three concrete things you can implement, with three different cost/value profiles. Pick the order based on your engineering bandwidth, not on which one trended last week.

What each surface actually requires from your catalogue

OpenAI tools, the function-calling shape

OpenAI tools are JSON-schema function definitions. You write the schema; OpenAI calls your function when the model needs it. The functions you typically expose for commerce: search_products, get_product_details, check_inventory, get_pricing, optionally add_to_cart if you trust the agent to write. Authentication is OAuth 2.0 with PKCE; the user authorises the assistant once and your token lasts the session.

Latency is the killer. The OpenAI orchestrator times out at the platform level; your tool call has to round-trip in under 200 ms median for the assistant to stay coherent. Cache the read paths aggressively (your existing CDN is fine). For write paths (cart, checkout), be conservative, return the optimistic state quickly and let your backend resolve async.

Anthropic MCP, the server you publish

MCP is a protocol, not a single product. You implement a server that exposes three things: tools (callable functions, similar to OpenAI tools but with richer metadata), resources (read-only references the model can fetch, e.g., a product catalogue index), and prompts (parametrised prompt templates the host app can compose into the user prompt). Claude and any MCP-compatible client discover your server, list its tools, and call them.

The win MCP gives you over OpenAI tools: state. You can expose a search session where the agent narrows down via successive calls; the server holds the search state. That lets Claude do things like "show me what you have in sage linen, size M, under £100, sorted by reviews" without re-listing the full catalogue on every call. It is much closer to how a human shops.

Google agent feed, the enriched product feed

This one is structurally simple but operationally demanding. Take your Merchant Center feed and enrich every product with the schema.org Product markup that Google requires for the Shopping Graph: sku, gtin, price, priceCurrency, availability, image, aggregateRating, review (if you have them), shippingDetails, hasMerchantReturnPolicy. Validate with the Rich Results Test on three representative SKUs.

Where it breaks: inventory freshness. Google suppresses products whose availability field is stale (≥ 15 minutes behind your actual stock). If your inventory pipeline runs nightly, you have to fix that before you turn the agent feed on, or every "buy" intent will be suppressed by Gemini and pushed to a competitor whose feed is fresh.

A 90-day implementation sequence

1. 1Week 1–2 · OpenAI tools, or the evidence layer if you are on Shopify Liquid. On a non-Shopify stack: wrap your existing search, get_product, get_inventory endpoints in OpenAPI schemas, add OAuth, ship to a private test plugin, and test with five real shopper prompts before exposing to anyone. On Shopify Liquid, WebMCP already covers those read paths in-browser, so spend the fortnight on schema completeness and llms.txt instead and pick the OpenAI work back up when you need the out-of-browser surface.
2. 2Week 3–4 · Google agent feed. Audit your Merchant Center feed against schema.org Product spec. Fix the missing fields. Get inventory freshness under 15 min. Run the Rich Results Test on 20 SKUs.
3. 3Week 5–8 · MCP server prototype. Stand up the minimal MCP server: list_products, get_product, search_products tools. No write paths. No state yet. Test locally with Claude Code; iterate on the JSON-LD shape.
4. 4Week 9–10 · MCP server, productionised. Add auth (API key first, OAuth later). Add stateful search (session id token in tool args). Add observability, every tool call should land in your existing API logs alongside human API calls.
5. 5Week 11–12 · Cross-surface observability + the RFP. One dashboard that shows tool-call volume by surface (OpenAI / MCP / Google), conversion attributable to each, and the top failing prompts. Bring the RFP template (below) to your next martech vendor review.

The "MCP-ready vendor" RFP template

Copy this verbatim into your procurement system. Make every shortlisted vendor fill it in before they get to a demo. You will eliminate half the field in the first round.

# MCP / Agent Surface. Vendor RFP

## 1. Agent surface support
- [ ] Do you publish an MCP server today? (Y/N + URL of public manifest)
- [ ] Do you support OpenAI function-calling against your API? (Y/N + link to OpenAPI schema)
- [ ] Do you expose a Google-compatible Product agent feed? (Y/N + sample URL)

## 2. Latency + freshness
- [ ] What is your median tool-call latency, measured from edge?
- [ ] What is your p95 tool-call latency?
- [ ] What is the staleness budget on your "availability" + "price" fields?

## 3. Auth + tenancy
- [ ] How does the agent authenticate against your tools? (OAuth 2.0 / API key / both)
- [ ] How do you handle per-shopper auth scope?
- [ ] Can a single agent access multiple of our stores in one session?

## 4. Observability
- [ ] Do you provide a tool-call audit log per merchant? (Y/N + access mechanism)
- [ ] Do you surface "model called X tool, got Y answer, shopper converted Z"?
- [ ] Can we route tool-call logs to our SIEM in real time?

## 5. Trust + safety
- [ ] How do you prevent prompt-injection through <a href="/glossary/ugc">user-generated content</a>?
- [ ] How do you handle rights-cleared review media exposed to agents?
- [ ] Do you have a redaction pathway for content the brand later un-cleared?

## 6. Pricing model
- [ ] Is pricing per tool-call, per impression, per merchant, or flat?
- [ ] What is the cost cliff at 10x our current traffic?
- [ ] Is the agent-surface line item separable from the rest of the contract?

What we got wrong in our first MCP build

• We shipped tools before resources. Tools are obvious; resources are less so. A static catalogue resource the agent can read on session start gave us a 40% drop in pointless list_products calls. Ship resources second-to-first.
• We made the search tool too clever. The first version had 14 optional parameters. The agent used three. Trim ruthlessly, every parameter is one more thing for the model to get wrong.
• We forgot prompts. MCP prompt templates parametrised by industry / persona / season pre-empt 60% of the disambiguation rounds an agent does on its own. Cheap, under-used.
• We treated the tool calls as one-shot. A real shopper agent calls four to six tools before it decides anything. Hold a session id; charge once.

Your action list, this week

1. 1Audit your existing public API for OpenAI tool-call readiness. Anything that takes > 200 ms median is on the critical path.
2. 2Pull your Merchant Center feed. Run three SKUs through the Rich Results Test. Note every red flag.
3. 3Read Anthropic’s MCP spec end-to-end (yes, the whole thing). 90 minutes; saves you a quarter of guessing.
4. 4Pick the order that matches your bandwidth: 6+ engineers → all three in 90 days; 2–3 engineers → OpenAI tools + Google feed this quarter, MCP next quarter.
5. 5Send the RFP template above to every martech vendor in your funnel. Watch the field thin out.