WebMCP vs MCP: What Each One Actually Does

Google and Microsoft engineers have spent the last year building a browser standard called WebMCP. It shares half a name with the Model Context Protocol, which Anthropic released in late 2024. The two are now discussed as if one succeeds the other.

They are not. WebMCP does not use MCP’s wire protocol, does not speak JSON-RPC, and was deliberately not coupled to the MCP specification by the working group that adopted it. The shared vocabulary is real. The plumbing is entirely separate.

The distinction that matters is not technical, though, and you do not need to read either spec to grasp it.

An MCP server works when nobody is watching. A WebMCP tool only works while the tab is open.

Everything else falls out of that one line. Here is what each one is, the test I use to pick, and the part of the current WebMCP coverage that is quietly wrong.

What MCP actually is

The Model Context Protocol is a standard for connecting AI agents to external systems. A server runs, either locally over stdio or remotely over HTTP, and advertises a set of tools. When an agent calls one, real code executes and returns real data.

The important properties are all about independence. The server does not care which client is talking to it, so one integration works across Claude, Cursor, VS Code, and anything else that implements the client half. It does not care whether a browser exists. And it keeps running whether or not a human is present, which is what makes scheduled work and background jobs possible.

That last property is the one people skip past. An MCP server is reachable at three in the morning with nobody logged in. It has its own credentials, its own view of your data, and no dependence on any particular session.

The cost of that independence is that you have to build and host it. You replicate the user’s state and authentication on a separate server, and you maintain it. For a fuller version of that trade-off, we wrote a decision guide on building versus installing an MCP server, and the honest answer for most people is install.

Good MCP candidates: live data behind an API. Your database. Anything on a schedule. Bulk operations across thousands of records. Actions with side effects that need to happen whether or not anyone is at a keyboard.

What WebMCP actually is

WebMCP is a proposed web standard, drafted by Google and Microsoft engineers and incubated in the W3C’s Web Machine Learning Community Group. It lets a web page declare tools that a browser-based agent can call directly, instead of that agent screenshotting the page and guessing which button to click.

There are two ways to declare them.

The imperative API is JavaScript. You register a tool with a name, a description, a JSON Schema for its inputs, and a function that runs when it is called.

const controller = new AbortController();

await document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new 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}` }]
    };
  }
}, { signal: controller.signal });

The declarative API is HTML attributes on a form you already have. Two attributes turn an existing form into a tool.

<form toolname="supportRequestTool"
      tooldescription="Submit a request for support."
      action="/submit">
  <label for="firstName">First Name</label>
  <input type="text" name="firstName" id="firstName">
  <button type="submit">Submit</button>
</form>

That is the whole setup for the declarative half. The browser reads the form, builds a JSON tool description from it, and when an agent calls it, the browser focuses the form and fills the fields. The user sees it happen.

That last detail is the design intent, not an accident. WebMCP is built for a human and an agent looking at the same page, which is why it ships with CSS pseudo-classes like :tool-form-active so you can style a form while an agent is driving it.

Good WebMCP candidates: a multi-step checkout the user is halfway through. A filter panel with twenty controls. A form where the agent should fill the fields but the human should press submit. Anything where the answer depends on the session, the cart, or the state already loaded in that tab.

The lifecycle difference, and why it decides everything

Chrome’s documentation puts it plainly: “WebMCP tools are ephemeral. They exist only when your page is open. Once the user navigates away from your site or closes the tab, the agent cannot access your site or take actions.”

Read that twice if you are considering WebMCP as an API replacement, because it rules the idea out completely. There is no version of WebMCP where an agent books your flight overnight, syncs your records hourly, or does anything at all without a live tab pointed at you.

What you get in exchange is everything a server integration loses. The tool runs inside the user’s session, so it already has their login, their cart, their unsaved form state, and their permissions. You do not replicate any of it, because you are not on a separate machine. The explainer calls the alternative “UI Disintermediation and Context Loss,” which is a heavy phrase for a simple failure: the server-side integration does not know what the user is looking at.

Half the guides you will read are already wrong

This is the part worth the price of admission, and it is checkable in about thirty seconds.

The WebMCP spec moved, and a lot of published tutorials did not move with it. I compared the guides currently ranking against the live W3C draft on August 26, 2026. Three errors are everywhere.

Write document.modelContext. The draft defines the interface on Document: partial interface Document { readonly attribute ModelContext modelContext; }. Early proposals used navigator and a great many guides still do.

In Chrome today, both work, and we checked rather than assumed. On Chrome 151 with experimental web platform features enabled, document.modelContext === navigator.modelContext returns true. modelContext is present on both Document.prototype and Navigator.prototype, and both report a ModelContext constructor. It is one object exposed in two places.

So a navigator.modelContext example will not silently fail on you. It is still the wrong one to write down: it is not the surface the spec defines, and nothing promises Chrome keeps the alias when the origin trial ends.

There is no .well-known/webmcp manifest. Several guides describe one as a third implementation surface alongside the two APIs. No such file appears anywhere in the specification. It does not exist.

provideContext() is not a method. The IDL exposes exactly three: registerTool, getTools, and executeTool, plus an ontoolchange event handler. Chrome’s docs mention requestUserInteraction() as ongoing research, and it is not in the draft either.

Version numbers have drifted too. Guides published in the spring cite Chrome 146, which was the flag-gated developer trial. The public origin trial started in Chrome 149 and runs through 156.

None of this is anyone’s fault exactly. The spec is six months old and marked experimental. But it does mean the sensible move right now is to read the draft and Chrome’s own docs first, and treat everything else as commentary. That is a rare situation in web development and it will not last long.

The security model is not the same either

MCP’s security story is about which server you trust with a token. We covered how to vet one in a piece on whether MCP is safe, and the short version is that the risk lives in the server you install.

WebMCP’s story is different, because the page is the thing supplying the tools. Chrome’s guidance is blunt about the limits: “it’s impossible to guarantee safety inside of a large language model,” because models remain vulnerable to indirect prompt injection.

So the spec gives you flags to declare what you know about your own content. untrustedContentHint marks a tool that returns user-generated or external data, so the agent treats the output with more suspicion. readOnlyHint marks a tool that changes nothing, so the agent can skip a confirmation it does not need. Tools are same-origin by default, and exposedTo is an explicit allowlist if you want to share them wider.

Chrome’s advice on that allowlist is worth quoting directly: “Only expose your tools to origins that you trust.” A read-only tool leaks user preferences. A write-enabled one takes actions on their behalf.

There are hard budgets too, which nobody mentions and which will bite you: 30 characters for a tool name, 500 for a tool description, 150 for a parameter description, and 1.5K for a single tool’s output.

So which one do you build

The test is one question. Does the agent need to act on the page a person is currently looking at?

If yes, that is WebMCP, and nothing else does the job. A server integration cannot see the half-filled form or the current cart, and browser automation has to infer both from pixels.

If no, it is MCP, and WebMCP cannot help you because there is no tab to run in.

Most real products answer yes to both, which is why Chrome’s own guidance says “the most effective agentic applications use both MCP and WebMCP to benefit from the strengths of both technologies.” The server does the durable work. The page makes the live session legible.

One honest caveat on timing. WebMCP is an origin trial, which means it is off by default for most visitors, and Google is explicitly asking for feedback on the API shape through GitHub. Building against it now is a bet that the shape holds. The declarative half is a much smaller bet than the imperative half, because two HTML attributes on a form you already ship cost almost nothing if the spec moves again.

There is a third option that is cheaper than either, and worth knowing before you scope a build. If you run on Cloudflare, a dashboard toggle will inject a WebMCP bridge into your pages at the edge with no code at all. We turned it on and measured every part of it: 115 bytes, two tools, and one tool pack that registered nothing. It is a real head start and it is emphatically not the same as exposing what your product actually does.

If you are weighing it up as an SEO or content question rather than an engineering one, the calculation is different and mostly not urgent yet. We went into that separately in how AI agents are changing SEO, and the same principle applies here: machine readable is worth doing, but only the parts that are cheap and reversible.

Where this is heading

Google named Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart and Target as testing WebMCP at I/O in May 2026. Shopify now says its standard tool set is live automatically on every Liquid storefront, which we break down in Shopify WebMCP explained for store owners. Gemini in Chrome is getting support. Cloudflare shipped a way to inject a WebMCP bridge at the edge with no code changes at the origin. Lighthouse has added an Agentic Browsing category that looks for registered tools, though when we ran that audit on four sites every WebMCP check turned out to be weighted zero.

That is a lot of scaffolding for a standard that is six months old, and it is a reasonable signal that the direction is real even if the API is not final.

The thing to avoid is the framing that WebMCP makes servers obsolete. It cannot, by design. A tool that dies when the tab closes was never going to replace an API, and the specification says so in the first section. What it replaces is the agent squinting at your interface trying to work out which of your four buttons says “continue.”