Shopify WebMCP: your storefront now exposes 12 tools to AI agents

Every Shopify storefront running Liquid gained an API on 5 August 2026, and almost nobody noticed. Not a REST endpoint, and not something you install. Your theme now registers a set of tools with the browser itself, and an AI agent sitting in that browser tab can call them: search your catalog, read a product, add to cart, and start a checkout. No app, no configuration, no merchant approval.

The feature is called WebMCP, and Shopify shipped it to Liquid and Hydrogen storefronts at once. If you build themes for a living, this is the most consequential platform change of the month, and it arrived as a two-paragraph changelog entry. This post covers what it actually exposes, what the docs do not say, and where the constraints are.

What WebMCP actually is

Start with the thing it is not. This is not the Storefront MCP server, which is a remote endpoint an agent connects to from anywhere. It is not the Dev MCP that plugs Shopify's docs into your editor either. WebMCP is narrower and stranger: the page itself advertises what it can do, to whatever agent happens to be running in the browser.

The mental model that helps is an accessibility tree. A screen reader does not scrape your markup and guess; it reads a structured description your page publishes about itself. WebMCP does the same thing for actions rather than content. Instead of an agent trying to infer that the button labelled Add to cart adds to the cart, and clicking it, and hoping, the page hands over a tool named update_cart with typed parameters and a defined result.

That distinction matters more than it first appears. Screen-scraping agents break every time you rename a class or restructure a template. Tool-calling agents do not, because the contract is the tool, not the DOM. Shopify has effectively taken the fragile part of agentic shopping and made it the platform's problem instead of yours.

The 12 tools, and what they do

Shopify groups the tools into four areas. The catalog tools read through the Storefront API. The cart tools call standard storefront actions, which are the same functions apps use to change the cart. That detail is the one with teeth, and it is the subject of the companion post linked at the end.

Read that table again with an eye on what is missing. There is no tool that completes a purchase. proceed_to_checkout takes the shopper to checkout; a human still finishes it. There is no tool that writes customer data, applies a discount, or touches an order. Shopify drew the line at the point where money moves, which is a more conservative design than the agentic-commerce discourse would have you expect.

The constraints nobody is leading with

Chromium only, for now

The tools are live on every storefront, but agent support for WebMCP is currently limited to Chromium-based browsers. Registering a tool and having something call it are different problems, and the second one depends on browser vendors shipping the other half of the standard. Treat current traffic as a trickle and the direction of travel as the point.

No documented opt-out

Shopify's WebMCP tools reference documents the 12 tools and says the feature requires no installation or configuration. It does not document a way to register your own tools, change the behaviour of the defaults, or turn the whole thing off. If a merchant asks you to disable it, the honest answer today is that there is no supported switch.

It is a proposal, not a ratified standard

WebMCP is a proposed web standard. Proposals change, and the shape of the tool contract may well move before it settles. That is an argument against building anything load-bearing on top of the exact tool names today, and an argument for making sure your theme behaves correctly through the underlying mechanisms the tools call, which are stable.

How this fits with UCP and Storefront MCP

Shopify now has three overlapping agent surfaces, and the naming does them no favours. They solve different problems and it is worth keeping them straight.

The short version: WebMCP is the one that affects the theme you are working on right now, because it is already switched on and it runs against your markup and your cart. The other two are things you opt into.

What a theme developer should do this week

1. Audit your cart JavaScript. The cart tools go through standard storefront actions. A theme that bypasses those with a hand-rolled fetch can end up with an agent and a UI that disagree about what is in the cart. This is the concrete risk and it deserves its own post, linked below.
2. Check your product data is actually readable. get_product returns variants and stock status from the Storefront API. If your theme fakes availability in JavaScript, or hides variants behind custom markup, the agent sees the real data and the shopper sees yours.
3. Leave the tool names alone in your planning. The standard is a proposal. Build against the mechanisms, not the surface.
4. Tell your merchants it is on. Most of them do not know. Being the developer who explains a platform change before it becomes a support ticket is worth more than any feature you ship this month.

The pattern here should feel familiar if you have been building on Shopify for a while. The platform absorbs a hard problem, ships it on by default, and quietly changes what counts as a correct theme. The developers who get caught out are the ones who treated platform conventions as style preferences. The ones who followed the standard mechanisms wake up already compatible.