WebMCP, examined: the spec, the GitHub, and what's actually shipped

WebMCP is the most interesting thing to happen to the "agentic web" conversation in 2026, and also one of the most over-claimed. In the space of a few weeks it went from a niche GitHub repository to a Chrome origin trial, a Lighthouse category, a nine-logo slide at Google I/O, and a small pile of blog posts declaring that the web now has a native language for AI agents. Some of that is real and shipped. A meaningful part of it is a TODO in the specification text, an unresolved GitHub issue, or a "will soon" from a vendor blog.

This is a teardown. Every load-bearing claim below is linked to a primary source — the spec, the GitHub repo and its API, Chrome's own documentation, the one peer-style attack paper that exists, and dated Hacker News threads. Where I could only verify the shape of a thing and not its exact wording, I say so rather than dress a paraphrase up as a quote. Nothing here is invented, and where the honest answer is "unknown," that is the answer I give.

I write this from a specific vantage point: I run a prerender layer that exists because the machine-readable and human-readable halves of the web keep drifting apart. WebMCP is a proposal to close a different gap — not "can the agent read the page" but "can the agent act on it." That makes it adjacent to what I do rather than a competitor, and it makes me neither a booster nor a hater. A companion piece works through the prerendering-specific angle in plain language; this one is just the honest state of the thing.

1 · What WebMCP actually is

Strip away the framing and WebMCP is a browser API that lets a web page hand an in-browser AI agent a set of callable tools, instead of forcing the agent to reverse-engineer the page by screenshot or DOM-scraping. The current primary surface is imperative JavaScript:

const registration = document.modelContext.registerTool({
  name: "add_to_cart",
  description: "Add a product to the shopping cart",
  inputSchema: { /* JSON Schema */ },
  async execute(args) {
    // do the work in-page, using the user's existing session
    return { content: [{ type: "text", text: "Added to cart." }] };
  }
});

A few things are worth pinning down precisely, because a lot of secondhand write-ups get them wrong:

• It's document.modelContext, not navigator.modelContext. Chrome's own documentation states verbatim that "navigator.modelContext is deprecated in Chrome 150. Use document.modelContext instead," and the current spec README uses document.modelContext exclusively. If you read a tutorial still calling navigator.modelContext.registerTool(), it is already stale. (Chrome imperative-API docs)
• You unregister a tool with an AbortSignal, not an unregisterTool() method. registerTool takes an options object with { signal, exposedTo }; aborting the signal removes the tool. There is also an ontoolchange event. (spec)
• execute() returns MCP-style content arrays — { content: [{ type: "text", text: … }] } — which is the one place the "MCP" in the name is more than branding.

There is also a declarative API, and this is where the first gap between marketing and reality opens up. The idea is elegant: annotate an ordinary HTML <form> with attributes — toolname, tooldescription, toolautosubmit, and per-control toolparamdescription — and the browser synthesizes a tool from the form, with responses flowing back through SubmitEvent#respondWith() or a JSON-LD fallback. Without toolautosubmit the browser focuses the submit button and waits for the human — human-in-the-loop by default. It's a genuinely nice design. It is also, in the specification itself, marked "This section is entirely a TODO"; the declarative API lives in an explainer document, not in normative spec text, and the schema-synthesis algorithm is tracked as open issue #210. Treat the declarative API as a design intent, not a shipping feature.

One naming point that trips everyone up: WebMCP is not wire-compatible with MCP. It doesn't speak JSON-RPC. The Arcade.dev interview with Alex Nahas (whose "MCP-B" project is part of WebMCP's lineage) frames it bluntly — "WebMCP is not MCP. It doesn't follow the JSON-RPC spec" — though that's the article's framing, not a spoken quote I can attribute to Nahas directly. (Arcade.dev) The shared vocabulary of "tools" is real; the shared protocol is not.

2 · Where it actually stands — governance

Here is the single most important sentence for anyone deciding whether to build on WebMCP today, and it is in the spec's own boilerplate: the document is a "Draft Community Group Report, 24 June 2026" of the W3C Web Machine Learning Community Group, and it is "not a W3C Standard nor is it on the W3C Standards Track." (spec, Status of This Document) A Community Group report is a place to incubate ideas. It carries no cross-vendor commitment. The transition to an actual Working Group is itself just an open issue — #192 ("Transitioning WebMCP to the working group?"), opened 2026-05-28 by WebKit contributor mwyrzykowski.

The provenance is genuinely two-vendor, which is more than many incubations get. Looking at the GitHub contributors API (checked 2026-07-02), the top committers are Brandon Walderman (Microsoft, 24 commits), victorhuangwq (23), Dominic Farolino (Google, 20) and Khushal Sagar (Google, 14); Intel's Anssi Kostiainen chairs the group. The spec editors are Walderman, Sagar and Farolino. So: Microsoft and Google engineers doing the drafting, Intel chairing. That's real.

What that provenance does not include is the other half of the browser market:

• WebKit / Apple has formally opposed. The standards-position issue (WebKit #670) is closed with a position: oppose label, plus concern labels spanning API design, duplication, portability, privacy, security, internationalization, venue, use cases, and meaningful user consent. That is not a shrug; it is a detailed objection across nearly every axis.
• Mozilla has taken no formal position. There is an open, unlabeled position request (mozilla/standards-positions #1412) and an earlier closed one (#1391). "No position yet" is the accurate reading — not endorsement, not opposition.
• Edge has shipped nothing. Microsoft co-authored the spec, but there is no Edge origin trial, no flag, and no announcement wiring Copilot to WebMCP.

The repository itself is active but young: 2,729 stars, 103 open issues against roughly 50 closed, created 2025-08-05, with substantive API churn in June 2026 alone — promise-based registerTool (PR #200), abort-signal rejection semantics (#202), and the deliberate removal of the ModelContextClient interface (#205, merged 2026-06-11). Churn like that inside a single release cycle is normal for an incubation and disqualifying for anything you need to be stable.

3 · The origin trial, and the chicken that has no egg

WebMCP is a real, running Chrome origin trial. It starts at Chrome 149; the official announcement went up 2026-06-09; the registration ID is 4163014905550602241; and there's a local flag, chrome://flags/#enable-webmcp-testing, for testing without registering. (Chrome origin-trial announcement) You can, today, register tools on a page and watch a compatible agent surface enumerate them.

Two constraints matter more than the launch does. First: there is no headless access. Chrome's docs are explicit — "there is no support for agents or assistive tools to call tools in a headless state." WebMCP tools require an origin-isolated, visible document. That excludes exactly the background-automation use cases that most server-side MCP deployments are built for. Second, and more awkward: Google's own agent doesn't consume WebMCP yet. The I/O 2026 language is "Gemini in Chrome will soon support WebMCP APIs," and Gemini's shipping agentic feature, Auto Browse, launched without WebMCP. (Chrome at I/O 2026)

So the state of play in mid-2026 is: sites can publish tools, and there is no first-party agent that calls them. The most-commented open issue in the repo — #51, on the in-page agent-consumption API, with 44 comments — is precisely this hole, and the README still reads "TODO: Spec and describe the modelContext.getTools() and modelContext.executeTool() APIs." The half of the protocol that lets a third-party agent read and invoke tools is unspecified. Interop today runs entirely through Chrome's private implementation, or through the community @mcp-b/global polyfill.

4 · The good — stated as plainly as the bad

A teardown that only tears down is dishonest. Several things about WebMCP are genuinely well done:

1. Conservative, double-gated security defaults. The Permissions-Policy feature tools defaults to an allowlist of ['self']. A cross-origin iframe needs an explicit allow="tools" and the tool needs a per-tool exposedTo opt-in; a denied call rejects with a NotAllowedError DOMException. Origin isolation is on by default, not bolted on later. (spec)
2. Idiomatic platform design. AbortSignal for teardown, an ontoolchange event, reusing SubmitEvent#respondWith() and JSON-LD rather than inventing parallel machinery — this is a proposal written by people who know the web platform.
3. It solves a real MCP pain point. Because tools execute in the page under the user's existing session, there's no separate server replicating state and re-implementing auth. That was literally the founding motivation of the MCP-B project that fed into WebMCP — the OAuth-2.1 pain of standing up a separate MCP server. (Arcade.dev)
4. An unusually candid threat model. The spec enumerates its own attack classes — tool poisoning, output injection, tool-implementation-as-target — and Chrome's guidance says out loud that "it's impossible to guarantee safety inside of a large language model." (Chrome secure-tools) That honesty is worth more than a glossier pitch would be.
5. A measurable efficiency claim exists. An implementer quoted by InfoQ reports "roughly ~90% decrease in token usage" versus screenshot-loop automation — one benchmark from one implementer, not an established fact, but a real, sourced number. (InfoQ)

5 · The bad — the parts the launch posts skip

1. Single-engine, with active headwind. One shipping implementation (Chrome), a formal WebKit oppose across eight-plus concern axes, no Mozilla position, and nothing from Edge despite co-authorship. Building on WebMCP today is building on Chrome, full stop.
2. Not a standard. A Draft Community Group Report, explicitly off the standards track, with Working-Group transition merely proposed (#192).
3. The agent-consumption half is a hole. getTools() / executeTool() are literal TODOs; ModelContextClient was removed in June (#205); the most-discussed issue in the repo is about exactly this gap.
4. The declarative API is "entirely a TODO," and the maintainer of Angular has questioned on the tracker whether it fits JavaScript-driven forms (#138) — i.e. much of the modern web.
5. API churn inside one release cycle. The trial's own navigator.modelContext is deprecated in Chrome 150 in favor of document.modelContext. Trial participants already need feature detection to survive a point release.
6. No enforced schema validation. The browser serializes your inputSchema but does not validate agent-supplied arguments against it; who owns validation is open issue #92 ("Who owns the validation layer?"), and output schemas are #9. Every execute() handler has to defensively re-validate its inputs.
7. The auth model's strength is also its sharpest edge. Tools ride the user's authenticated first-party session. Origin isolation controls which sites can expose tools; it does nothing to constrain what a hijacked agent does inside a logged-in session. Per-tool session and consent management is unresolved (#87, #165, #50, #198), and requestUserInteraction() — which Chrome's secure-tools page still references — isn't in the current spec text at all.
8. No headless. A visible tab is required, excluding the background-agent workloads MCP is most used for.
9. Adopter evidence is marketing-grade. More on this next.

On adopters specifically: Google's I/O blog shows a logo wall of nine brands "experimenting with WebMCP" — Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, and Target. (Chrome at I/O 2026) I could find no independent company announcement and no observable production WebMCP deployment for any of the nine. The correct verb is "named by Google as experimenting," never "adopted." Nine logos on a vendor slide is a signal of interest, not of shipping.

6 · Security — the one paper that actually exists

Most of the WebMCP security commentary online is hand-waving in both directions. There is, as of this writing, exactly one rigorous demonstrated-attack study: arXiv 2606.06387, "WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents" (Lee, Chang, Yu, Yeh; submitted 2026-06-04). It defines a family of attacks in which a page manipulates its own tool surface at runtime to steer an agent. The headline numbers are stark: a mid-session tool-injection variant (registration race) hit 100% attack-success rate across GPT-5.4, Claude Opus 4.6 and Gemini 2.5-flash, and the combined description-plus-readOnlyHint manipulation also reached 100% — meaning the very "hints" meant to reassure agents were weaponized to deceive them. Not every variant was that total (a long-description-only attack ranged from 0% against Claude to 72% against Gemini) — but the worst cases leave nothing on the table.

Two caveats keep this honest, and both come from the authors themselves. First, the testbed was the CDN-loaded @mcp-b/global polyfill running in headless Node.js — not Chrome's native implementation — and the authors explicitly note that feasibility "may vary" against the real browser. So the numbers describe the polyfill's threat surface, not a proven native exploit. Second — and this is a correction to some secondhand summaries — the authors did not just describe attacks; they prototyped and evaluated defenses (origin-bound tool IDs, lifecycle validation, data-flow restrictions, provenance logging) and reported 0% ASR against them in their testbed. The accurate framing is "defenses demonstrated in research, none shipped in the spec or browsers" — not "no one has a fix."

The spec's own Security Considerations are, to their credit, candid about the structural problem. The trust-gap sentence is verbatim: "There is no guarantee that a WebMCP tool's declared intent matches its actual behavior." The shipped mitigations — the tools Permissions-Policy default, exposedTo, untrustedContentHint, readOnlyHint — are real origin isolation plus a set of advisory hints. Hints constrain well-behaved agents; they do nothing to an attacker. What does not exist yet: signed or attestable tool definitions, cryptographic binding of a tool to its origin, any enforced (rather than advisory) trust boundary, and — the root issue under all of it — separation of the LLM's instructions from the page's data.

7 · Community pulse

The honest sentiment read is mixed: skeptical on Hacker News, more pragmatic in developer-tooling press. The reservations are consistent and worth quoting directly rather than paraphrasing. All of these are verbatim, with links:

• "This seems like a security nightmare, a way to inject insecure content onto everyone's PC which can then automate actions executed with full user/admin privileges? Why on Earth would I want this?" — saberience, HN, Oct 18 2025
• "Basically I have to put in work setting up WebMCP, so that Google can have a better agent that disintermediates my site." — arjunchint, HN, Mar 2 2026
• "HTML is one of the few RESTful systems people still use today — build semantics into the page and humans and LLMs can understand how to use it." — _heimdall, HN thread 47211249
• "More people will make their stuff machine-accessible and that's a good thing even if MCP won't last or if it's like VHS — yes Betamax was better, but VHS pushed home video." — paraknight, HN, Mar 1 2026

The "we already had this" objection — HTML and the accessibility tree are already a machine-readable action space — is not just a forum complaint; it's an open issue on the repo (#91, 19 comments, on accessibility-tree redundancy). It is the critique the proposal most needs to answer and hasn't yet.

8 · What's genuinely unknown

These are the open questions I'd hold any WebMCP planning against. None of them has an answer today, and anyone selling you certainty on them is guessing:

• When — or whether — Gemini in Chrome actually consumes WebMCP. "Coming soon" since I/O; no first-party caller exists yet.
• The origin trial's end date and graduation criteria. No primary source names an end milestone. Anyone planning around a specific end version is planning around a number I could not verify.
• The standards-track future. Does #192 become a Working Group? Does WebKit's oppose foreclose multi-engine support? Will Mozilla ever label #1412?
• The agent-consumption API (#51). What getTools()/executeTool() finally look like decides whether third-party agents, extensions, and assistive tech get real interop.
• Whether the poisoning attacks reproduce against native Chrome. The arXiv results are polyfill-and-Node only by the authors' own admission — the single most important unanswered security question.
• Whether any of the nine logo-wall brands ship production tools. Zero independent evidence so far.

9 · FAQ

The questions that come up most, on the tracker, on Hacker News, and in my inbox. (Reddit, notably, has barely engaged — the argument is happening on HN and GitHub, not the subreddits.)

Is WebMCP an official web standard?

No. It's a "Draft Community Group Report, 24 June 2026" — an incubation, explicitly "not a W3C Standard nor on the W3C Standards Track." Editors are Brandon Walderman (Microsoft), Khushal Sagar and Dominic Farolino (Google). (spec)

Does any AI agent actually call WebMCP tools yet?

Effectively no, not in shipping first-party form. Google's own language is "Gemini in Chrome will soon support WebMCP APIs," with no date, and its shipped Auto Browse launched without it. The one working consumer today is the community MCP-B browser extension, which aggregates tools from open tabs into a local MCP client. (I/O 2026)

How is WebMCP different from Anthropic's MCP?

MCP runs as a server process and speaks JSON-RPC; you stand up and authenticate a separate server. WebMCP runs inside the browser tab, reuses the user's existing logged-in session, and exposes JavaScript functions or form actions as tools. It shares MCP's vocabulary ("tools," content arrays) but is not wire-compatible — it doesn't speak JSON-RPC, and Anthropic is not involved in the spec.

Does it work with React / Next.js / JavaScript-rendered forms?

The imperative registerTool() API works from any framework, provided your tool logic can reach a shared service layer rather than being trapped in component state. The declarative form-annotation API is a different story: it's marked "entirely a TODO" in the spec, and Angular's maintainer has questioned on the tracker (#138) whether it fits JS-driven forms at all — i.e. most of the modern web.

Does it work headless?

No. Chrome's docs are explicit that there's "no support for agents or assistive tools to call tools in a headless state." WebMCP requires a visible, origin-isolated document — which rules out the background-automation jobs most server-side MCP is used for.

Do I need to register for the origin trial?

To expose tools to real users on Chrome 149–156, yes — register the origin (ID 4163014905550602241). For local development you can flip chrome://flags/#enable-webmcp-testing and skip registration. (origin-trial announcement)

Which browsers support it?

Chrome, in any real sense. WebKit has formally opposed; Mozilla has filed no position (#1412, open); and Edge has shipped nothing despite Microsoft co-authoring the spec. Building on WebMCP today is building on Chrome.

Does it replace SEO or structured data?

No — different jobs. Schema.org / JSON-LD describes what a page contains, for discovery and citation. WebMCP describes what a page can do, for action. They're complementary layers, and the read layer (crawlable content) still has to exist for either to matter.

Isn't this just the accessibility tree with a new name?

The sharpest architectural critique, and an open issue (#91): the accessibility tree already exposes a machine-readable action space, and because it's derived from the DOM it can't desync — whereas a hand-maintained WebMCP surface will drift from the UI over time. WebMCP's counter is that it offers typed, callable actions with schemas, not just described elements. The spec editors haven't publicly answered the issue.

Will adding WebMCP just help Google disintermediate my site?

A live worry with no clean answer from Google — the concern that agent-only flows bypass the ad-supported parts of a page. It's telling that a FreeCodeCamp scan found zero of 111,076 top sites shipping WebMCP as of mid-2026. Interest is real; production adoption is not.

10 · Where I land

WebMCP is a serious, well-engineered proposal to a real problem — agents currently act on the web by imitating a human's eyes and mouse, and that is slow, brittle, and expensive. The security honesty is refreshing, the platform design is idiomatic, and the two-vendor provenance is more than most incubations manage. If the agentic web is going to have a native "act" layer, something shaped like this is a reasonable candidate for it.

But in mid-2026 it is an incubation, not a standard: one shipping engine, an opposing engine, a silent third, an agent-consumption API that is still a TODO, a declarative API that is "entirely a TODO," a real attack paper whose defenses live only in research, and an adopter story that is nine logos on a slide. The correct posture for a site owner is to watch it closely and build nothing load-bearing on it yet. Prototype behind the flag if you're curious. Do not put it on a roadmap you have to keep.

And notice what has to be true before any of it matters: an agent can only act on a page it can first read. The tools an agent invokes still live in a document that a crawler or a headless retrieval bot has to be able to fetch and render. The "act" layer sits on top of the "read" layer, and the read layer is where most sites are still quietly broken. That's the subject of the companion piece — and, not coincidentally, the problem I actually work on.

Companion reading: WebMCP, explained — the plain-language version · The strange afterlife of dynamic rendering · The bot directory

Sourcing note: every factual claim in this piece is linked to a primary source — the WebMCP spec, the GitHub repository and its API, Chrome's documentation, the arXiv poisoning paper, and dated Hacker News threads. Repo statistics and issue counts were read from the GitHub API on 2026-07-02 and will drift. Where I could verify only the shape of a claim and not its exact wording, the text says so.