WebMCP: Let Agents Use Your Website (2026 Guide)

A browser agent trying to do something on your site today has one option: read the rendered page and drive it like a person — find the button, click it, hope the markup has not moved. WebMCP replaces the guessing with a declaration. The page says "here are the things you can do here, here is what each one needs, here is what it returns", and the agent calls them.

It is a W3C Web Machine Learning Community Group draft, authored jointly by Google and Microsoft. The shape is deliberately the same as an MCP tool — a name, a description, a JSON schema and a handler — which is why the two are named alike. The difference is where the tool lives: an MCP server runs on a machine you operate, a WebMCP tool runs in the page.

That difference matters for anything behind a login. The agent inherits the session the browser already has, so a tool can act as the signed-in user without you issuing an API credential to a third party.

A tool is a name, a description, an input schema and a function. The description is doing the real work here — it is what an agent matches against a user request, so write it the way someone would ask.

const mc = document.modelContext ?? navigator.modelContext

if (mc) {
  mc.registerTool({
    name: 'search_products',
    description: 'Search this store's catalogue by keyword and return matching products with prices.',
    inputSchema: {
      type: 'object',
      properties: { query: { type: 'string', description: 'What to search for' } },
      required: ['query'],
    },
    async execute({ query }) {
      const res = await fetch('/api/search?q=' + encodeURIComponent(query))
      const products = await res.json()
      return { content: [{ type: 'text', text: JSON.stringify(products) }] }
    },
  })
}

Guard the whole block on the object existing. Outside the origin trial it is `undefined`, and an unguarded `registerTool()` throws on every page load for every visitor — including the ~100% of them who are not agents.

WebMCP is not generally available. It ships behind a Chrome origin trial, which means the page must serve a token for your origin or the API is simply not there.

Register at Chrome Origin Trials, then put the token in the page head:

<meta http-equiv="origin-trial" content="YOUR_TOKEN_HERE">

There is one mechanism worth knowing about: third-party origin trials. The token can be delivered by an external script loaded from the origin that registered it, which then injects the meta tag into the host page. That is what lets a tag you already embed switch WebMCP on for a site whose own team never touched the code.

This is the part most write-ups leave out, so here it is plainly: almost nothing consumes WebMCP tools today.

• No mainstream agent client calls registered tools in production. Gemini in Chrome is announced as the first consumer.
• Adoption outside demos is close to zero — one survey of the space noted that checker tools now outnumber known implementations.
• The spec is a Community Group draft, not a standard. The API has already moved once, in July 2026.

None of which makes it a waste of time. Registering a handful of tools is an afternoon, the failure mode is inert rather than harmful, and the cost of being early is close to nothing. But be honest with yourself about the return: you are preparing for agents that are arriving, not serving traffic that exists.

The useful ones are the actions a visitor actually came to perform, not a mirror of your REST API. Three rules:

1. 1Describe in user language. The description is the matching surface. "Book a meeting with the sales team" beats "createCalendarEvent".
2. 2Keep them idempotent and safe. An agent may retry. Searching, checking availability and looking things up are ideal; irreversible or money-moving actions want a human confirmation step in your own UI.
3. 3Return structured text. The agent reads the result, so return the fields it needs to answer — not an opaque id.

Good candidates on a typical business site: search the catalogue or docs, check availability, get a quote, look up an order, start a booking. Bad candidates: anything that spends money, deletes data, or sends a message on the visitor's behalf without them seeing it.

Because the handler is your own JavaScript, a tool call is a normal event you can record — which makes WebMCP the first agent interaction most sites can actually count. Fire your analytics event inside the handler and you get the tool name, the arguments and the outcome.

That is worth setting up before the traffic arrives rather than after, because the interesting question is not "how many agent calls did we get this quarter" but "when did the first one land, and what did it ask for". Our own tracker fires a goal on every registered tool call for exactly this reason — see the AI crawler identifier for the adjacent problem of naming the agents that fetch your pages rather than call your tools.