Right now, when an AI agent tries to buy something on your website, it looks at a screenshot and guesses. It finds a rectangle that probably says “Add to cart,” works out roughly where the middle of it is, and clicks there. If your layout shifted while it was thinking, it clicks something else.
WebMCP is the proposal to stop doing that. It lets your site hand the agent a list of things it can actually do, described in plain language, with the parameters each one needs.
It is a browser API from engineers at Google and Microsoft, drafted through the W3C, and it is further along than most people realize. Shopify’s current developer docs say it provides the tools automatically on every Liquid storefront and its Hydrogen developer preview.
- WebMCP lets a page declare tools that a browser’s AI agent can call, instead of the agent inferring your interface from pixels.
- Two ways to add them. Two HTML attributes on a form you already have, or a JavaScript call for anything more involved.
- Shopify is already shipping it. Shopify says it provides tools automatically on every Liquid storefront and its Hydrogen developer preview. My August 26 checks found the standard ten tools on Allbirds and Brooklinen.
- It came from a workaround. An Amazon engineer built the prototype because MCP’s OAuth requirement did not fit his employer’s browser-based logins.
- It is not an SEO tactic. The Lighthouse audit that looks for it scores it at zero weight. If you want a number that does move, measure whether AI answers name you, which ContextBolt SEO checks from inside your agent.
The problem WebMCP is solving
An AI agent operating a website today has two bad options.
It can call an API, which means someone built and documented that API, and the agent has credentials of its own that are separate from the person it is working for. Or it can drive the interface: screenshot, infer, click, screenshot again. That works surprisingly often and fails in ways nobody notices, because a wrong click still returns a page.
Neither option knows what the user is looking at. A server integration cannot see the half-filled form or the three items already in the cart. Interface automation can see them, but only as pixels it has to interpret.
WebMCP takes a third path. The page itself, which already knows all of this, publishes a list of things it can do. The explainer describes the goal as “visually rich, cooperative interplay between a user, a web page, and an agent with shared context.” In practice that means the human and the agent are looking at the same screen, and the agent is no longer guessing.
How a page hands over a tool
There are two ways, and one of them is not really programming.
The declarative API takes a form you already have and adds two attributes.
<form toolname="searchCatalog"
tooldescription="Search the product catalog by keyword."
action="/search">
<input type="text" name="q">
<button type="submit">Search</button>
</form>That is the whole thing. The browser reads the form, builds a structured description of it, and when an agent calls that tool the browser focuses the form and fills the fields in front of the user.
The imperative API is JavaScript, for anything a form cannot express. You register a tool with a name, a description, a JSON Schema for its inputs, and a function to run:
await document.modelContext.registerTool({
name: "add-todo",
description: "Add a new item to the user's active todo list",
inputSchema: {
type: "object",
properties: { text: { type: "string" } },
required: ["text"]
},
async execute({ text }) {
await addTodoItem(text);
return { content: [{ type: "text", text: "Added." }] };
}
});Note document.modelContext. That is the surface the W3C draft defines, and it is the one to write down. Plenty of published guides still show navigator.modelContext from the earlier proposals, and in Chrome today that works too: we checked on Chrome 151, and document.modelContext === navigator.modelContext returns true. It is one object exposed in two places. Copy the navigator form and it will run, but nothing promises the alias outlives the origin trial. We went through the full API surface checked against the live spec separately, including two things the popular guides get outright wrong.
It is already running on shops you have used
Shopify’s current developer documentation says it provides WebMCP tools on every Liquid storefront, and on storefronts built with its Hydrogen developer preview. There is nothing to install or configure. The agent uses the shopper’s live browser session, so cart changes and navigation happen in the tab the shopper is looking at.
My August 26 spot-check is useful as confirmation, not as a rollout census. I loaded a set of storefronts in Chrome with the WebMCP flag enabled and asked each page what tools it had registered. Allbirds and Brooklinen each returned the same ten tools:
browse_store
search_catalog
get_product
show_variant
get_cart
update_cart
cancel_cart
proceed_to_checkout
manage_orders
search_shop_policies_and_faqsThat is a complete shopping agent surface. Search the catalog, pick a variant, manage a cart, go to checkout, look up the returns policy. An agent that speaks WebMCP can shop those sites without touching a single button.
An earlier version of this post treated a zero-tool result on Chubbies as evidence that Shopify was still rolling WebMCP out. That conclusion is no longer safe. One old spot-check cannot settle whether the storefront was using a different front end, hit an earlier state of the feature, or behaved differently for another reason. Shopify’s current documentation is the source to follow.
One case is worth separating out, because it points at how this ships. Gymshark also returned nothing, but Gymshark is not a themed Shopify storefront: it serves a Next.js frontend and uses Shopify only as the commerce backend. If the tools arrive with the Shopify storefront itself, a headless frontend would not inherit them, which is worth knowing if you run one. That is one data point and a plausible mechanism, not a proven rule.
Caveats on my own numbers, because a small sample deserves them. A handful of reachable sites is not a survey, and I tested from one country on one afternoon, so a staged rollout could look different from where you are.
If you run a Shopify store, Shopify WebMCP explained for store owners separates the automatic ten-tool set from the things it does not change, including search visibility and custom store logic.
Beyond Shopify, Google named Expedia, Booking.com, Credit Karma, TurboTax, Redfin, Etsy, Instacart and Target as testing WebMCP at I/O in May 2026. OpenAI has been running a WebMCP Challenge. And Cloudflare will inject a bridge into any site behind it from a dashboard toggle, which we turned on here and measured: 115 bytes, two tools, and one tool pack that registered nothing.
Where it came from
The origin is more interesting than “Google proposed a standard,” and it explains the design.
Alex Nahas was a backend engineer at Amazon when MCP landed in late 2024. He tried to deploy it internally and hit a wall: Anthropic’s spec expected OAuth 2.1, and Amazon’s thousands of internal services authenticated through federated browser sessions instead. None of them spoke OAuth in the way the spec wanted.
His insight was that the browser had already solved the problem. The user is signed in. The session exists. The cookies are right there. So in January 2025 he built MCP-B, a Chrome extension that let a page expose MCP-style tools using the authentication the browser already had.
Chrome and Edge engineers found it through W3C channels. The three parties co-developed a joint proposal, submitted it to the W3C Web Machine Learning Community Group in August 2025, and the group accepted it that September. The spec was published as a Draft Community Group Report on February 10, 2026, and the public origin trial opened in Chrome 149.
That history is why WebMCP looks the way it does. It was never designed to replace APIs. It was designed to work inside a session that is already authenticated, because that was the actual problem.
What WebMCP is not
Three corrections worth making early, because each one is common.
It is not a new version of MCP. It does not use JSON-RPC, and the working group deliberately declined to couple it to the MCP wire protocol. If you want the distinction properly, WebMCP vs MCP is the whole argument. The short version is that an MCP server works when nobody is watching and a WebMCP tool only works while the tab is open.
It is not an API replacement. It cannot be. The tools cease to exist when the user navigates away, so anything scheduled, bulk, or unattended still needs a real backend.
It is not an SEO tactic. Lighthouse added an Agentic Browsing category that inspects WebMCP, which produced a wave of posts telling you to implement it or fall behind. We ran that audit on four sites and every WebMCP check carries a weight of zero. Registering tools cannot raise that score, and having none cannot lower it. If agents changing search is your reason for being here, this is not the lever.
Is it safe to hand agents a control surface
The honest answer is that the spec gives you controls and does not pretend they are sufficient.
Chrome’s own security guidance says plainly that “it’s impossible to guarantee safety inside of a large language model,” because models remain vulnerable to indirect prompt injection. A tool that returns text from a review, a comment, or a third-party feed can carry instructions the model may follow.
So the design gives you flags to declare what you know. untrustedContentHint marks a tool whose output includes content you did not write. readOnlyHint marks one that changes nothing, so an agent can skip a confirmation it does not need. Tools are same-origin by default, and sharing them wider takes an explicit exposedTo allowlist.
The risk shape is genuinely different from the server-side case, where the question is which server you trust with a token. We covered that in whether MCP is safe. Here the page supplies the tools, so the question becomes which of your own actions you are willing to expose to something that can be talked into misusing them.
The practical rule: expose reads freely, expose writes carefully, and never expose an irreversible action without a human confirmation step.
For the fuller implementation checklist, including untrusted output, cross-origin access, and test cases that force the bad path, see WebMCP security checklist.
Should you add it to your site
Ask one question. Does an agent need to act on the page a person is currently looking at?
For most content sites the answer is no, and there is nothing here for you yet. A blog does not need tool calling. Publishing an article is not an action an agent takes on your behalf.
For anything with a multi-step flow behind a login, the answer is more interesting. Checkouts, booking flows, dashboards with twenty filters, support forms that route to the wrong team when a human picks wrong. Those are exactly the places where an agent guessing at your interface goes wrong expensively, and where your page already knows the answer.
Whichever way you answer, the cheaper work comes first. An agent that cannot read your page has nothing to call a tool about, and our free GEO audit reports both, including whether the page already declares WebMCP tools.
If you decide to try it, start with the declarative API on one form. It is two attributes, it degrades to an ordinary form when the standard is absent, and if the spec moves again you have lost almost nothing. That is a very different bet from wiring up the JavaScript API across a product.
The one-line test: if a wrong click on your site costs the user money or time, WebMCP is worth an experiment. If your worst case is that someone reads the wrong article, it is not.
Where this goes next
The standard is experimental and the API is still moving. The origin trial runs to Chrome 156, Google is openly asking for feedback on the shape, and nothing here is guaranteed to survive in its current form.
What looks more durable is the direction. Two browser vendors are building the same thing, a shopping platform has shipped a standard tool pack to real storefronts, a CDN will inject it for you, and the auditing tool every developer already runs has grown a category for it. That is a lot of independent scaffolding for a six-month-old draft.
The reasonable position is neither of the two loud ones. It will not make your site rank, and it is not vaporware either. It is a well-motivated fix for a real problem, currently shipping, and cheap to experiment with in the one place it obviously helps.