The Agent Is Already On Your Site

What Actually Shipped

WebMCP is a draft from the W3C's Web Machine Learning Community Group, edited by engineers at Google and Microsoft. A page calls document.modelContext.registerTool() with a name, a description, and a JSON schema, and an agent acting for the person at the keyboard can call it. Chrome has been running it as an origin trial since Chrome 149. Edge has it behind a flag. Firefox and Safari have not committed.

The adoption is the part worth paying attention to, not the API. In August, Shopify turned WebMCP tools on by default across every Liquid storefront (catalog search, cart, checkout, policies) with no merchant action required. Cloudflare shipped a developer preview that injects a WebMCP bridge into any site behind it from a dashboard toggle. Neither of those is a developer choosing to expose tools. Both are a platform deciding on their behalf.

If you sell software to businesses, the interesting question stopped being “should we expose tools to agents” somewhere around then. It is now whether the tools that get exposed are the ones you meant, running under the rules you wrote.

The Quiet Move

Here is the thing that took us a while to say out loud. When you register a tool with the browser, the obvious implementation is a function in your page that does the work. It reads your app's state. It calls your API with whatever credentials the page already holds. It is, from your backend's point of view, the user.

That is fine while the caller is a person clicking a button, because a person clicked the button. It is a different proposition when the caller is an agent working through a list, and the browser's consent prompt, not your server, is the thing standing between “search the catalog” and “cancel the subscription.”

Nobody decided to move the authorization boundary into the browser. It moves on its own, as a side effect of the easiest way to build the feature. That is the failure mode worth designing against, and it is not solved by being careful.

By Construction, Not By Discipline

Our embedded assistant already had a governed path for tool calls. A session is minted against one authored surface. Its tool list is projected for that surface and filtered for that caller. A call is authorized, its arguments are validated against the tool's schema, it is admitted against the surface's budget, and anything that is not marked read-only raises a confirmation the user has to answer before it runs.

So the WebMCP bridge does not get its own version of any of that. It registers the tools the session already has, and when a browser agent calls one, the call goes through the exact path an in-panel call goes through. Same projection, same authorization, same admission, same confirmation.

That distinction matters more than it sounds. “The bridge enforces the same rules” is a promise that decays: two code paths drift, and the drift is silent until someone finds it. “The bridge has no rules of its own” is a property of the shape of the code. There is nothing to keep in agreement, so there is nothing to fall out of agreement.

The concrete version: a tool your surface does not project is a tool the agent never learns exists, and would be refused if it guessed the name. A tool marked as a write still returns a confirmation instead of executing, and the browser's own consent dialog is not accepted in its place. We do not treat a prompt shown by software we do not control as a decision our server can act on.

Discovery Is Not Authority

We got one thing wrong on the way here, and it is worth writing down because the correction is the more useful idea.

The first version made the WebMCP switch a single setting for the whole deployment, and made it deliberately hard to vary, on the reasoning that it decides which callers can reach your tools, and that kind of decision should not be refinable in three places.

That was a misreading of our own system. The switch does not decide who may call anything; the session decides that, and it decides it the same way whether the switch is on or off. What the switch governs is discovery: whether the tools get registered with the browser at all, and so whether an agent ever learns they are there.

Discovery, unlike authority, is exactly the question one company answers two ways. A marketing site wants an agent to find its tools. The signed-in application behind the same login usually does not, at least not yet. So the setting became a deployment default that any individual surface can override in either direction, widening or narrowing per surface. Authority stayed where it always was.

What It Costs You

A browser agent calling tools spends no model turn, which means the budgets that bound a conversation do not bound it. It gets its own: a per-session cap and a daily cap, both of which an operator can raise, lower, or set to zero from the CLI without waiting for us to ship anything.

Every bridge call is also a request event, tagged with the surface it came from, so agent traffic shows up as its own line rather than disappearing into a quiet-looking day. We shipped that late. The first version of the bridge recorded nothing, which meant a browser agent working a site looked exactly like nobody visiting it. That was a real gap and it is closed.

What We Do Not Know Yet

WebMCP is a draft that is not on the standards track, in an origin trial, in one browser engine. The entry point was renamed mid-trial. It may change again, and it may not ship at all in the form it has today.

So the bridge is off unless you turn it on, and it feature-detects: on a browser without the API, nothing runs and nothing changes. The numbers behind the budgets are proportionate rather than measured. We sized them against what a conversation already costs, not against real agent traffic, because there is not much real agent traffic yet. They are set where an operator can move them, which is the honest arrangement for a guess.

What we are reasonably confident about is the shape. Whatever the API ends up being called, something is going to let an agent in a browser act on the page in front of it, and the businesses that do well out of that will be the ones whose answer to “what is this agent allowed to do” was written down somewhere other than the browser.