WebMCP: Browser-Hosted Tool Contracts for In-Page AI Agents¶

WebMCP, a W3C draft, lets a page register JavaScript tools via navigator.modelContext so an in-tab agent calls them by name instead of actuating the DOM.

When WebMCP is the right tool¶

WebMCP fits a narrow surface: an interactive in-tab single-page application where a logged-in user and an agent share UI state and the agent operates only while the tab is open. Reach for WebMCP when:

The user keeps the tab in the foreground and watches the agent work
The action depends on session state already loaded into the page (filters, cart, multi-step form progress)
A server-side MCP server would duplicate logic that today lives only in the client
The agent is the browser's own (Antigravity, Claude for Chrome, a built-in or extension-installed agent), not a headless CI runner

Reach for server-side MCP instead when the agent runs headlessly, fans tool calls out in parallel, operates without an open tab, or already has an authoritative API. Google frames the two as complementary: server-side MCP answers from anywhere, WebMCP only while you are on the site (Chrome for Developers: When to use WebMCP and MCP).

What WebMCP defines¶

The WebMCP specification is a Draft Community Group Report of the W3C Web Machine Learning Community Group (revision of 25 September 2026), with editors from Microsoft and Google. It is not on the W3C Standards Track.

The spec adds one entry point — navigator.modelContext — and one tool descriptor shape: a JavaScript function with a name, a natural-language description, a JSON Schema inputSchema, and an execute callback. Tools carry annotations including readOnlyHint and untrustedContentHint. The latter signals output that may contain content from outside the application's trust boundary, propagating the MCP trust model into the page. Two registration shapes coexist (Chrome for Developers: WebMCP): an imperative API (navigator.modelContext.registerTool({...})) and a declarative API (HTML form-element annotations the browser synthesizes into a JSON Schema). An exposedTo registration option (a list of origins) and a tools permissions-policy feature scope which embedded origins can invoke a page's tools.

Why it works¶

Without WebMCP, a browser agent reaches the page's actions through DOM actuation — serializing rendered HTML, picking a target element by visual or accessibility cues, and simulating clicks and keystrokes (Chrome for Developers: WebMCP). Every step is open to interpretation.

WebMCP replaces actuation with a typed function call against a contract the page declares. The agent stops serializing HTML, and the "which element is the Add to Cart button" inference disappears because the page exposes an addToCart tool with an explicit JSON Schema. Chrome frames the gain as "increased speed, reliability, and precision" (Chrome for Developers: WebMCP early preview). Pilot numbers cited in secondhand coverage — a 67.6% token reduction and 97.9% task success — remain to be reproduced in independent benchmarks (Manveer Chawla: The WebMCP False Economy).

When this backfires¶

WebMCP carries real adoption and security costs. The cases below mark where reaching for it makes the system worse:

Headless or background agents — WebMCP tools live in the page's event loop, so they need an open tab (WebMCP spec §5.1). CI runners and server-side cron jobs want server-side MCP instead.
Long-tail sites with no UI investment budget — Twenty years of voluntary metadata (microformats, schema.org, OpenGraph) show that long-tail sites do not adopt optional protocols without distribution incentives (Manveer Chawla: The WebMCP False Economy). For a restaurant menu, the browser synthesizing existing ARIA roles and form labels is more realistic than a registerTool call that never ships.
Teams that already maintain a server-side API or MCP server — A WebMCP descriptor written against the in-page UI becomes a second tool contract that drifts from the server API; the same critique calls it "a second-class annotation that describes a UI rather than owning the functionality" (Manveer Chawla: The WebMCP False Economy).
Multi-tab browser agents with private data in adjacent tabs — An agent holding a logged-in session in tab A and visiting an attacker-controlled WebMCP page in tab B receives tool descriptors and outputs from an untrusted origin. The untrustedContentHint annotation acknowledges the threat but does not solve it. Section 6, 'Security and Privacy Considerations', is non-normative: it names prompt injection through tool metadata, inputs, and outputs as a key risk, and states that the document "cannot define precise mitigation strategies that agents or user agents must provide" (WebMCP spec §6). Treat WebMCP as one more untrusted-content surface alongside the lethal-trifecta threat model.

Current adoption status¶

Google opened a WebMCP early preview program on 10 February 2026 (Chrome for Developers: WebMCP early preview), and a WebMCP origin trial runs from Chrome 149 (Chrome for Developers: WebMCP). The spec editors are Brandon Walderman of Microsoft and Khushal Sagar and Dominic Farolino of Google. The spec remains a Community Group Draft, not a W3C Recommendation. Vercel added experimental WebMCP support to its mcp-handler package on 18 September 2026, with tools opted in through an experimental_webMcp option (Vercel changelog).

The implementation existing does not mean agents use it. A May 2026 scan of 111,076 of the top 200,000 websites found zero shipping WebMCP, and the author's own deployed tools had nothing calling them because no production browser fully executed them (freeCodeCamp: A Developer's Guide to WebMCP — Shipping a 0% Adoption Standard). Until a shipping agent consumes these tools, WebMCP is a capability to track, not one to build against. Follow changes at webmachinelearning.github.io/webmcp.

Example¶

A page registers a single tool that the browser's agent can call when the user asks to filter a search result. The page owns the state — the agent does not need to know how the filter UI is implemented:

navigator.modelContext.registerTool({
  name: "applyPriceFilter",
  description: "Filter the visible search results to listings under the given maximum price in USD.",
  inputSchema: {
    type: "object",
    properties: {
      maxPriceUsd: {
        type: "number",
        minimum: 0,
        description: "Maximum price in USD; results above this are hidden."
      }
    },
    required: ["maxPriceUsd"]
  },
  annotations: { readOnlyHint: true },
  execute: ({ maxPriceUsd }) => {
    applyFilter({ price: { lte: maxPriceUsd } });
    return { filteredCount: getVisibleListings().length };
  }
});

The agent calls applyPriceFilter({maxPriceUsd: 50}) by name and receives a structured result; it never has to find the price slider in the DOM. readOnlyHint: true lets the browser agent surface the call as a low-risk action (WebMCP spec §4.2.1).

Key Takeaways¶

WebMCP is a W3C Community Group draft, not a Standards Track recommendation — treat it as an experimental Chrome early-preview capability rather than a broadly supported standard.
The right place for WebMCP is in-tab interactive flows where the agent and user share UI state; server-side MCP remains the right answer for headless, parallel, or multi-platform agents.
Tool descriptors carry an untrustedContentHint annotation, but the spec's Security and Privacy section is non-normative and leaves prompt-injection mitigations to agents and browsers.
Two API shapes (Imperative registerTool, Declarative HTML annotations) coexist; the declarative form is the lighter on-ramp for standard form submissions.
Adoption follows the same long-tail dynamics as past voluntary metadata standards; sites with no UI investment budget will not author WebMCP descriptors, so browser-side synthesis from existing accessibility metadata remains complementary.