WebMCP, and what Shopify quietly turned on

The last piece in this library ended with a caveat: at some point you stop tuning input fields and give an agent a described interface instead. That point has arrived for a large share of merchants, who did not ask for it and mostly have not noticed. It is worth understanding precisely, because the mechanism is genuinely new, and almost every write-up of it so far has merged two different things that work in two different ways.

Reviewed September 29, 2026 · 11 min read

Everything written here about forms an agent can fill assumes the agent has to work out your interface: read the labels, infer the purposes, guess which address block is which. That is the hard way, and it is the only way available when the page offers nothing better.

WebMCP is the page offering something better. Instead of leaving an agent to interpret your controls, the page hands it a list of named operations with descriptions and typed parameters, and the agent calls them. The difference is the difference between watching someone use a machine and being given its manual.

Your page can hand the agent a toolbox#

The mechanism is a JavaScript API. A page registers tools against a model context object on the document, and an agent operating in that browser can list and call them.

A tool declaration is a small dictionary. Name and description are required, and so is execute, the callback that actually does the work and returns a promise. Title, an inputSchema expressed as JSON Schema, and an annotations object are optional.

document.modelContext.registerTool({
  name: 'check_availability',
  description: 'Check whether a size is in stock for a product',
  inputSchema: {
    type: 'object',
    properties: {
      sku: { type: 'string' },
      size: { type: 'string' },
    },
    required: ['sku', 'size'],
  },
  execute: async ({ sku, size }) => {
    const res = await fetch(`/api/stock?sku=${sku}&size=${size}`)
    return res.json()
  },
})

Read the shape of that declaration again and notice what it resembles. A name, a description in natural language, a typed schema for the inputs. It is the same contract a merchant MCP server exposes, with one difference that turns out to matter a great deal: this one lives in the page, inside the shopper’s own browser session, rather than on a server the agent connects to separately.

If you are on Shopify, this already happened#

Shopify turned WebMCP tools on across its storefronts, and the phrasing in its own changelog is the part merchants should read twice: there is nothing to install or configure, and the tools are live on every Liquid storefront and on the Hydrogen developer preview. No opt-in, no flag. If you run a Liquid theme, an agent in a supporting browser can already call these:

One current limit is worth knowing before you draw conclusions from your own testing: agent support for WebMCP is documented as limited to Chromium-based browsers. An agent driving a different engine will not see these tools, and your experience of whether any of this works depends on which agent you happened to try.

The part almost every write-up got wrong#

Coverage of this has widely reported that Shopify now lets agents read, edit and submit checkout, naming a set of tools that includes complete_checkout. That merges two separate things, and the distinction is the most important thing in this article.

The Checkout MCP server does document a complete_checkout tool described as submitting payment and placing the order. But the same documentation is direct about who that is for, noting that for general access, directing buyers to the checkout URL is how checkout completes and you do not call complete_checkout. Order placement is gated by access level, not handed out with the browser tools.

What changes for you, and what emphatically does not#

If you are on a covered platform, the interface-interpretation problem largely disappears for the paths those tools cover. An agent does not have to guess what your Add to cart button does when there is an update_cart tool with a described schema. That is a real reduction in failure modes and it arrived for free.

What does not change is everything upstream of it. search_catalog returns the products you published, with the prices and availability you published. get_product returns your variant and stock data. search_shop_policies_and_faqs answers from your policies. A tool is a reliable way to reach your data; it is not a way to improve your data.

So the whole argument for accurate product feeds, honest availability and stated policies survives intact, and arguably gets sharper. Previously a wrong price might be missed because the agent could not parse your page at all. Now it is handed over cleanly, through a documented interface, with your name on it.

It is a draft, and drafts move#

The honest framing matters here, because the gap between how settled this feels and how settled it is remains wide. The specification is a Draft Community Group Report from the Web Machine Learning Community Group, and it carries the standard disclaimer: it was published by that community group, it is not a W3C Standard, and it is not on the W3C Standards Track.

That is a familiar pattern by now. Signed agent requests shipped in production ahead of their own draft too. Deployment leading standardisation is not a reason to ignore something that is live on your storefront, but it is a reason to read tool names and method signatures from the specification and the platform documentation rather than from an article, including this one, six months from now.

What to do about it this week#

1. Find out whether your platform registers tools on your behalf. On a Liquid storefront the answer is yes and you did not have to do anything. On a custom stack the answer is no unless somebody built it.
2. Test in a Chromium-based browser, since that is where agent support currently is, and note that a negative result elsewhere tells you about the browser rather than about your store.
3. Audit the data behind the tools rather than the tools. Ask what search_catalog would return for your three best sellers, and whether the availability is accurate right now. That is the part you own.
4. Do not assume order placement is open. Check what your platform actually permits at your access level before either worrying about it or building on it.
5. If you are on a custom stack and considering implementing this, read the specification directly. Name, description, inputSchema and execute are the whole contract, and the API hangs off document rather than navigator.
6. Keep the rest of the work. Tools change how an agent reaches your facts. They do nothing about whether your facts are right, and they make wrong facts travel faster.

The strategic read is simple enough. For two years the argument for agent readiness had to be made speculatively, because the agents could not do much when they arrived. A platform quietly enabling cart manipulation on every one of its storefronts, with nothing to install, is that argument arriving as a default. The businesses that will benefit are the ones whose underlying data was worth reaching.