What is WebMCP? How Chrome lets a web page register tools for AI agents

WebMCP lets a website act as a tool provider for an agent. The draft specification describes it as a way for a page to expose client-side functions as tools with natural-language descriptions and structured input schemas, and it says the API is meant to complement backend protocols such as MCP rather than replace them (WebMCP repository).

The Model Context Protocol (MCP) is an open standard Anthropic introduced in November 2024 for connecting AI applications to external systems (Anthropic announcement, modelcontextprotocol.io). An MCP server is a separate program that an AI client starts or connects to. WebMCP tools are different because they live in the page itself and run in the user's browser tab.

• An MCP server runs outside the browser, usually as a local process or a hosted service, and any MCP client can connect to it.
• WebMCP tools run inside a loaded page, with the user's logged-in session, cookies and application state already in place.
• A client or browser must visit a site to learn whether it offers WebMCP tools, since the tools exist only while the page is open (Chrome WebMCP docs).

The tool shape is deliberately close to MCP. Both use a name, a description and a JSON Schema for the input, so the same idea of a tool carries over from one to the other. You can read more about the server side in our guide to an MCP server for API traffic.

Status as of 16 October 2026. The specification is a Draft Community Group Report dated 15 October 2026 from the W3C Web Machine Learning Community Group. It is not a W3C Standard and is not on the W3C Standards Track (spec).

• Chrome announced an early preview program for WebMCP on 10 February 2026 (Chrome blog).
• On 9 June 2026 Chrome's developer blog said you can sign up for a WebMCP origin trial in Chrome 149 (Chrome blog).
• For local development, Chrome documents the flag chrome://flags/#enable-webmcp-testing (Chrome docs).
• Chrome's documentation says WebMCP is under active discussion and subject to change.

Both the imperative and declarative APIs are gated by the tools Permissions Policy. The default is self, so tools can be registered in top-level and same-origin frames but not in cross-origin iframes, unless the iframe has allow="tools".

In the current draft the entry point is document.modelContext, an object available on secure-context pages. Its registerTool() method takes a tool definition and returns a promise. The promise rejects if a tool with the same name is already registered, if name or description is empty, or if inputSchema is invalid (spec).

A tool definition has a required name, a required description, an optional title, an inputSchema object, a required execute callback and optional annotations. The callback receives the input object and an options object with an AbortSignal called signal.

if ("modelContext" in document) {
  document.modelContext.registerTool({
    name: "search_orders",
    description: "Search the signed-in user's orders by status. Returns up to 20 orders.",
    inputSchema: {
      type: "object",
      properties: {
        status: { type: "string", enum: ["open", "shipped", "cancelled"] },
      },
      required: ["status"],
    },
    annotations: { readOnlyHint: true },
    async execute({ status }, { signal }) {
      const res = await fetch("/api/orders?status=" + encodeURIComponent(status), { signal });
      return res.json();
    },
  });
}

Other parts of the same object let you manage tools. getTools() lists registered tools, executeTool() runs one, and a toolchange event fires when tools are added or removed. To unregister a tool, pass an AbortSignal as the second argument to registerTool() and abort it.

The draft defines four boolean annotations, all false by default: readOnlyHint, untrustedContentHint, consequentialHint and debugging. Use consequentialHint for actions with real-world or irreversible effects, such as booking or paying, so an agent can ask the user first.

The declarative API turns an ordinary HTML form into a tool without any JavaScript. According to Chrome's documentation, these attributes control the result (Declarative API docs).

• toolname on the <form> names the tool. Removing it unregisters the tool.
• tooldescription on the <form> describes what the tool does.
• toolparamdescription on a field describes that field in the generated JSON Schema. If it is missing, the browser falls back to the field's <label>, then aria-description.
• toolautosubmit on the <form> submits the form when the agent invokes it. Without it, the user clicks Submit.

<form toolname="createSupportRequest"
      tooldescription="Submits a request for customer support.">
  <select name="team" required
          toolparamdescription="Determines what team this request is routed to.">
    <option value="billing">Billing</option>
    <option value="technical">Technical</option>
  </select>
  <button type="submit">Send</button>
</form>

The spec repository states that the declarative approach was still being explored separately from the core specification, so the form attributes are documented by Chrome rather than defined in the draft spec text. When an agent triggers a form, SubmitEvent.agentInvoked is true, which lets your code tell agent submissions from human ones.

Several companies have published work on WebMCP in 2026. These are dated facts from their own announcements, and they say nothing about where the standard will end up.

• Cloudflare launched a WebMCP developer preview on 6 August 2026. A dashboard setting uses HTMLRewriter to add a script that registers tools through document.modelContext (Cloudflare blog).
• OpenAI announced the WebMCP Challenge on 25 August 2026, a 10-day hackathon run with Google Chrome, Cloudflare, Shopify, Vercel, Render and Netlify. Submissions closed in early September and OpenAI said winners would be announced on 23 September (OpenAI community post).

Chrome Extensions can also query and execute WebMCP tools through content scripts, according to Chrome's documentation.

Writing a tool by hand means working out the endpoint, its parameters and its schema. Netraptor is a Chrome extension that records the fetch and XHR traffic of your own app locally in your browser. Its Agent Tools tab in the DevTools panel derives tool definitions from that traffic. Pro includes the full tab, and Free previews 3 tools.

• One tool per endpoint (method plus path template), per detected form and per GraphQL operation.
• Each tool has a name, a description placeholder for you to edit, a "Built from" note, and an input schema inferred from real parameters and bodies (JSON Schema draft 2020-12).
• Tools carry read-only, destructive and needs-confirmation flags. Names such as cancel, archive, reject, reset and logout are treated as destructive.

Netraptor produces three outputs. The first is imperative JavaScript in the form if ("modelContext" in document) { document.modelContext.registerTool({ name, description, inputSchema, async execute(input) { ... } }) }, where execute calls the endpoint with fetch. The second is declarative markup using toolname, tooldescription and toolparamdescription. The third is a list of MCP tool definitions as JSON.

As of 16 October 2026 the first two outputs use the same entry point and attribute names as the spec and Chrome documentation described above. The JavaScript output does not set WebMCP annotations, so add consequentialHint: true yourself to tools that change data. The MCP JSON file uses MCP's own annotation names (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), which differ from WebMCP's.

You can pair this with the API map of your app to decide which endpoints deserve to be tools, or export an OpenAPI spec for the same traffic. Netraptor Free covers recording and exports. Pro is a one-time $29.99 purchase.