PROTOCOLS & AGENTS

Your website is about to get a second user — and it doesn't click buttons

WebMCP turns the DOM you built for humans into a set of callable tools for AI agents. Here's what it actually changes for the way we build frontends.

For as long as the web has existed, there's been exactly one kind of visitor to design for: a person with a mouse, a keyboard, and eyes on a screen. Every button, every form, every hover state — built around that assumption.

That assumption is starting to crack. Increasingly, the thing loading your page isn't a human at all — it's an agent acting on one, trying to book the flight, compare the prices, or fill out the form on someone's behalf. And right now, it does that job the hard way: reading raw HTML, guessing at intent, and hoping the click lands where it meant to.

WebMCP is Chrome's answer to that gap — a proposed browser standard that lets a site describe, in plain structured terms, what it can do and how to ask for it.

The core idea

Instead of an agent inferring your app's capabilities from markup, your app tells it directly: here's an action, here's what it needs, here's what it returns. No scraping, no vision models squinting at screenshots, no brittle selectors that break the moment a designer ships a redesign.

today: agent → parses DOM → infers intent → clicks → hopes
with webmcp: agent → reads declared tool → calls it → gets structured result

It's a small reframe with a large consequence: the interface stops being the only contract. There's now a second, machine-readable contract sitting alongside it.

Two ways to expose a tool

1 · Register it in JavaScript

For anything dynamic — search, filtering, multi-step flows — you register a tool programmatically and hand it a schema:

// expose a booking action to any agent on the page
navigator.webMCP.registerTool({
  name: "reserveTable",
  description: "Reserves a table at the restaurant",
  inputSchema: {
    type: "object",
    properties: {
      partySize: { type: "number" },
      time: { type: "string" }
    },
    required: ["partySize", "time"]
  },
  execute: async ({ partySize, time }) => {
    return await api.reserve(partySize, time);
  }
});

The agent now knows the tool's name, its purpose, exactly what arguments it takes, and how to invoke it — all without touching a single DOM node.

2 · Tag a form and let the browser do the rest

For simpler, form-shaped actions, there's a zero-JS path — annotate the markup and the browser infers the tool for you:

<form webmcp-tool="reserve-table">
  <input name="partySize" type="number" />
  <input name="time" type="datetime-local" />
</form>

This is the part that matters for existing products: you don't need a rewrite to become agent-legible. A single attribute on a form you already have can be enough.

WebMCP is not MCP

It's easy to conflate the two because the acronym overlaps, but they sit on opposite sides of the request:

MCP

Runs server-side. Gives an agent structured access to your backend, databases, and internal systems.

WebMCP

Runs in the browser. Gives an agent structured access to what's already rendered on the page, in the user's session.

Put together, they cover the whole stack: MCP is the brain talking to your servers, WebMCP is the hands operating inside the tab that's already open and already authenticated as the user.

Where this shows up first

The obvious candidates are anywhere a person currently clicks through a multi-step flow to get a single outcome:

• Retail — search, filter, add-to-cart, apply-coupon, checkout, exposed as discrete callable steps instead of a page a bot has to click through.

• Travel — comparing fares and availability across a session without re-deriving intent from scratch on every page load.

• Internal dashboards — an ops tool that exposes generateReport() or rotateApiKey() turns a copilot from "reads your screen" into "actually operates your product."

• Support flows — cancellations, refunds, and shipment lookups an agent can execute directly instead of parsing a ticket form.

What good tool design looks like

The emerging guidance reads a lot like good API design, because it is good API design — just aimed at a different caller.

Keep tools narrow. A single manageOrder() that branches internally on ten intents is harder for an agent to reason about than five small ones — createOrder(), cancelOrder(), refundOrder() — each doing one thing.

Name for intent, not implementation. submitExpenseClaim() tells an agent what it's for. postForm3() doesn't.

Push the math into your app, not the prompt. Ask for startTime and endTime, not a pre-computed durationMinutes the caller has to derive first. Let your code do arithmetic; let the agent supply intent.

Assume retries. Agents fail and re-call. Any tool that changes state needs to be safe to invoke twice — idempotency keys, not "hope it only runs once."

The part that should worry you a little

Handing an agent a callable action is also handing it a callable action. If a page can register a tool, a malicious script on that page — or a compromised third-party widget — can register one too, and an unwary agent won't necessarily know the difference between a legitimate checkout tool and one quietly rerouting funds.

Treat every registered tool the way you'd treat a public API endpoint, not a UI affordance: verify origin, log registrations, scope what each tool is actually permitted to do, and require explicit confirmation before anything irreversible — payments, deletions, account changes.

The shift underneath all of this

For twenty-odd years, "frontend" has meant "the layer humans look at." WebMCP quietly adds a second audience to that definition. The components you ship now need to make sense to a person's eyes and to a schema an agent will call — which means naming things clearly, keeping actions small, and treating your UI's behavior as something worth documenting as precisely as an API.

It's early. The spec is still a proposal, browser support is partial, and most teams have never written a line of code with an agent as the intended caller. But the same was true of REST once, and of WebSockets. The pattern with standards like this is always the same: quiet for a year, then suddenly the thing everyone assumes was always there.

The useful question to sit with isn't whether WebMCP specifically wins. It's this: which parts of what you're building right now would you want an agent to be able to call directly — and which parts would terrify you if it could?

Written for developers thinking about what "frontend" means once agents are a second class of user.