The AI shopping tools every Liquid storefront got in August 2026: the ten tools, what they read, what they can't

Short answer: since August 2026 every Liquid storefront on Shopify declares ten tools that an AI agent running in the shopper’s browser can call. They search and browse the catalog, fetch a product’s variants and prices, manage the cart, hand off to checkout and orders, and answer policy questions. They read what the catalog holds. A spec in a metafield, a filter across tags, or the price of one particular variant is where they stop.

What WebMCP is, in one paragraph

WebMCP is “a proposed web standard to help you build and expose structured tools for AI agents” (developer.chrome.com, published 18 May 2026, last updated 7 August 2026). A page registers tools with the browser, each with a name, a description and a JSON schema for its inputs. An agent running in that browser reads the list and calls the tool it needs, getting structured data back instead of scraping the page and simulating clicks. Shopify’s own description is the same shape: “your storefront registers tools with the browser, and the agent calls them with structured inputs and gets structured data back” (shopify.dev/docs/api/web-mcp, read 12 September 2026). The standard covers the declaring side. Which agents call the tools is a separate question, and we come back to it.

When it arrived, and where

Shopify’s changelog entry “WebMCP support for Liquid and Hydrogen storefronts” is dated 5 August 2026 and says the tools “are live today on every Liquid storefront and on the Hydrogen developer preview. There’s nothing to install or configure” (shopify.dev/changelog/webmcp-liquid-hydrogen, read 12 September 2026). If your store runs a Liquid theme, you have these tools now, and you did nothing to get them.

One design point from the docs matters for what follows: the catalog tools “read product, collection, and search data through the Storefront API”, so they see what the Storefront API sees. Everything happens in the tab the shopper is looking at.

The ten tools

Names and descriptions below are from Shopify’s documentation (read 12 September 2026), lightly shortened.

Tool	Group	What it reads or does
search_catalog	Catalog	Searches products, collections, articles and pages. Returns matching products with prices and availability, plus a link to the full search results page.
browse_store	Catalog	Lists the store’s collections, or the products in one collection. Can take the shopper to the collection page.
get_product	Catalog	Full details for one product: variants, prices, and which option combinations are in stock. Can take the shopper to the product page.
show_variant	Catalog	Opens a product page with a specific variant selected; accepts an exact variant or a partial option such as a colour.
get_cart	Cart	Reads the cart: line items with product and variant details, quantities and totals.
update_cart	Cart	Adds items, changes quantities or removes items. If a request is ambiguous it returns options to clarify without changing the cart.
cancel_cart	Cart	Empties the cart.
proceed_to_checkout	Checkout and orders	Takes the shopper to checkout with the current cart, after checking it is not empty.
manage_orders	Checkout and orders	Takes the shopper to their order history; asks them to log in first if needed.
search_shop_policies_and_faqs	Store information	Answers questions about the store’s policies and services, such as returns, shipping and opening hours, from the store’s own content.

Four of the ten read data, five act on the session, one answers from policy content. An agent’s knowledge of your products comes almost entirely from the first three: search_catalog, browse_store and get_product.

Who can call them today

Shopify’s changelog is direct about this: “WebMCP is still an emerging standard, and agent support is currently limited to Chromium-based browsers through an origin trial.” The docs page says the same without the last clause: “agent support for WebMCP is currently limited to Chromium-based browsers.”

An origin trial is Chrome’s way of letting a site turn on an experimental API for its own visitors before the browser ships it to everyone. The API is not on by default in any Chrome channel; it works on Shopify storefronts because Shopify serves a trial token. We decoded that token on 5 September 2026 and re-checked it on 12 September: it expires on 17 November 2026. By then either Chrome ships the API by default, Google extends the trial and Shopify renews its token, or the tools stop appearing until one of those happens. We will update this line the day the date changes.

The other half deserves the same precision. Chrome ships the page-side API; it does not yet ship a built-in agent that calls page tools, and Google’s documentation names no such consumer. Today the callers are extensions, site-loaded agents, automation frameworks and the ChatGPT desktop app’s browsing mode, which we have driven against these tools by hand. That is a small share of shopper sessions. None of this is a defect in Shopify’s implementation; it is the state of the browsers.

What is not documented

Two things merchants ask us about have no published answer, as of 12 September 2026.

There is no documented way to turn the tools off on a Liquid theme. Neither the changelog nor the docs page describes an opt-out, a theme setting or an admin toggle. Chrome’s side has a tools Permissions Policy, but it “defaults to self, which allows tool registration in top-level and same-origin contexts” (developer.chrome.com, 7 August 2026), so it does not stop a script the storefront itself loads. If you want the tools gone, the honest answer is that nobody has written down how.

Nothing is published about apps registering additional tools. The WebMCP specification permits any script with document access to register a tool, subject to that same policy. Shopify has not said whether apps may do so on a storefront, or under what rules. StoreKnows does register tools this way, through a theme app embed the merchant enables, and will follow Shopify’s guidance when it arrives. On 32 live third-party storefronts we read on 5 September 2026, the tool set was the same ten on every one, and none of the 30 third-party apps we detected had added a tool.

What the tools return, in practice

The descriptions above are what the tools are for. What matters for a shopper question is what comes back. Three observations from our own checks:

get_product returns a price range and one variant unless the agent names an option. The docs say it returns “variants, prices, and which option combinations are in stock”, and it does: the response carries the product’s price range and the details of one variant, and the agent has to ask again with a specific option to get another. On a 1,055-product phone-accessories store we checked on 2 September 2026 (12 questions; Anthropic’s Claude Opus 5, OpenAI’s GPT-5.6 and GPT-5.5 via their APIs; a separate judge model), six of the nine partial answers were exactly this: the agent answered “$69.99–$79.99”, or the $69.99 minimum, when the variant the shopper chose costs $74.99. Our fix article on AI assistants calling in-stock products sold out covers the availability version of the same trap.

search_catalog returns ten summary cards. Title, price, availability, a link. It is a good search. It is not a filter: “in-stock black-and-white 35 mm film under $10” is an intersection the agent has to rebuild by opening products one at a time, and it runs out of tool calls. In the same 2 September check, the three remaining partials were attribute-filter recall across near-identical products, where the deciding property lived in tags or options that the search result does not carry.

Metafields are not in any of it. On 41 of 41 storefronts we crawled on 5 September 2026, product metafields were invisible from outside: not in the WebMCP tools, not in /products.json, not in the UCP catalog endpoint. If your thread pitch, your helmet size chart or your “fits models X, Y, Z” note is a metafield the theme renders on the page, an agent calling get_product does not see it. A 15-inch versus 15.4-inch fitment comparison in that accessories check stayed partial in every model for this reason.

Which shopper questions this covers, and which it doesn’t

Put the tool list and the return shapes together and the map is fairly clear.

Answered well by the native tools:

• Do you sell a 4-person tent? Is it available in green? Search, then get_product, then a variant lookup. In our batch of 340 questions across 34 specialist storefronts on 4 September 2026 (OpenAI’s GPT-5.4 mini via the API, native tools only), fit questions of this kind were fully right 55 times out of 68.
• What is your returns window? Do you ship to Ireland? search_shop_policies_and_faqs reads the store’s own policy pages and FAQs, which is precisely what those pages are for. Keep them complete and current and the tool has what it needs.
• Add the medium to my cart and take me to checkout. The cart and checkout tools were built for this, and they trigger your theme’s own behaviour.

Not answered by the native tools alone:

• What is the max load of this rack? A spec in a metafield, or in an image, or in a size chart. Not returned.
• How much is the 256 GB one? A variant’s price, when the agent did not name the option. It gets the range or the minimum.
• Show me the in-stock MagSafe cases under $30 with a kickstand. A filter across tags and options. Search returns ten cards; the agent cannot intersect what it cannot see.
• What is actually different between these two? Comparisons were fully right 16 times out of 68 in the same batch, because the fact that separates two near-identical products is usually one of the three above.

The pattern in our data is not “the tools fail”. It is that the agent almost always finds the product and then lacks one fact about it. On a small text-rich coffee store, checked the same week with the same setup, native tools alone answered 10 of 10 (Claude Opus 5) and 9 of 10 (GPT-5.6). The tools read what the catalog holds; specialist catalogs hold their deciding facts where the tools do not reach. The full numbers, method and limits are in What AI shoppers get wrong about specialist products.

How to see the tools on your own store

You can read the list yourself in about a minute. Open your storefront in Chrome (or another Chromium browser: Edge, Brave, Arc), open the developer console, and run:

await document.modelContext.getTools()

You get back an array of ten tool objects, each with its name, description and input schema. This is the check Slobodan “Sani” Manic of No Hacks ran on 6 August 2026, the day after the changelog, on three live Liquid storefronts in a stock Chrome 150 with no flags (nohacks.co, published 6 August 2026). Two of his details are useful here: the older name from the draft spec, navigator.modelContext, now returns a deprecation warning pointing at document.modelContext; and the descriptions the tools ship with are the text an agent uses to decide which tool to call. Read yours. It is your store as an agent will see it.

If document.modelContext is undefined, you are either not in a Chromium browser, or the origin-trial token is not being served to your page, or the trial has ended. That last case is what the 17 November date is about.

What StoreKnows adds beside them

StoreKnows does not replace any of the ten tools and does not put a chat widget on your store. It registers a small set of extra read-only tools beside Shopify’s, through a theme app embed you enable, built from a saved copy of your catalog that you review and approve. They answer the questions the native set does not: the price and stock of a named variant, a spec or chart from a metafield or metaobject, a “fits with” relationship. An agent that can call get_product can call them too, unchanged. On our dev store, with 144 seeded bicycle products whose deciding specs live in metafields, that took Google’s Gemini 3.8 Flash via the API from 7 of 14 fully right to 13 of 14 on one run each, and OpenAI’s GPT-5.4 mini from 4 of 14 to 8 of 14 (5 September 2026; runs vary).

The honest limits are the same as Shopify’s. The added tools run under the same origin trial and the same expiry date. They are read-only. They serve a saved catalog copy, not live inventory, so stock answers are as fresh as the last sync you approved. And a simulated check tells you what the tools return and how a model reads them, not what a consumer assistant will say to a given shopper this afternoon.

What to do this week

1. Run the console line above on one product page and read the ten descriptions.
2. Take the five hardest questions your customers actually send you and check where each answer lives: title, description, option or variant (the tools see it), or metafield, chart, image or tag (they do not).
3. Make sure the first variant of every product is one you would be happy to have quoted as “the” price and stock.
4. Keep your policy pages complete; the policy tool is only as good as they are.
5. Run a simulated check to see the answers agents actually give on your store, with the product data behind each one. StoreKnows does that for free, and lets you try a fix against your own question before publishing anything.

Results in this article come from simulated checks run by StoreKnows on 2, 4 and 5 September 2026 against public storefronts and our own development store. Questions were answered by OpenAI’s GPT-5.4 mini, GPT-5.5 and GPT-5.6, Google’s Gemini 3.8 Flash and Anthropic’s Claude Opus 5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.