WebMCP and Agentic Commerce

By Everett Zufelt, Program Lead, Agent Ecosystem, MACH Alliance

What’s real, what’s missing, and what to build regardless.

I’ve had the same conversation about a dozen times this year. Someone mentions WebMCP, the browser API that lets a website expose its search, cart, and checkout as tools an AI agent can call directly, and asks whether agentic commerce has finally arrived. The honest answer is worth more than yes or no.

WebMCP is real. Chrome shipped it as a public origin trial in 2026, and it solves something concrete: instead of an agent scraping a rendered page to guess what a button does, the page just declares its available actions. Where it falls apart is the leap people build on top of that one fact, treating a single-browser trial as proof the web agents problem is solved.

So I run claims like this through a short test. Is anyone using it? Are its safety guarantees enforced, or just advisory? Is what it lets an agent do reversible if something goes wrong?

None of that is an argument to dismiss WebMCP. It means understanding what it solves, what it doesn’t yet, and what protects you either way: a composable, API-first foundation, built regardless of which protocol wins.

What WebMCP is

Before WebMCP an agent trying to act on a website had one option: pretend to be a person. Read the rendered page, guess which element says “add to cart,” click it, and hope the click did what it looked like it would. That approach is slow, breaks the moment a site redesigns its layout, and gives the agent no way to know what’s safe to try versus what might charge a card or cancel an order.

WebMCP’s answer is to let the site declare its actions explicitly: exactly which tools exist, what inputs each one takes, and whether it just reads data or changes something. An agent reads that declaration instead of the rendered page, and calls the tool by name instead of guessing at a click.

Mechanically, a site calls navigator.modelContext.registerTool(), or declares tools through markup, to expose actions like searching a catalog, adding an item to a cart, or starting checkout. Each tool carries a name, a description, and a schema for its inputs. Google and Microsoft are co-developing the spec through the W3C, and Chrome shipped the first implementation as an early preview in version 146, in February 2026, moving into a public origin trial in version 149 in May. A storefront running it today can expose search, cart, and checkout as callable tools with no guessing at rendered HTML required, inside a single-browser origin trial that nothing is deployed against at production scale yet.

The three-question test

I call them adoption, enforceability, and reversibility, and I picked these three on purpose. Whether something is technically a standard doesn’t tell you much by itself; the web is full of specs nobody uses and specs that quietly became the default. What matters is whether anyone outside a demo has adopted it, whether its safety claims are guaranteed by the system or only suggested to it, and whether a bad call can be undone before it costs anything.

Score weak on one and the answer is “not yet.” Score weak on all three, which is closer to where WebMCP sits today, and the headline claim and the real risk assessment stop being the same document.

Adoption is also the leg most likely to move fast, and not always visibly. MCP itself went from an announcement almost nobody outside Anthropic had heard of in November 2024 to something most of the industry had adopted within about a year. A weak score today describes today, and today moves fast, which is why this is worth re-running every few months rather than filing WebMCP under “not real” and moving on.

Running WebMCP through the test

On adoption, the honest answer is mixed, and worth being precise about. A live directory tracking WebMCP deployments lists close to 200 verified sites shipping tools today, including recognizable commerce brands, plus at least one browser extension built specifically to talk to them. That’s a real signal. Look closer, though, and a large share of the commerce listings register the identical ten tools, search_catalog, get_cart, proceed_to_checkout, and so on, across unrelated brands, which points to one vendor’s toolkit installed on many storefronts rather than two hundred companies independently deciding this matters. The browser side hasn’t moved nearly as fast: one browser, as a trial, with no committed timeline from Firefox or Safari, and Microsoft’s Edge hasn’t enabled it despite co-authoring the spec. Polyfills backfill navigator.modelContext into any browser, which solves the “my browser doesn’t support this” problem. It solves nothing about whether an agent reaches for it. I wrote this piece with Claude, working in Cowork, and asked it directly whether it calls WebMCP tools by default when browsing on someone’s behalf. It doesn’t call them as a standard step, though a small number of purpose-built extensions and shopping agents already do.

On enforceability, WebMCP does include safety annotations: a tool can be marked read-only to skip confirmation, or destructive to require it. The Model Context Protocol’s own writing on these annotations calls them a risk vocabulary, not an enforced guarantee, and means exactly that. A site can mislabel a tool. A runtime can ignore the hint. Nothing in the protocol stops either one, which makes the annotation a suggestion dressed up as a safeguard.

On reversibility, getting a catalog search wrong is harmless. Charging a card or canceling an order isn’t, and nobody has published a shared vocabulary for which commerce actions belong in which category. Not WebMCP. Not the commerce protocols being built alongside it. A destructiveHint only means something if everyone agrees on what’s destructive, and right now every site is left to decide that on its own. An agent operating across multiple merchants is reading a different, unaudited judgment call from each one about what counts as dangerous.

What WebMCP solves, and todays opportunities

Credit where it’s due: WebMCP fixes a real, specific problem. Scraping a page to infer intent is brittle and slow, and a declared list of callable actions is a legitimate improvement over that, one that can cover any action a site’s code can perform, not just a narrow set. The real constraints are the ones already covered above: who’s using it, whether its safety signals are enforced, and whether there’s a shared sense of what’s safe to automate.

What it doesn’t fix is everything downstream of discovery: a shared vocabulary for what these actions mean, an enforcement layer that doesn’t depend on every site behaving well, and an audit trail an enterprise could stand behind. Those aren’t Chrome’s problems to solve alone, and no commerce protocol I’ve reviewed has solved them yet either.

What I tell people depends on where they’re starting.

If you haven’t modernized your frontend yet, close that gap first. A browser standard can only expose actions your systems already perform cleanly through an API, so WebMCP won’t rescue a monolithic frontend with logic split across templates and ad hoc endpoints; it will just expose the mess faster. Composable, API-first foundations are what make “declare this as a callable tool” a thin wrapper instead of a rewrite. That work matters with or without WebMCP, and it’s the prerequisite many organizations are missing.

If your frontend is already modernized, there’s no reason to wait on the sidelines. Use a WebMCP shim and start with a narrow set of low-risk tools: catalog search, product lookup, order status, nothing that moves money yet. Instrument it properly and track when, and whether, agents interact with those tools in the wild. That data tells you something a spec document never will: whether real agent traffic is showing up, and what it’s trying to do when it does. Right now, almost nobody has that data. Being one of the first to have it is worth more than being an early adopter for its own sake.

Either way, keep an eye on the commerce protocols developing alongside WebMCP, ACP and UCP among them. They’re solving an adjacent problem, standardizing checkout and payment flows between platforms and businesses, not just what an agent can see in a browser tab, and neither has closed the vocabulary or enforcement gap either.

Whichever combination of these protocols ends up winning in the long-term will decide how agentic commerce gets adopted at scale. That’s the foundation MACH members have been building toward regardless of AI. Agentic commerce just raised the stakes on already having it.