What is WebMCP?

The problem it was built to solve

An AI agent that acts inside a browser today works the way a person does, only blind. It reads the page, guesses which element is the search box, clicks what looks like a button, and hopes the form submitted. That is screen scraping with better manners. It breaks when a site changes its layout, it misreads a modal for a menu, and it cannot tell a "Delete account" button from a "Save" button except by reading the label.

WebMCP flips the relationship. Instead of the agent guessing at the interface, the site publishes a list of things it can do, each with a name, a plain-English description and a schema saying what information it needs. The agent picks one and calls it. The site runs its own code and returns a result.

The name is a nod to MCP, the Model Context Protocol, which does the same job for servers. MCP needs a server you deploy and maintain. WebMCP needs nothing but the page the visitor is already on: the tools are defined and executed in the browser tab, so the website is its own server.

How a site actually declares a tool

There are two ways, and one of them is not programming at all.

The declarative way: annotate a form

An ordinary HTML form becomes a tool with three attributes. The browser reads the fields and works out the parameters on its own.

<form toolname="book-session"
      tooldescription="Book a free 90 minute working meeting"
      toolautosubmit>
  <input type="text" name="name">
  <input type="email" name="email">
  <textarea name="message"></textarea>
  <button type="submit">Send</button>
</form>

toolname gives it an identifier, tooldescription tells the agent what it is for, and toolautosubmit says the browser may submit on the agent's behalf rather than waiting for a human to press the button. No JavaScript at all.

The imperative way: register it in code

Anything that is not a form is registered by hand, on document.modelContext:

document.modelContext.registerTool({
  name: 'get-pricing',
  description: 'Return the published rates and what each one includes',
  inputSchema: { type: 'object', properties: {} },
  async execute() {
    return { hourly: 265, currency: 'USD', firstMonth: 150 };
  }
});

The execute callback gets the agent's arguments already parsed, can take an AbortSignal so a cancelled request stops work, and returns anything that survives JSON. The browser serialises the answer and hands it back.

What the standard actually specifies

The draft is more careful than the summaries suggest. Worth knowing:

• Tools are same-origin by default. A page's tools are visible to that origin and to the browser's own agent. A cross-origin iframe has to be granted the tools permission policy feature, and a tool can name exactly which origins may call it with an exposedTo list.
• Tools can be labelled. readOnlyHint says the tool changes nothing. consequentialHint says it does something in the real world. untrustedContentHint says the output contains text the site did not write. An agent is meant to treat these differently, and a careful one will ask a human before anything marked consequential.
• The page is told what is happening. Events fire when a tool starts, when it is cancelled and when the tool list changes, so the interface can show the visitor that an agent is acting.
• Tools die with the document. Navigate away and any running call is cancelled.

What it is not

This is the part most write-ups get wrong, and it matters if you are thinking about it for marketing reasons.

It is not search visibility. Tools are not discoverable by crawlers. There is no registry, no directory, and nothing in a sitemap. A browser or an agent only learns a site has tools by visiting it. Publishing tools will not make you appear in ChatGPT's answers or in Google's AI Overviews, and it will not bring you traffic. That job belongs to ordinary content, structured data, a clean markdown version of your pages and an llms.txt.

It is not an API for the public. It runs in a visitor's own browser tab, in their own session, with whatever they are logged in as. Chrome's own documentation says headless browsing is not fully supported and that the design assumes a human is in the loop.

It is not finished. It is a draft specification in an origin trial. Without a token from Google served by the page, document.modelContext does not exist for an ordinary Chrome visitor. The trial covers Chrome 149 to 156 and the tokens expire on 16 November 2026. No other browser ships it.

The risk nobody should skip

A tool description is text that an AI reads and acts on. That makes it an attack surface. If a page renders something a stranger wrote, a review, a comment, a shared document, and that text finds its way into a tool's description or its return value, the agent may read it as an instruction. The specification names prompt injection as the central risk and asks sites to mark untrusted output as such.

Practically: never let a tool do something you would not let an unattended script do. Do not expose anything that spends money, sends a message, deletes data or changes account settings without a human pressing something. Mark those consequentialHint if you expose them at all.

Should a small company do anything about it today?

For most, not yet, and not for the reason they think. The audience is close to zero: a Chrome user, on a trial, with an agent that supports it. Nobody is getting leads from this in 2026.

There are two honest reasons to do it anyway.

The first is that it is cheap. Turning an existing contact form into a tool is three attributes. Adding a handful of read-only tools that answer questions about your services and prices is an afternoon.

The second is the real one: it is proof. If you sell AI work, a site that is itself agent-callable is a live demonstration that costs a day and nothing per month. It is also a straightforward piece of content, which is more than most of the field has managed.

The thing to avoid is treating it as a traffic channel. It is not one, and anyone selling it as SEO has not read the specification.