What is WebMCP? The API that lets AI agents use your site

When an AI agent tries to buy something on your site today, it does a strange thing: it reads your rendered page, guesses which element is the “Add to cart” button, and clicks where it thinks that button is. It works until your layout shifts, your button is an unlabelled <div>, or your search box needs three steps. WebMCP is Google’s proposed fix: a way for your page to hand the agent a labelled set of tools it can call directly, no guessing required. This is the plain definition, both ways to add it, how it differs from MCP, and an honest read on how new it still is.

01 · The whyThe problem it solves

An agent operating your site through the raw page is doing the web equivalent of using an app by tapping pixels with its eyes closed. It infers intent from labels, roles, and position, and every ambiguity is a chance to click the wrong thing. That is fragile, and it is why the whole agentic browsing effort leans so hard on clean accessibility trees and stable layouts.

WebMCP takes a different angle: instead of making the agent interpret your interface, you declare what it can do. A tool has a name, a plain-language description, and a schema of inputs, so the agent calls searchProducts({ query: "wool socks" }) rather than hunting for your search field. You stop hoping the agent guesses right and start telling it exactly what is available.

02 · How it worksThe two ways to add it

There are two APIs, and you can mix them. The declarative one is nearly free if you already have forms.

Declarative: annotate a form. Add a few attributes to a standard HTML <form> and the browser turns it into a tool. toolname and tooldescription describe the tool; toolparamdescription explains a field.

<form toolname="supportRequest" tooldescription="Submit a request for support." action="/submit">
	<label for="firstName">First name</label>
	<input type="text" name="firstName" />

	<select name="team" required toolparamdescription="Which team this request is routed to.">
		<option value="returns">Return my purchase</option>
		<option value="shipping">Check where my package is</option>
	</select>

	<button type="submit">Submit</button>
</form>

Imperative: register a tool in JavaScript. For anything a form cannot express (navigation, reading page state, custom logic), you register a tool directly. It takes a name, a description, an inputSchema (JSON Schema), and an async execute handler.

navigator.modelContext.registerTool({
	name: 'searchProducts',
	description: 'Search the product catalog by keyword',
	inputSchema: {
		type: 'object',
		properties: { query: { type: 'string' } }
	},
	execute: async ({ query }) => searchCatalog(query)
});

The agent sees your registered tools, picks the right one for the user’s goal, supplies inputs that match your schema, and your execute function does the real work, in the user’s own session, with their own permissions.

03 · The name confusionWebMCP is not MCP

The name borrows from MCP, and people conflate them constantly. They share a core idea (give models tools) but live in completely different places.

The practical upshot: WebMCP needs no backend deployment and inherits the logged-in context of whoever is browsing, which is exactly what makes it suited to on-page actions like checkout or booking. It is the front-end complement to MCP, not a replacement for it.

04 · MaturityHow new this really is

Be clear-eyed about the stage. WebMCP shipped as a Chrome 149 origin trial in May 2026. That means it is experimental and opt-in: you register for the trial and serve a token, or flip chrome://flags/#enable-webmcp-testing for local development. It is being incubated in the W3C Web Machine Learning community group, with Google and Microsoft involved, and an actual W3C recommendation is years, not months, away. Expect Chrome-first support and an API that can still shift under you.

05 · The honest callShould a small product adopt it yet?

It depends entirely on whether AI agents are a real channel for you. The asymmetry is the thing to weigh: adding WebMCP to one or two high-value flows is cheap, especially the declarative form path, and it makes those flows dramatically more reliable for any agent that supports it. Adding it everywhere, chasing a spec that is still moving, for an agent audience that is still small, is premature.

So: if you sell something, or expose tools an agent would genuinely use, declare your one or two most important actions (search, add-to-cart, book) now, as low-cost insurance. Otherwise, do the cheaper, dual-purpose agent-readiness work first, real server-rendered content, a clean accessibility tree, an llms.txt, and watch WebMCP mature. That “build the floor before the ceiling” order is the same one the agent readiness guide argues for, and WebMCP is squarely a ceiling item.