WebMCP in 2026: the browser API that lets agents use your SaaS UI
WebMCP lets a web page register tools that browser AI agents call directly. Chrome 149 runs it as an origin trial. What it changes for SaaS interfaces.
In this piece
WebMCP is a browser API that lets a web page register its own tools, each one described in JSON Schema, so an AI agent working inside the browser can call them directly instead of reading the screen and guessing which button does what.
It exists as a Draft Community Group Report at the W3C Web Machine Learning Community Group, edited by engineers from Google and Microsoft, and it runs as an origin trial in Chrome from version 149. It is not a W3C standard and it is not on the standards track. The teams who should be reading the draft now are the ones shipping checkout flows, dashboards, search, and booking screens, because those are the tasks an agent will try to complete on a user's behalf.
The 30-second version
A browser agent today drives your product the way a person would, only worse. It reads the accessibility tree or a screenshot, infers intent from labels, clicks, waits, reads again. Every loop costs tokens. Every loop can break on a modal, a lazy-loaded list, or three buttons that all say Continue on the same page.
WebMCP inverts the flow. The page declares what it can do. The agent calls the declared function. The handler runs in the page's own JavaScript context, under the session the user is already signed into. No second API, no separate auth, no server work.
Why letting an agent guess at the DOM is expensive
The cost is measurable. A 2025 arXiv paper published under the same webMCP name, a client-side prototype separate from the Google and Microsoft draft, ran 1,890 real API calls across shopping, authentication, and content management flows. Embedding structured interaction metadata in the page cut processing overhead by 67.6% and held a 97.9% task success rate, with per-interaction cost dropping between 34% and 63% (Perera, arXiv:2508.09171).
Those numbers come from a prototype, not from Chrome's implementation, so read them as a direction and not as a promise. The direction is not controversial. A typed function call is cheaper than a screenshot plus a chain of inferences.
How the API works
The interface exposes three methods and one event: registerTool, getTools, executeTool, and an ontoolchange handler. A tool is a name, a description, an input schema, and an async function.
await document.modelContext.registerTool({
name: "add-todo",
description: "Add an item to the user's active todo list",
inputSchema: {
type: "object",
properties: { text: { type: "string", description: "The todo item text" } },
required: ["text"]
},
async execute({ text }) {
await addTodoItemToCollection(text);
return { content: [{ type: "text", text: "Added todo: " + text }] };
}
});Chrome documents two paths. The imperative one is the code above: tools defined in JavaScript for navigation, form input, and state changes. The declarative one lets you annotate a standard HTML form so the browser exposes it as a tool with no extra script. Chrome DevTools ships an experimental panel that lists the tools registered on a page, invokes them by hand, and validates the JSON Schema (Chrome for Developers).
Where the spec stands in September 2026
- Status. Draft Community Group Report at the W3C Web Machine Learning Community Group. Not a standard, not on the standards track.
- Chrome. Origin trial from version 149, announced in May 2026.
- The API moved. The getter went from
navigator.modelContexttodocument.modelContext. Chrome 150 deprecated the navigator name and kept it as an alias, so old code still runs and the change is easy to miss. - A method was cut.
provideContext()came out of the draft in March 2026. Any guide still showing it is out of date. - Edge. Microsoft co-edits the spec. WebMCP does not appear as shipped in Microsoft's public Edge platform release notes, so treat third-party claims of native Edge support as unconfirmed.
- Firefox and Safari. Both engaged in the community group. Neither has committed to a timeline.
That is a moving target. Anything built against it in 2026 is an experiment with a maintenance bill attached.
What WebMCP changes for SaaS interface design
The interesting work here is design work, not only engineering.
Your tool list is your information architecture, said out loud
Registering tools forces you to name what the product does in verbs a stranger can read. If a team cannot list eight tools for its own dashboard without arguing, the product's jobs were never clear. Writing MCP servers produces the same effect: the naming pass is a product exercise wearing an API costume.
Tool descriptions are interface copy
The model reads the description to decide whether to call the tool. That is the job a button label does for a person, with a different reader. "Update settings" is as useless to an agent as it is to a user. "Change the notification email for this workspace" is not.
Reads and writes deserve different treatment
Chrome's guidance includes a readOnlyHint for tools that change nothing and an untrustedContentHint for tools returning data from outside the page. Sorting a table and cancelling a subscription should not be registered with the same posture.
Confirmation moves to the boundary
An agent calling a tool that deletes records, sends messages, or moves money needs a person in the loop. That confirmation is a screen, and somebody has to design it. The interface does not disappear when the agent arrives. It concentrates at the points where being wrong is expensive.
The screen still has to work
Every tool a page registers has a human counterpart on the same page. Two contracts to keep in sync, two paths to test. That is a real cost, and it is the honest argument for waiting. The related question of how a screen reads to a non-human user is covered in our piece on building a UI the non-human user can read.
When to wait instead
Four situations where the answer today is no.
- Your traffic is human. If no measurable share of your sessions comes from an agent, you are paying maintenance for a hypothesis.
- Your critical flows are irreversible. Payments, deletions, and outbound messages carry the highest injection risk and the lowest tolerance for a wrong call.
- You have no way to observe tool calls. Without logging on which tool ran, with what arguments, and what came back, you cannot debug or audit anything.
- Your team already has an MCP server carrying the same capabilities. Duplicating the contract before the browser API settles buys drift, not reach.
What Chrome warns about
Chrome publishes a dedicated agent security page, and the warnings are specific (Agent security considerations for WebMCP). A malicious page can hide instructions inside tool names, descriptions, and outputs, which is indirect prompt injection with a new delivery route. Over-parameterised tools can be talked into leaking user data. Tools can misrepresent what they actually do.
The mitigations are unglamorous: strict character limits on names and descriptions, hints that mark read-only tools and untrusted content, explicit human confirmation before anything irreversible, and logging on every call. A studio that has hardened an MCP server will recognise the shape of the work. We wrote up the server-side version in hardening an MCP server for enterprise.
WebMCP and MCP are not the same thing
The names collide and the architectures do not. An MCP server lives on your infrastructure, speaks a transport, carries its own authentication, and serves any client that connects. WebMCP lives in the page, runs in the browser, and rides the session the user already has. One exposes your product to any agent anywhere. The other exposes the page a user is currently looking at to the agent looking over their shoulder.
Most SaaS teams will end up with both, for different jobs. If the server side is the open question, start with what MCP is and why a SaaS needs a server, then the managed versus self-hosted decision. The specification itself is short enough to read in an afternoon (WebMCP draft), which is the cheapest research any product team can do this quarter.
Sources
Frequently asked questions
Does WebMCP replace the MCP server I already run?+
No. They cover different ground. An MCP server exposes your product to any agent that can reach your infrastructure, with its own authentication and its own audit trail. WebMCP exposes the page a signed-in user is currently looking at to the agent running in their browser, using the session that already exists. A support agent pulling ticket data at 3am needs the server. A user asking their browser to file the ticket for them needs the page tools. Most teams will end up maintaining both.
Will adding WebMCP tools help my SEO or my AI search visibility?+
There is no evidence for that, and the mechanism does not support it. WebMCP tools are registered at runtime by JavaScript in a page a user has already opened. Search crawlers and the retrieval pipelines behind AI answers do not sign in, do not hold a session, and do not execute your tool handlers. Structured data, server-rendered content, and citations are still what move citation rate. Treat WebMCP as a task-completion feature for logged-in users, not as a ranking lever.
How much work is it to add WebMCP to an existing SaaS?+
The first tool is an afternoon. The tenth is a project. Registering a tool is a name, a JSON Schema, and a handler that calls a function your app already has, so the initial wiring is genuinely small. The cost arrives afterwards: keeping tool descriptions in sync with the UI when features change, deciding which actions require human confirmation, logging every call, and re-testing when the spec moves under you. Budget for the maintenance, not for the first commit.
What happens in browsers that do not support WebMCP?+
Nothing breaks, and nothing helps. Feature-detect before you register: if the modelContext object is absent, your registration code never runs and the page behaves exactly as it does today. Agents in unsupported browsers fall back to reading the DOM, which is where they are anyway. That is the one comfortable property of this API. It degrades to the status quo rather than to a broken page, which is why an experiment behind a feature flag is a defensible thing to run in 2026.
Related services
Studio
Start a project.
We write about what we build. Tell us what you want to build.