WebMCP

WebMCP is a browser API proposal that lets web pages expose JavaScript functions as structured tools to AI agents. Built on top of the Model Context Protocol, it replaces DOM scraping and screenshot-based interaction with explicit navigator.modelContext.registerTool() calls, giving agents named tools with JSON Schema inputs and same-origin scoping by default.

In Plain Words

Until WebMCP, an AI agent driving a website had two choices. It could read the rendered DOM and try to figure out which button does what, or it could screenshot the page and ask a vision model to predict where to click. Both are brittle. Both break the moment the page redesigns a tooltip.

WebMCP flips the contract. The page itself declares: 'I expose these tools. Each takes these inputs. Call them like functions.' The agent stops guessing. It calls addToCart({ sku: 'A123', qty: 2 }) the same way it would call a remote MCP server, except the implementation runs inside the page that the user is already authenticated to.

How It Works

A page registers tools through the new navigator.modelContext interface. Each tool has a name, a natural-language description, an optional JSON Schema for its inputs, and an execute callback that runs in the page's own JavaScript context.

navigator.modelContext.registerTool({
  name: "addToCart",
  description: "Add a product to the user's shopping cart.",
  inputSchema: {
    type: "object",
    properties: {
      sku: { type: "string" },
      quantity: { type: "integer", minimum: 1 }
    },
    required: ["sku"]
  },
  async execute({ sku, quantity = 1 }) {
    return await cart.add(sku, quantity);
  }
});

An agent connected to the browser (a sidebar assistant, an extension, a desktop client) discovers the registered tools, picks one, and invokes it. The page handles auth, validation, and rendering. The agent never touches the DOM.

A declarative form variant is also drafted: HTML attributes like toolname and tooldescription on a <form> element let the browser synthesize a tool from existing markup, no JavaScript required.

Security Model

Tool exposure is gated by a Permissions Policy feature named tools, which defaults to ['self']. Tools are visible only to same-origin documents unless the page lists other origins through an exposedTo parameter.

• Read-only hint: a tool can declare it does not modify state, letting agent runtimes skip confirmation prompts for queries.
• Untrusted content hint: outputs returned to the agent can be flagged as untrustworthy, so the agent treats them as user-controlled data rather than instructions.
• Human-in-the-loop: the requestUserInteraction() call pauses a tool mid-execution until the user clicks an explicit confirmation.

Why It Matters

Agent reliability on the web is mostly bottlenecked by interface drift. A pixel-driven agent that books a flight today might fail tomorrow because the airline moved a button two columns over. WebMCP makes the contract structural instead of visual, so the surface that the agent depends on is the same surface the developer maintains intentionally.

It also reuses the trust boundary the user already established. The agent runs in the open tab where the user is logged in, with that origin's cookies and CSP. There is no separate OAuth dance to wire an agent into a SaaS account: the user's session is the credential.

WebMCP vs MCP

Both share a tool-and-schema vocabulary. The difference is where the tool runs.

Origin

WebMCP is incubated by the W3C Web Machine Learning Community Group, with the initial proposal driven by engineers at Google and Microsoft. The first Draft Community Group Report landed on 20 May 2026. An early preview ships behind a flag in Chrome 146 Canary. It is not yet on the W3C standards track, so the API surface is still moving.

See the editor's draft at webmachinelearning.github.io/webmcp for the current shape of the spec.