WebMCP is not Chrome's MCP: the website side of agent tools

At WeAreDevelopers World Congress 2026 in Berlin, somewhere between the talks and a long table at the Zollpackhof beer garden, one of us said the word “WebMCP” and the three of us — a frontend engineer, a backend engineer, and me — spent the next half hour confidently disagreeing about what it was. The frontend read it one way, the backend another, and my first instinct was that it was just a new name for the thing we already used to drive a browser from an agent. We were all a little wrong. The honest end of that conversation was “we need to actually read the spec.” A few days later it shipped as a feature in our gateway. This post is the explanation we wished we’d had at the table.

Chapter 1 — Why smart people mix these up

The names are close, the protocol word is identical, and both involve an agent and a browser. That is enough to send three engineers down three different mental models. Ours went like this. The backend engineer heard “MCP” and pictured a server exposing tools over the network — correct for our gateway, wrong for this. The frontend engineer heard “Web” and pictured a client library you call from page JavaScript — closer, but they assumed it talked out to some server. I heard “browser + agent” and pattern-matched to the thing we already use to let an agent drive Chrome for testing. Three reasonable reads, and the spec matches none of them exactly.

The unlock is to stop thinking about where the code runs and start thinking about which side offers the tools. In Chrome DevTools MCP the browser is the thing being operated — the agent is the one holding the controls. In WebMCP the browser is the host, and the website loaded in it is the one publishing controls for an agent that lives in the browser to pick up. Both are “an agent and a browser.” Only one of them is your website talking.

Chapter 2 — What WebMCP actually is

WebMCP is, in Chrome’s own words, “a proposed web standard” — first announced in February 2026 and developed in the W3C Web Machine Learning Community Group with authors from Google and Microsoft. Concretely it is a browser JavaScript API: a page calls registerTool() to declare an action — a name, a human-readable description, and a JSON Schema for its inputs — and provides an execute function that runs when an agent invokes it. The agent does not screen-scrape the DOM or guess where to click; it reads the declared tools and calls them directly, in the context of the page’s already-logged-in session.

// A page declares one tool. This is the whole surface an agent sees.
// document.modelContext on Chrome 150+; it was navigator.modelContext on 149.
await document.modelContext.registerTool({
  name: "filter_products",
  description: "Filter the product list by category and price ceiling.",
  inputSchema: {
    type: "object",
    properties: {
      category: { type: "string" },
      maxPrice: { type: "number" }
    },
    required: ["category"]
  },
  async execute({ category, maxPrice }) {
    applyFilters(category, maxPrice);        // reuse the code the UI already calls
    return { content: [{ type: "text", text: `Filtered to ${category}.` }] };
  }
});

The important part is what execute does: it calls the same code the on-screen buttons already call. WebMCP is not a second implementation of your app for robots — it is a thin, declared front door onto the behaviour you already ship. That is why it is interesting to a frontend engineer (it is page code, reusing page logic) and to a backend engineer (the action still lands on your existing endpoints, with your existing auth and rules) at the same time. It sits exactly on the seam the three of us were arguing across.

Chapter 3 — What you set in Chrome to try it (July 2026)

This is the part that cost us the most trial and error, so here it is precisely, dated, because it will age. WebMCP is a Chrome origin trial — an opt-in preview you can run on real users — that began in Chrome 149; the current stable as we write is Chrome 150, and everything hands-on below we verified on 150. The consuming agent today is Gemini in Chrome. Treat versions, flag names, and the API object as things that will keep moving.

To experiment locally, enable chrome://flags/#enable-webmcp-testing → Enabled and relaunch Chrome — that one flag exposes the API. The thing that actually trips people up is not a second flag: navigator.modelContext is a secure-context feature, so it exists only on HTTPS pages and comes back undefined on http:. If it is missing, check the scheme before anything else — that cost us more time than it should have. (There is a separate #devtools-webmcp-support flag, but it only adds the DevTools inspector panel; it is not needed for the API itself.) Two more details worth knowing:

• Where the API lives is changing. Chrome’s documentation states plainly: “navigator.modelContext is deprecated in Chrome 150. Use document.modelContext instead.” On 149 it is still navigator.modelContext. If you write against this, feature-detect both — check document.modelContext first, then fall back — so your code survives the rename.
• You can test without an agent. Chrome’s implementation also exposes getTools() and executeTool(), so you can drive your own registered tools straight from the DevTools console and watch them run end to end — no Gemini required.

// Drive your own registered tools from the DevTools console — no agent needed.
const mc = document.modelContext || navigator.modelContext;   // survives the 150 rename
const tools = await mc.getTools();
const tool = tools.find(t => t.name === "filter_products");
const result = await mc.executeTool(tool, JSON.stringify({ category: "books" }));
console.log(result);   // { content: [{ type: "text", text: "Filtered to books." }] }

One wrinkle worth flagging, which we confirmed by hand on Chrome 150: executeTool wants the tool object returned by getTools() (not its name) and its arguments as a JSON string — pass a plain object and it throws Failed to parse input arguments; the JSON.stringify above is what makes it work. That is a detail of the preview testing interface, not part of the spec, and a real agent never sees it; it only matters when you are the one driving the console.

For a production trial — real users, no flags — each site origin needs its own origin-trial token, registered with Chrome and served as a <meta http-equiv="origin-trial"> tag. That is the mechanism that lets you ship a preview API to visitors without asking them to touch chrome://flags.

Chapter 4 — What happened when we shipped it into a gateway

A few days after the beer garden, we added a WebMCP surface to our own dashboard. We are writing about it here not as a launch — it ships off by default and it is deliberately small — but because building it forced the fuzzy conference argument into concrete decisions, and those decisions are the reusable part.

Our dashboard already sits in front of a lot of connected services. The temptation was to expose all of it to an in-browser agent. We didn’t. The design we landed on has three properties we would keep for any WebMCP surface on a privileged app:

• The server decides what exists, not the page. The page fetches a small manifest of allowed tools from the server and registers exactly those. The browser never gets to enumerate capabilities on its own — a stale tab cannot invent a tool.
• Every call re-checks permission at execution time. Each tool invocation runs through a single server endpoint that re-verifies the user’s role right then, so a tab left open across a permission change cannot call something it no longer should. It runs as the logged-in user — never more.
• Every call is audited as its own channel. Because the agent acts as the user, the audit log tags browser-agent calls distinctly, so “the agent did this” and “the person clicked this” stay separable after the fact.

We kept the first version read-only on purpose: list what is connected, report health, search the action catalogue, show recent activity. Read tools let us learn how a browser agent actually behaves against a real app before any write path is on the table. That restraint is the honest state of the art — WebMCP is young, one browser and one agent consume it, and the useful move is to ship a small, well-fenced surface and watch, not to wire an agent into everything the moment the API appears.

This is also why WebMCP sits next to what we already build rather than replacing it. Our gateway serves the network side of the same protocol — tools for agents that connect over the wire, from Claude Desktop to a headless worker — while WebMCP is the browser side, tools for an agent standing inside the user’s own tab. Both raise the identical question — how much of your app are you willing to expose, to an actor carrying the user’s permissions — and the safe answers are the same on both sides: curate the surface, check every call, log who did what. The entry point differs; the governance does not.

Chapter 5 — When WebMCP is the right tool, and when it isn’t

The direction-of-the-arrow test also tells you when to reach for which thing. If you are automating a browser — end-to-end tests, scraping a site you don’t own, driving a legacy web UI that has no API — you want Chrome DevTools MCP or a similar browser-driver, because the agent needs to hold the controls. If you are making your own site agent-friendly for the people already using it in a browser, WebMCP is the fit: you declare the handful of actions that matter and let their in-browser agent call them cleanly instead of hunting through your DOM.

And if the consumer is not a browser at all — a headless worker, an automation, an IDE assistant connecting over the network — then neither applies and you are back to a normal remote MCP server, which is what our gateway is. These are not competitors; they are three answers to three different questions about where the agent is. The mistake we made at the table was assuming there was one question. If the surface you are weighing is the network one — many tools, many clients — the sibling problem there is keeping that surface small and inspectable, which is its own design decision.

What to take from this

Three things survive the read-up. First, WebMCP and Chrome DevTools MCP are opposites, not synonyms: one lets an agent drive a browser, the other lets a website offer tools to an agent inside the browser. Second, it is real but early — a Chrome origin trial from version 149, consumed today only by Gemini in Chrome, enabled locally by enable-webmcp-testing, with the API living on navigator.modelContext in 149 and moving to document.modelContext from 150. Third, if you put it on a privileged app, the safe shape is server-decides-the-tools, re-check-permission-per-call, audit-as-its-own-channel — the agent should be able to do exactly what the signed-in user can do, and not one thing more.

The unglamorous conclusion is the one we reached a few days late: the names collide, the arrow settles it, and the interesting engineering is not in the API surface but in deciding how much of your app you are willing to hand an agent that is standing in your user’s shoes.

Related: the network-side counterpart to this page is MCP explained: how AI agents talk to your company tools — the same protocol vocabulary, from the server direction.