WebMCP, explained: your website hands the AI a menu of buttons

There is a new browser feature called WebMCP, and most of what's written about it is either breathless or impenetrable. This is the plain version — what it is, what it's actually made of on a page, and why, if you run a site, the interesting question isn't "should I add it" but "can I add it, and what do I do if I can't." If you want the deep, citation-heavy state of the spec, the governance, and the security research, that's the companion teardown. This piece is the one you can hand to someone non-technical.

The one-sentence version

WebMCP lets a website hand an AI agent a menu of buttons it can press — instead of the AI having to squint at the screen and guess where to click.

That's the whole idea. Today, when an AI assistant "uses" a website for you — books a trip, adds something to a cart — it works like a tourist who doesn't speak the language: it looks at the page, guesses which box is the date field, tries to click the button, and often fumbles, because it's reading the screen the way a human would, just clumsily. WebMCP is the site handing that tourist a clean phrasebook: "say search_trips to search; say book_trip with a date and a name to book." Now the agent doesn't guess — it asks for what it wants, and the page does it.

So what is it made of — is it a file?

The surprising answer: WebMCP is mostly not a separate file. It's a little bit of code added inside the pages you already have. There are two ways to add it.

Way 1 — tag a form you already have (declarative)

You take a normal HTML form and add a couple of attributes. No new file — you're just labelling markup that's already there:

<form toolname="book_trip"
      tooldescription="Book a wilderness trip in Lapland">
  <input name="trip_id" required>
  <input name="start_date" type="date" required>
  <button type="submit">Book</button>
</form>

The toolname and tooldescription attributes turn a form the humans already use into a tool the AI can call. (Leave off the auto-submit flag and the browser fills the form but waits for a human to click the final button — human-in-the-loop by default, which for anything that spends money or stores personal data is exactly what you want.)

Way 2 — a few lines of JavaScript (imperative)

For anything more complex than a form, you register a tool in JavaScript. This lives in a .js file — one you already load, or a small new one:

document.modelContext.registerTool({
  name: "search_trips",
  description: "Search Lapland wilderness trips",
  inputSchema: { /* what info the tool needs */ },
  async execute(args) {
    const res = await fetch('/api/trips?' + new URLSearchParams(args));
    return { content: [{ type: "text", text: await res.text() }] };
  }
});

The only genuinely separate file in the neighbourhood is llms.txt — a plain-text summary at your site root — and that's a "be findable" nice-to-have, not WebMCP itself. Everything else is either code inside your pages, one permission line in your server config (Permissions-Policy: tools=(self)), and — during the current experiment — a token Google gives you to switch the feature on for your domain.

So when you explain it to someone: WebMCP isn't a file you drop in. It's a few tags on the pages you already have, plus one small permission line. Your normal HTML and JavaScript become the AI's menu.

The catch nobody puts on the slide: the page has to render first

Here's the part that connects WebMCP to what I actually do for a living. An AI agent can only press the buttons on a page it can first see. And "see" is doing a lot of work.

There are three layers stacking up here, and they are often confused:

Layer 1 — read. The AI crawlers that feed ChatGPT, Claude, and Perplexity fetch your HTML and never run your JavaScript. If your site is a client-side-rendered single-page app, they get a blank shell. This is the problem PrerenderProxy exists for.

Layer 2 — navigate. The newer browser agents (Gemini in Chrome, Perplexity's Comet) do run JavaScript, but they read the page through its accessibility tree — the same structure a screen reader uses. If your app paints a blank <div> on first load and shuffles the layout while it hydrates, that tree is empty or unstable exactly when the agent looks.

Layer 3 — act. This is WebMCP. And a WebMCP tool is registered in the page. If the page hasn't rendered — if the DOM is a blank shell or still thrashing — the tool the agent needs isn't there yet.

So the uncomfortable, and slightly self-serving, truth is this: the agentic web makes rendering more necessary, not less. Every fancy "act" capability sits on a page that first has to be readable. Most sites are still quietly broken at layer 1. Bolting a tool menu onto a page an agent can't read is putting a menu board on a drive-through with no speaker.

The rigid-CMS problem — and where PrerenderProxy comes in

Now the practical bit. Both ways of adding WebMCP assume you can change your pages: add custom attributes like tooldescription to your forms, or ship a <script> that calls document.modelContext.registerTool().

A lot of the web can't do either. If you're on a locked-down commerce platform, a marketing-team CMS, an old template system, or a heavily-abstracted framework where the forms are generated for you, "just add an attribute to the <form>" isn't a thing you can do. You don't own the markup. You can't drop in arbitrary JavaScript. The maintainer of Angular has raised exactly this on the spec tracker — the declarative form approach doesn't fit JavaScript-driven forms, which is most of the modern web.

This is the same shape of problem PrerenderProxy already solves for other machine-readable metadata. When a CMS can't emit Product schema, or ships broken canonicals, or answers 200-OK on pages that should be 404s, we fix it at the edge — in the rendered HTML, on the way to the bot, without touching the origin. Injecting a WebMCP tool declaration is the same move on a new surface.

So here is what we're building toward, said plainly:

If your platform can add the attributes natively, wonderful — do that, you don't need us for it. The point of a prerender layer has always been the long tail of sites that can't change their own markup on demand. WebMCP just adds a new reason that tail exists.

One honest caution before you get excited

WebMCP is early. As of mid-2026 it's a Chrome origin trial, not a finished standard; it ships in one browser; Apple's WebKit has formally opposed it; and — the part that matters most — Google's own agent doesn't consume WebMCP tools yet ("coming soon" since Google I/O). You can publish tools today and there is no first-party agent reliably calling them. So: worth understanding, worth prototyping, absolutely not worth betting a roadmap on this quarter. I wrote the full, sourced state of it here — the spec's own TODOs, the one real attack paper, the honest good and bad.

What's not speculative is the layer underneath. Agents that can't read your page can't act on it, and most sites are still failing that test today. Fix the reading first. The menu of buttons is only worth printing once the room has a door.

Keep reading: WebMCP, examined — the deep teardown · The strange afterlife of dynamic rendering · When the CMS can't ship it, the edge can