WebMCP Tool: your site is about to have AI agent visitors with no hands.

WebMCP is a proposed web standard that lets websites declare their capabilities as structured tools that AI agents can call. A tool is a name, a description in natural language, and a JSON Schema for its arguments. Instead of an agent falling back on DOM scraping and inferring which button submits a booking, the page hands over tool definitions and the agent calls the tool directly in the browser.

The vocabulary is borrowed from the Model Context Protocol and moved into the page, where the session already holds the visitor’s login. No keys change hands, no separate server is stood up, and a tool is reachable only while the tab is open. The specification is a W3C Community Group draft in the Web Machine Learning group, which is not the same thing as a ratified standard: it can still change under you, and in July 2026 it did.

The imperative API is the stable path: call registerTool on document.modelContext with an input schema and an execute callback, and register custom tools for anything the page can already do. The declarative API annotates HTML forms instead and lets the browser derive it from the fields you have, which is the shorter route in the common scenario where you just want to make existing forms agent-accessible.

await document.modelContext.registerTool({
  name: "search_products",
  description:
    "Search the catalogue by free text. Returns up to 20 matches with " +
    "price and stock status. Use before get_product_details.",
  inputSchema: {
    type: "object",
    properties: { query: { type: "string", description: "Free-text term" } },
    required: ["query"],
  },
  annotations: { readOnlyHint: true },
  execute: async ({ query }, { signal }) => {
    const res = await fetch(`/search?q=${query}`, {
      credentials: "same-origin",
      signal,
    });
    return { content: [{ type: "text", text: JSON.stringify(await res.json()) }] };
  },
});

One read-only tool, complete. The agent gets a name, a description and typed arguments instead of a screenshot.

Register tools when relevant and unregister them when they unmount, so the list can change contextually as the agent navigates. An AbortSignal handed to registerTool does the unregistering for you. If you already think about state in a component tree, tool registration belongs in the same place as everything else that mounts and goes away. The imperative API in detail, or annotating the forms you already have.

A separate server is still the right answer for anything that has to happen while nobody is looking, and an MCP server plus a machine-readable description of your APIs is worth points here for exactly that reason. WebMCP tool calls are the opposite case: no second deployment, no key exchange, and the permission to act is the login the person already has. The permissions policy defaults to self, so registration is off in cross-origin iframes unless the frame carries allow="tools".

The pattern is the same in all three: your product, not your markup, becomes the tool surface. Agents can discover what is registered on the current page, filter and sort tools, and call your tools directly. What agents can invoke is exactly what you registered and nothing else, and every call runs visibly in the tab, so the person watching sees what was done in their name. What that looks like by industry.

So: real, early, and available across Chrome and Edge behind flags rather than switched on for everyone. The entry point moved from navigator.modelContext to document.modelContext in July 2026 and broke every early adopter, which is a fair measure of how settled the surface is. The vendor’s own claim is that WebMCP offers higher accuracy for task completion than actuation does, and that it can be added as a progressive enhancement; both look fair. Register three read-only tools behind a feature check and you have spent a day. Rebuild a product around an unratified draft and you have made a different bet. Enabling it locally.

Chrome documents a Model Context Tool Inspector extension. Install it and you have tools to inspect what a page registers, call them by hand from natural language, and confirm the browser parses your arguments the way your code expects. It is the quickest way to find out whether any of it actually does anything on your site yet, and it costs nothing to try.

The WebMCP proposal did not appear from nowhere. The explainer on GitHub credits Alex Nahas and Jason McGhee for the implementation experience behind it, and the MCP-B project that came out of that work still ships the polyfill most teams use to put document.modelContext into browsers that do not have it. The polyfill and the React bindings.