What is WebMCP?

WebMCP lets a web page expose parts of itself as tools: JavaScript functions with a plain-language description and a structured schema, written for AI agents to call. An agent built into the browser, running in an extension, or hosted in an iframe can then ask the page to do something directly, instead of operating an interface designed for human eyes and hands.

A tool, in one example

A page registers a tool by calling document.modelContext.registerTool(). This example is adapted from the specification's README:

await document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string", description: "The text content of the todo item" }
    },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return {
      content: [{ type: "text", text: "Added todo item: " + text }]
    };
  }
});

Four things make up a tool. The name and description tell the agent what the tool is for. The input schema says what arguments it takes. The execute function is the page's own code, and it runs in the page when the agent calls the tool.

What happens when an agent uses a tool

Registration. The page registers one or more tools.
Discovery. An agent connected to the page asks the browser which tools are active, and reads their schemas.
Invocation. The agent calls a tool with arguments that match its schema.
Execution. The browser runs the tool's execute function with those arguments, on the page.
Response. The function returns a structured result, and the agent carries on with the user's task.

This is the lifecycle described in the specification.

How it differs from a backend MCP server

The Model Context Protocol (MCP) normally connects an AI platform to a service's backend. The service runs a server, and the platform talks to it directly. WebMCP moves that idea into the page. The specification describes a page that uses WebMCP as an in-page MCP server whose tools expose client-side logic and the page's own interface, not server-side APIs.

The specification's stated reasons are that a backend integration bypasses the page's interface, forces developers to replicate the user's state and sign-in on a separate server, and means writing a dedicated backend for something the page's JavaScript can already do.

Two spellings, and a declarative idea

The current specification text uses document.modelContext. Implementations have referenced navigator.modelContext as well, and some look at one before the other. Our crawler instruments both, so a site is found whichever it uses.
The specification defines the imperative, JavaScript API. A declarative counterpart, where the browser would build tool definitions from HTML <form> elements, is being explored separately and is not part of the specification.

Browser and agent support changes quickly. The project keeps a live implementation status page; check it rather than relying on a snapshot in an article.

How many sites use it today

We crawl a large sample of the web and record which sites register tools. In our sealed file for 2026-10-10, we crawled 6,279,103 domains and found 104,881 sites that declare WebMCP tools. They fall into two very different groups:

Kind	Sites	Share
Vendor-distributed (a platform ships the tool set to its sites)	99,080	94.5%
Independent (the site wrote its own implementation)	5,801	5.5%

Adoption is not zero, but it is mostly vendor-distributed. For example, 80,158 of these sites carry one of the tool sets that Shopify distributes (see the Shopify page), and the individual merchants did not opt in one by one. Quoting a single total without this split misstates what the data shows.

What a declaration does and does not tell you

We read the tool names and descriptions a page declares. We never invoke a tool.
What a tool does is inferred from its name and description. We have not yet published an accuracy measurement for that inference.
A declared tool is not a vulnerability, and a finding in our data is not evidence that a site has a security problem. These are measured indicators, not audits.
The crawl is a sample, not a census. Sites that disallow our crawler in robots.txt are excluded and counted separately.

The full method and its limits are on the main page. Every number above comes from a sealed, dated file with a published sha256 in the index, so it can be checked and does not change.