Skip to content

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

WebMCP is a W3C Community Group draft that lets a web page expose JavaScript functions as MCP-style tools through navigator.modelContext, so a browser-resident agent invokes them by name and JSON Schema instead of clicking and typing into 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 out tool calls in parallel, needs to operate without an open tab, or already has an authoritative API to talk to. Google's own guidance frames the two as complementary: server-side MCP is the call-centre that answers from anywhere; WebMCP is the in-store expert available 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 (20 May 2026) of the W3C Web Machine Learning Community Group, 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 tool is 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 that the tool's output 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({...}) from JavaScript) and a Declarative API (HTML form-element annotations the browser synthesizes into a JSON Schema). An exposedOrigins list and a tools permissions-policy feature scope which embedded origins can see and invoke a page's tools.

Why It Works

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

WebMCP replaces actuation with a typed function call against a contract the page itself declares. The agent stops serializing rendered HTML into its context, and the "which element is the Add to Cart button" inference disappears because the page exposes a tool named addToCart with an explicit JSON Schema. Chrome's early-preview write-up frames the gain as "increased speed, reliability, and precision" relative to actuation (Chrome for Developers: WebMCP early preview). Early pilot numbers — a 67.6% token-usage reduction, 25–37% latency improvement, and 97.9% task success rate — circulate in secondhand coverage (Manveer Chawla: The WebMCP False Economy) and remain to be reproduced in independent benchmarks.

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 run on the page event loop and require an open tab or webview. CI runners, server-side cron jobs, and any agent that fans tool calls out in parallel cannot use them; tool calls within a page are sequential rather than parallel (WebMCP spec §5.1). Target server-side MCP for those surfaces.
  • Long-tail sites with no UI investment budget — The 20-year history of voluntary developer-maintained metadata (microformats, schema.org, OpenGraph) shows that long-tail content sites do not adopt new optional protocols without distribution incentives (Manveer Chawla: The WebMCP False Economy). For a restaurant menu or a civic portal, the browser synthesizing existing ARIA roles, schema.org JSON-LD, and form labels is the more realistic path than waiting for 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 as features change. The same critique calls WebMCP "a second-class annotation that describes the product rather than owning it" (Manveer Chawla: The WebMCP False Economy).
  • Multi-tab browser agents with private data in adjacent tabs — A browser agent holding logged-in session context in tab A and visiting an attacker-controlled WebMCP page in tab B receives tool descriptors and tool outputs from an untrusted origin. The spec's untrustedContentHint annotation acknowledges the threat but does not solve it, and Section 6 Security and privacy considerations of the May 2026 draft is still empty — the indirect-prompt-injection threat model is not yet normative (WebMCP spec §6). Teams evaluating browser-resident agents should treat WebMCP as one more untrusted-content surface alongside the MCP control-plane bypass and the broader lethal-trifecta threat model.

Current Adoption Status

WebMCP is available in Chrome 149 through the early preview program for registered developers (Chrome for Developers: WebMCP early preview, 2026-02-10). Microsoft is represented through co-editorship — Brandon Walderman of Microsoft is lead editor alongside Khushal Sagar and Dominic Farolino of Google. The spec remains a Community Group Draft, not a W3C Recommendation. Track 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 still empty — the indirect-prompt-injection threat model is not yet normative.
  • 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.
Last reviewed: 2026-05-27
Feedback