WebMCP: How to Make Your Website Usable by AI Agents

The problem WebMCP is trying to solve

Until now, an AI agent operating a website has been doing something close to screen-scraping. It reads the DOM, forms a hypothesis about which element is the search box and which button submits it, clicks, and hopes. It is slow, expensive in tokens, and brittle — a class name change or a redesigned filter panel breaks it silently.

WebMCP proposes the obvious fix: let the site say what its own functionality is. Rather than an agent inferring that a button probably books an appointment, the page declares a tool called book_appointment, describes it, and specifies exactly what parameters it takes. The agent calls the function instead of pretending to be a mouse.

What actually landed in Chrome 149

WebMCP entered an origin trial in Chrome 149, with DevTools support. An origin trial means it is testable on real origins with a token but is not a finished, shipped standard, and the API can still change. The work is being developed in the open through the Web Machine Learning group.

There are two ways to declare tools. A declarative approach annotates existing HTML forms, which is the low-effort path for anything already form-shaped. An imperative JavaScript API covers everything else: navigation, state management, and arbitrary functions.

The WebMCP API, concretely

The imperative form registers a tool on document.modelContext. A tool is a name, a description written for a model to read, a JSON Schema for its inputs, and an async handler:

await document.modelContext.registerTool({
  name: 'search_inventory',
  description: 'Search available stock by category and size.',
  inputSchema: {
    type: 'object',
    properties: {
      category: { type: 'string' },
      size: { type: 'string', enum: ['s', 'm', 'l', 'xl'] },
    },
    required: ['category'],
  },
  execute: async ({ category, size }) => {
    const results = await runSearch(category, size);
    return summarise(results);
  },
});

The description field deserves more attention than it usually gets. It is prompt text — the model decides whether to call your tool based on it. A vague description means your tool never gets used; an over-broad one means it gets called for the wrong tasks. Write it the way you would write a good function docstring for a colleague who cannot see the code.

The execute handler also receives an AbortSignal as a second argument, so long-running operations can be cancelled cleanly when the agent changes course.

The security part you cannot skip

Exposing internal site functions to a language model is a genuine widening of your attack surface, and it should be treated with the seriousness of adding a public API — because that is what it is.

The specific threat is indirect prompt injection. An agent operating your page may also be reading content you do not control: user reviews, a syndicated feed, an embedded third-party widget. Text in any of those can attempt to instruct the agent to call your tools in ways the user never asked for.

Chrome puts structural guards in place — documents must be origin-isolated with document.domain disabled, and the API is gated behind a tools permissions policy defaulting to self, so a cross-origin iframe needs an explicit allow="tools". Those guards constrain who can register tools. They do not validate what your tools do.

The practical rules: treat every tool invocation as untrusted input and validate it server-side exactly as you would a public endpoint; never expose destructive actions — deletions, cancellations, payments — without a human confirmation step outside the agent's control; scope tools narrowly rather than shipping one do_anything tool; and rate-limit as you would any API.

Should you adopt it yet?

For most businesses, honestly, no. It is an origin trial, agent traffic that would exercise it is still a small fraction of sessions, and the API surface may shift before it ships. Building against it now is a bet on timing, not a safe default.

It is worth prototyping if your product is genuinely task-shaped — a booking system, a multi-criteria catalogue search, a configurator, a dashboard with filters. Those are the cases where an agent completing a task in one call rather than twelve speculative clicks is a real difference, and where being early could mean being the option agents can actually operate.

The unglamorous work that beats it

Here is the part worth sitting with: almost everything that makes a site WebMCP-ready is something you should have done anyway. Semantic HTML. Real form labels. Server-rendered content rather than a client-side shell. Stable, meaningful URLs. Accurate structured data.

An agent operating a well-built, accessible site already does far better than one fighting a div soup of unlabelled controls — which is the same reason those choices help screen readers, covered in our piece on accessibility compliance, and the same reason they help search, covered in how code quality affects rankings.

WebMCP raises the ceiling for sites that are already well built. It does nothing for a site that is not. If you are choosing where to spend a sprint, spend it on the floor first — and if you want a read on where your site sits, talk to us.