What Is WebMCP, and Should Your Website Support It?

What Is WebMCP, and Should Your Website Support It?

As of September 2026, WebMCP is a proposed browser API that lets a website declare its features as structured tools an AI agent can call, instead of the agent guessing where to click. It is real, it is in a Chrome origin trial, and for most marketing sites it is still too early to build on.

The short version of why it exists: agents are already visiting websites, and they are doing it badly. They screenshot a page, guess which element is the submit button, and hope. WebMCP is the proposal that says the site should just tell them.

We have been reading the spec work rather than the commentary around it, so here is what the primary sources actually say.

What Problem Is WebMCP Trying to Solve?

The gap between what an agent can see and what a site actually does. A screenshot shows pixels. It does not show that a field wants a first name separately from a surname, that a date must be in the future, or that submitting this form starts a paid trial.

The proposal is direct about the alternative it wants to displace. It argues the design encourages developer involvement in the agentic web, and reduces the need for solutions like UI automation where the developer is not involved, which it frames as better for privacy, cheaper for the site, and a better customer experience.

That last point is the commercial argument, and it is the one worth paying attention to. UI automation means agents hammering your pages, burning your bandwidth, and misreading your forms. A declared tool is one structured call.

How Does the API Actually Work?

A site registers tools with the browser, and the browser hands them to whatever agent the user is running. The published proposal describes an interface at window.navigator.modelContext with three main methods: provideContext, which registers a list of tools and clears anything registered before it, registerTool, which adds a single tool without clearing the rest, and unregisterTool, which removes one by name.

Each tool carries a natural language description and a structured schema, so the agent knows what the tool does and what arguments it needs. The function that runs when a tool is called also receives an agent object, which exposes requestUserInteraction so the site can pause and ask the human to confirm.

The proposal covers two flavours of this. Simple actions that can be declared straight on HTML forms, and more dynamic ones that need JavaScript. If you have built an MCP server before, the mental model transfers almost completely. The site is the server, the tools are the tools, and the browser is the transport.

Who Is Behind It, and How Settled Is the Spec?

It is a joint Microsoft and Google effort, developed in the open. The specification lists Brandon Walderman, Leo Lee and Andrew Nolan from Microsoft and David Bokan, Khushal Sagar and Hannah Van Opstal from Google as authors, with the specification since evolving under Dominic Farolino.

The work lives in the W3C Web Machine Learning Community Group's repository. That is worth reading precisely: a community group is where proposals are incubated, and a community group report is not a W3C standard. Plenty of proposals never leave that stage.

How settled is it? When we looked this week, the repository carried 122 open issues and 10 open pull requests. More telling, the README and the proposal document do not even agree on where the interface lives, with one describing document.modelContext.registerTool and the other window.navigator.modelContext. That is not a criticism. It is what active design looks like. But it is the reason we are not shipping this to client production sites yet.

Can You Try It Today?

Yes, behind a trial. Chrome announced on 9 June 2026 that you can sign up for a WebMCP origin trial in Chrome 149. Origin trials are time-limited programmes that give early access to experimental platform features, sometimes with usage limits, and the post explicitly asks developers for feedback on the shape of the API.

Read that framing honestly. Chrome is not telling you to ship this. It is telling you the design is still open and it wants implementers to argue with it. An origin trial is an invitation to experiment, and experiments end.

So the answer to "can we try it" is yes, on a prototype, with a browser flag, on something that is not load-bearing.

Why Would You Want Agents Doing Things on Your Site?

Because they are going to do it either way, and declared tools are the version where you keep control. An agent filling your demo request form through UI automation gives you a badly mapped lead and no signal that a machine was involved. The same agent calling a declared tool gives you clean structured data and a clear marker.

There is also a quality argument that matters more for complex products. The things buyers use your site for, checking whether a plan covers their seat count, working out whether an integration exists, starting a trial, are exactly the things that break when guessed from a screenshot.

We think about this the same way we think about designing tools for AI agents generally. A good tool has a narrow job, an honest description, and a schema that makes invalid calls impossible.

What Are the Security Questions?

The big one is trust, and the proposal's answer is to put the browser in the middle. It says tool calls are mediated through the browser, so the user has an opportunity to review the requesting client apps and give consent, with the browser arbitrating access and applying platform security policies.

That handles the user's side. It does not by itself handle yours. A declared tool is a documented, machine-readable path into your application, which is useful to a legitimate agent and equally useful to anyone probing for one. Every tool you expose is surface area, and the descriptions you write to help agents also tell attackers exactly what the endpoint expects.

The other open question is prompt injection reaching the tool layer. If an agent's instructions can be poisoned by content it reads, a tool that performs a real action is a more interesting target than a button. We wrote about the general shape of that risk in our piece on stopping prompt injection in AI automations, and none of it gets easier when the browser is the one holding the tool list.

Should a B2B Marketing Site Do Anything About This Yet?

Not much, and that is a real answer rather than a dodge. If your site is brochure, blog and a contact form, there is nothing meaningful for an agent to call that plain HTML does not already offer. Making the form semantic and the labels honest gets you most of the benefit today.

The teams who should be paying attention now are the ones whose site does work rather than describes it. Booking, configuring, quoting, checking availability, searching a large catalogue. Those are tool-shaped, and those are where an agent's guesswork costs you conversions right now.

For everyone else, the useful posture is to watch rather than build. Agents already browse your site, and getting that experience right is a present-tense problem covered in how AI agents browse websites.

What Would We Build First?

One tool, on one high-intent path, on a prototype. Probably the one that converts. A tool that takes the handful of fields a demo request genuinely needs, validates them properly, and returns a clear result the agent can report back to the person who asked.

The reason to start there is not traffic. It is that it forces the two questions you have to answer anyway. What does this action really require, and what should happen when an agent, rather than a person, gets it wrong? A tool with a vague description and a loose schema fails in ways a form never did.

Then we would instrument it heavily, because the first thing you will want to know is how often agents call it, what they pass, and how often a human has to be pulled in to confirm.

What Are We Watching Next?

Three things. Whether the interface name settles, because that tells you the design has stopped moving. Whether a second browser engine commits, because a Chrome-only API is an integration and not a web platform. And whether the origin trial turns into something shipped by default or quietly lapses, which is the ordinary fate of many proposals at this stage.

Our honest read is that the idea is correct and the timing is early. Websites telling agents what they can do is obviously better than agents guessing. Whether this particular API is how it happens is not settled yet, and anyone telling you otherwise is reading the press coverage rather than the issue tracker.

If you are trying to work out whether your product is tool-shaped enough for this to matter, or you want a prototype built against the trial, we are happy to talk it through. Find us at phoenix.studio.