v149 · origin trial · experimental

WebMCP

An API that lets a web page expose typed "tools" to a user's AI agent, and lets the agent run those tools through a shared UI on the page. Same pattern as Anthropic's Model Context Protocol for desktop agents, ported to the browser.

Heads up WebMCP is experimental and the API surface is still moving. This page is generated from the explainer + the WebMachineLearning spec draft. Treat names and shapes as authoritative as of the explainer revision linked under "Sources" below; check the spec before shipping anything.

at a glance

Shipping target	Chrome 157 (origin trial earlier)
Status in 149	Origin trial
Flag	`chrome://flags/#enable-experimental-web-platform-features`
Spec	webmachinelearning.github.io/webmcp (W3C Web Machine Learning CG)
Explainer	webmachinelearning/webmcp
Initial proposal	explainers-by-googlers / script-tools
ChromeStatus	5117755740913664 — WebMCP

why it exists

Web apps today have two surfaces: a UI for humans, and APIs for other software. Agents fall between the two. They can read the human UI but doing so is brittle; they can call your APIs but lose the page's context and any user-mediated UI step (consent, confirmation, picking from a list). WebMCP gives an app a third surface: a typed set of tools the page hosts, that the user's agent can discover, call, and reflect back into the page's own UI. The agent runs in the user's agent context; the tool runs in the page's context; both share the page DOM as common ground.

Source: chromestatus motivation + the WebMCP explainer §1 ("Background").

shape of the API

The page is the provider: it registers tools that describe its capabilities (name, JSON-Schema input, side-effect annotations). The user's agent is the consumer: it discovers the page's tools, decides when to call them, and surfaces the result in conversation. Two top-level interfaces, both on window:

navigator.modelContext

provideTools(toolset)	Register one or more typed tools on the current page. Returns a handle the page can use to update, replace, or revoke the toolset later.
provideContext(context)	Push freeform context (page summary, current selection, etc.) into the shared agent context. Updates live.
addEventListener("toolinvoke", handler)	Fires when the agent calls a tool. Handler receives a `ToolInvokeEvent` with the validated arguments and a `respondWith()` method.

ToolInvokeEvent

toolName	The registered name the agent is calling.
arguments	Object matching the tool's JSON-Schema input.
respondWith(promise)	The page returns its result. The promise resolves to a structured value (JSON-serialisable) that the agent receives.
signal	An `AbortSignal` that fires if the agent cancels the call.

Source: WebMCP explainer §3 ("Page-side API") and §4 ("Tool descriptors"). Exact identifiers may rename before ship — check the spec.

API shape disagreement, both sides reported rather than resolved (fetched 2026-10-07): this page says the surface is navigator.modelContext with provideTools(toolset) and an addEventListener("toolinvoke", handler) route, while the WebMCP explainer reports document.modelContext with registerTool() and an execute callback. Neither side is adjudicated here.

example: a page that lets the agent search its own catalogue

navigator.modelContext.provideTools([{
  name: "searchCatalogue",
  description: "Search the products on this page by free text.",
  input: {
    type: "object",
    properties: {
      query: { type: "string", description: "Free-text search query" },
      limit: { type: "integer", default: 10, maximum: 50 }
    },
    required: ["query"]
  }
}]);

navigator.modelContext.addEventListener("toolinvoke", (event) => {
  if (event.toolName !== "searchCatalogue") return;
  const { query, limit = 10 } = event.arguments;
  event.respondWith((async () => {
    const results = await search(query, limit);
    // Reflect the result into the page UI so the user can see what the agent saw.
    renderSearchResults(results);
    return { hits: results.map((r) => ({ id: r.id, title: r.title, url: r.url })) };
  })());
});

example: pushing live context the agent can read

// Whenever the user selects text, tell the agent.
document.addEventListener("selectionchange", () => {
  const selection = document.getSelection()?.toString() ?? "";
  navigator.modelContext.provideContext({
    selection: selection.slice(0, 800),
    url: location.href,
    title: document.title,
  });
});

capabilities the spec defines

Tool discovery	The agent enumerates tools the current page has provided. Tools are tied to the page's lifetime; navigating clears them.
Typed inputs	JSON-Schema. The browser validates arguments before the page sees them.
Side-effect annotations	Tools declare whether they're read-only, mutating, or destructive. The agent and the browser use this to decide whether to confirm.
Cancellation	Cooperative via `AbortSignal` on the invoke event.
Shared context	The page can push live context to the agent; the agent reads it as part of its conversation.
Origin boundaries	Tools are scoped to the providing origin. Cross-origin frames register their own.

Source: WebMCP explainer §4–§6. Field names paraphrased.

browser support

Chrome	Origin trial in 149; shipping target 157
Edge	Tracking Chromium
Firefox	No signal
Safari	No signal

Source: chromestatus browser views, May 2026. Reference here may be stale on next snapshot.

Milestone disagreement, both sides reported rather than resolved (fetched 2026-10-07): this page says the feature is in "Origin trial in 149; shipping target 157", while the chromestatus browser views reports status "Proposed" with no shipping milestone. Neither side is adjudicated here.