WebMCP: How Websites Expose Tools to AI Agents

What WebMCP is

Today, browser agents interact with websites by reading the page and simulating clicks and typing, which is slow and brittle. WebMCP proposes a structured alternative: the website declares what actions it supports as tools, with descriptions and input schemas, and agents call those tools directly. The proposal is developed in the open in the W3C Web Machine Learning community's repositories, with authors from Microsoft and Google.

How the API works

The proposal adds a modelContext getter on Document, so the entry point is document.modelContext. A page calls registerTool for each tool, passing the tool definition and an options object; tools are removed by aborting the AbortSignal passed in those options rather than by a separate unregister call. The page can also read its own registrations with getTools, invoke one with executeTool, and listen for a toolchange event.

Each tool has a name, a natural-language description, an optional inputSchema in JSON Schema, and an execute callback that runs the action using the page's own JavaScript, session, and state.

If you read an older write-up, check the entry point. The getter originally sat on Navigator, and much of the early coverage still says navigator.modelContext. The Web Machine Learning Community Group moved it to Document on the grounds that tools belong to a page rather than to the browser, and Chrome has since removed the navigator form.

A minimal example

document.modelContext.registerTool({
  name: "search_products",
  description: "Search the catalogue by keyword and optional max price.",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string" },
      maxPrice: { type: "number" }
    },
    required: ["query"]
  },
  async execute({ query, maxPrice }) {
    const results = await searchCatalogue(query, maxPrice);
    return { content: [{ type: "text", text: JSON.stringify(results) }] };
  }
});

How WebMCP differs from MCP

The Model Context Protocol connects AI clients to servers, local or remote, over a defined message format. WebMCP brings the same ideas of tools, resources, and prompts into the browser, but the page itself provides the tools and the browser mediates the calls. The proposal deliberately avoids coupling the web to a specific MCP version, so browsers can apply their own security policies.

Security and consent

Because the browser sits between the agent and the page, it can show users which agent is calling which tool and ask for consent. The proposal includes a way for a tool to request user interaction during execution, for example to confirm a purchase. Tools run with the user's existing session, so sites must treat agent calls with the same care as user actions, including authorisation checks and confirmation for sensitive operations.

Why it matters for developers

Agents that call declared tools are faster and more reliable than agents scraping and clicking. Sites that expose clear tools may become easier for users' assistants to work with, in the same way that structured data helped search engines understand pages. Tools also let sites control exactly what agents can do, instead of leaving them to guess from the interface.

What to expose first

Start with actions that are common, low-risk, and well-defined: search, filter, look up order status, read documentation, or add to a basket with confirmation at checkout. Write descriptions for a model, keep schemas strict, and return compact structured results. Avoid exposing destructive or financial actions without explicit user confirmation.

Current status

WebMCP is a Draft Community Group Report from the W3C Web Machine Learning Community Group, which explicitly is not a W3C standard and is not on the standards track. Implementation is early: origin trials in Chrome and Edge, with no implementation in Firefox or Safari beyond standards-position discussion. API names and behaviour have already changed once, so treat anything you build as an experiment, feature-detect document.modelContext before using it, and keep the normal interface as the primary path.

WebMCP and retrieval

WebMCP tools are a good way to expose a site's knowledge to agents, for example a documentation search tool that returns relevant passages instead of whole pages. Retrieval keeps agent context small and avoids regenerating answers that already exist, the same principle behind RDK's indexed vaults and stacked retrieval.

Designing good WebMCP tools

Name tools by intent, such as search_orders rather than click_button_3. Write descriptions that explain when to use the tool and what it returns. Keep input schemas strict, with enumerations where possible. Return structured, compact results that an agent can reason over, and include clear error messages when inputs are invalid or the user lacks permission. Reuse the same server-side checks your normal interface uses, so agent calls cannot bypass business rules.

Testing and progressive enhancement

Feature-detect document.modelContext and register tools only when it exists, so pages work normally in every browser. Test tools directly from the console, then with an agent, checking that descriptions lead the agent to the right tool. Monitor usage separately from human traffic so you can see how agents use the site.

What a site exposes

Tools run in the user's session and can return personal data. Return only what the task needs, and avoid exposing data the user could not normally see on the page.