Last week I built a small online store that has no real interest in being looked at.
No hero image worth the name, six products, a cart, a checkout. When the page loads, it hands a list of tools to any AI agent in the browser: search the catalog, get product details, add to cart, view the cart, check out. Each tool has a name, a plain-English description, and a schema for what goes in and what comes back. The agent reads that list and calls the functions directly. It never has to look at the page at all.
That is WebMCP, and I wanted to understand it by building on it rather than reading about it.
For about twenty years the web has assumed a human on the other end. Eyes, a cursor, a screen. When an AI agent shows up to buy something, it has to pretend to be that human... take a screenshot, read the DOM, guess which button is "add to cart," hope the layout did not change since yesterday. When it does, the whole thing breaks, in ways that are miserable to debug. I have spent a lot of the last year on exactly that problem, first on the research side looking at whether checkout agents could even finish a purchase, then on the infrastructure side building rails that let an agent check out on a site the merchant never touched.
WebMCP comes at it from the other direction. Instead of the agent working to understand the site, the site tells the agent what it can do.
What WebMCP actually is
WebMCP is a proposed web standard from the W3C Web Machine Learning Community Group, authored by engineers at Microsoft and Google and first floated in February. The idea is small and clean. A web page registers "tools," which are just JavaScript functions with a natural-language description and a JSON schema, and an in-browser agent can discover and call them. The page becomes its own server. Nothing runs on a backend that the merchant has to stand up.
In code it is about as plain as it sounds:
document.modelContext.registerTool({
name: "add_to_cart",
description: "Add a product to the cart by id or name. Returns the updated cart.",
inputSchema: {
type: "object",
properties: { product: { type: "string" }, quantity: { type: "integer" } },
required: ["product"],
},
execute: async ({ product, quantity }) => {
// ...the same function the Add button already calls
return { content: [{ type: "text", text: JSON.stringify(cart) }] };
},
});The agent gets a clean contract. It sends { product: "nw-003" }, it gets structured JSON back, and the page updates. No screenshot, no guessing.
WebMCP is an origin trial in Chrome 149. The only thing that consumes these tools in the wild right now is Gemini in Chrome, behind a flag. There is no cross-browser support. The declarative half of the spec, where you would annotate an HTML form and get a tool for free, is still literally marked "TODO." The API was already renamed once, from navigator.modelContext to document.modelContext. This is an early preview, not a shipped standard, and I want to be careful not to describe it as more than that.
What building it made obvious
The first is reliability. When the agent calls search_products with a schema instead of parsing a page, a whole category of failure just disappears. No cookie banner sitting on top of the button. No layout change that quietly breaks the selector. Early third-party benchmarks have thrown out numbers like eight to twelve times faster than a vision-based agent on the same page. I would take the exact figure with a grain of salt, but the direction is obviously right. A named function with typed inputs beats a screenshot and a guess every time.
The second is control. I decided what the five tools were. I decided that checkout should only fire after the user confirms, and I wrote that into the description so the agent treats it as a gate. I marked the read-only tools as read-only. The site defines exactly what the agent is allowed to do and how, which is a much better place to be than hoping the agent interprets your page the way you intended.
The third is how little code it took, given that the logic already existed. My tools are thin wrappers around the same functions the buttons already call. For any site that already has search, cart, and checkout working, exposing them as tools is not a heavy lift (take this with a truckload worth of salt).
A better door for agents, less brittle, more predictable, cheap to add if you already have the pieces. That is why I want to be careful about what we call it.
It isn't the same kind of thing as UCP or ACP
When people file WebMCP next to Google's UCP or Stripe and OpenAI's ACP, they are putting it in the wrong drawer.
UCP and ACP are commerce protocols. They define commerce itself in a shared language: what a product is, how a cart works, how checkout proceeds, how payment is handed off and who is on the hook for it. They exist so that an agent and a merchant can agree on the meaning of "place this order" without a custom integration between every pair.
WebMCP defines none of that. It is a generic mechanism for a page to expose any function to a browser agent. A todo app registers a tool to add a todo. A flight tracker registers a tool to look up a delay. My store registers a tool to add to cart. WebMCP does not know or care that commerce is happening... it is a browser-interface layer, not a commerce layer. You could implement UCP-style checkout operations as WebMCP tools and hand them to an agent that way. It sits underneath the commerce question, not inside it.
So "is WebMCP a legitimate agentic commerce protocol" is close to a category error. As an interface for agents, it is legitimate and it is good. As a commerce protocol, it is not really trying to be one, and grading it as if it were is how the conversation gets confused. The useful question is narrower. For commerce specifically, does exposing your store as WebMCP tools get adopted and used? And there the story looks familiar.
The same wall every protocol hits
Someone has to write those tools and maintain them, on every site, forever.
My six-product demo has a hand-written list of five tools. A real store has hundreds of flows, an inventory system, promotions, variants, account state, all of it changing constantly, and every one of those tools is engineering the merchant has to build and keep in sync with a site that never stops moving. This is exactly the thing I keep coming back to about the agentic commerce merchants I have talked to. They do not want to dedicate engineering capacity to a new set of rails. They want to run their store. WebMCP, for all its elegance, asks them to take on more of that work, not less.
It also only helps the cooperative part of the web. If a site has not implemented WebMCP, an agent gets nothing from it and falls right back to scraping and vision. So the protocol raises the ceiling for the sites that opt in, and does nothing for the millions that never will. Any approach that depends on the merchant cooperating shares that limit by design: it helps the sites that show up, and the long tail still needs a path that works on the site as it already is, with no cooperation required at all.
And then there is adoption, which is where I have seen the same pattern before. UCP, ACP, MCP... every one of them is a genuinely reasonable idea that lives or dies on whether enough of the market adopts it, and merchant adoption has historically been the bottleneck for all of them. WebMCP is earlier than any of those. One browser, one agent, a flag, an origin trial. That is a hard place to start a two-sided market. Sites will not invest in tools until agents reliably use them, and agents will not rely on WebMCP until enough sites expose tools. Someone has to go first, before there is an agent on the other side to make it worth it.
A couple of smaller things are worth naming too. The agent trusts the page's own description of its tools, which is a new surface to think about... the spec includes an untrustedContentHint for a reason. And building real engineering hours on a spec that still has TODO sections and has already renamed its core API is a bet on a moving target.
None of this makes WebMCP a bad idea. It just makes it a protocol.
Where it actually fits
I think WebMCP is a real improvement to how a site can talk to an agent, and for high-value sites with the engineering to maintain a good set of tools, it will be worth doing. If you are the kind of site an agent visits constantly and you want to be maximally legible when it does, hand-writing a clean, well-described tool surface is a genuine advantage. I would build one.
What it does not do is settle agentic commerce, because it was never the layer that would. The commerce protocols are still sorting out how agents and merchants agree to transact, and the infrastructure worth building works on top of whichever ones win, not just one. The long tail still needs a way to be bought from without lifting a finger. WebMCP sits below all of that as a better interface for the sites that choose to build it, and next to a universal, no-integration layer for the enormous remainder that never will. But betting the whole channel on every merchant adopting a new standard counts on a web that has never fully arrived, with any protocol before this one. The web that adopts the standard gets better. The web that doesn't still has to work.
If you build agents, the practical read is simple. Use WebMCP tools when they exist, because they are faster and more reliable than anything you can scrape. Assume they usually will not exist, because today they almost never do, and have a fallback that does not depend on the merchant having done anything.
And to be straight about what I actually did here: I wrote the tools, registered them, and watched an agent-style caller run the full path from search to a placed order, with every call and its structured response visible on the page. The real-agent side, a live model discovering and invoking these tools through Chrome, is still early and browser-limited, and I would rather tell you that than pretend the ecosystem is further along than it is.
WebMCP is a genuinely better interface for agents. It is not a commerce protocol, and whether it matters for commerce comes down to adoption that is not here yet.
Frequently Asked Questions
What is WebMCP?
WebMCP is a proposed web standard that lets a web page register "tools," JavaScript functions with a natural-language description and a JSON schema, that an in-browser AI agent can discover and call directly. Instead of the agent scraping the page or guessing at the DOM, the site declares what it can do. It is currently an origin trial in Chrome 149, consumed only by Gemini in Chrome, and is best treated as an early preview rather than a shipped standard.
Is WebMCP a commerce protocol like UCP or ACP?
No. UCP and ACP are commerce protocols that define commerce primitives, catalog, cart, checkout, and payment handoff, so an agent and a merchant can agree on how to transact. WebMCP is a general-purpose mechanism for a page to expose any function to a browser agent, and commerce is just one use case. It sits at a different layer. You could even expose commerce operations through WebMCP tools.
Does WebMCP replace web scraping or the no-integration approach to agentic checkout?
No. WebMCP only helps on sites that have implemented it. If a site has not registered tools, an agent falls back to scraping and vision, and the long tail of merchants that will never build tools still needs an approach that works on the site as it already is. WebMCP raises the ceiling for cooperative sites; it does not remove the need for a universal layer.
Is WebMCP production-ready?
Not yet. It is a Chrome origin trial with a single consuming agent, no cross-browser support, and parts of the spec still unfinished. The API is stable enough to build against for experiments, and worth doing if you already have the application logic, but I would not bet a production roadmap on it at this stage.