Back to blog
AIGEOSEO

WebMCP, Explained: How to Let AI Agents Actually Use Your Website

4 min read

Right now, when an AI agent visits a website to complete a task, it is essentially pretending to be a clumsy human: it reads the HTML, guesses which button means "submit," clicks it, waits, and hopes nothing broke. This process even has a name — actuation — simulating manual mouse clicks and text input as though the agent were a person. It works, sometimes. It is also slow, brittle, and gets more unreliable the more an interface changes.

WebMCP is a proposed web standard that fixes this by letting a site declare its own tools. Instead of an agent guessing what a form does, the page tells it directly: here is a submitContactForm tool, here are exactly the fields it needs, here is what it returns. No guessing, no brittle selectors, no silent failures.

What WebMCP actually is

WebMCP offers two ways to expose a tool. The imperative API is plain JavaScript — call document.modelContext.registerTool() with a name, a description, a JSON Schema for the inputs, and an execute function. The declarative API is HTML-only — add a few attributes (toolname, tooldescription) to an existing <form>, and the browser converts the form structure into a tool schema automatically.

Either way, the tool still runs in the browser, on the page, using the site's existing JavaScript. An agent invoking it does not bypass validation or the UI — it fills in fields and submits through the same code path a human would, visibly, so the site's behavior and design stay exactly as built.

Why this matters for AI search visibility

Most GEO (generative engine optimization) advice focuses on being readable to AI — clear structure, good headings, llms.txt, crawler-friendly robots.txt. That is necessary, but it only gets a site cited. WebMCP is the next layer: being usable by AI. An agent that can read about a company's services is one thing; an agent that can actually book a call, request a quote, or file a support ticket on a visitor's behalf is a different kind of visibility entirely — the kind that converts.

What you can build with it

Some concrete examples:

  • Lead-gen forms — a contact form or an audit-request form becomes a single tool an agent can fill and submit on a visitor's behalf.
  • Support flows — a run_diagnostics or submit_ticket tool skips the nested-menu hunt a human, or a confused agent, would otherwise have to do.
  • Complex bookings — multi-step flows like date pickers or multi-passenger travel search, which agents today struggle to actuate reliably through raw clicking.

Sensitive actions — anything involving payment or an irreversible change — should still route through an explicit confirmation step. WebMCP does not remove that responsibility; it makes the rest of the interaction reliable.

How to start

WebMCP is available today as a Chrome flag for local testing (chrome://flags/#enable-webmcp-testing) and, from Chrome 149, via an origin trial for production use. It also requires an origin-isolated document and a tools Permissions-Policy directive — both easy one-line additions on top of existing security headers.

Is your site ready?

  • At least one real, single-step action a visitor completes — a form, a search, a booking — not just static content.
  • That action already has clean client-side validation to reuse, rather than a second, parallel validation path built just for agents.
  • Security headers centralized somewhere a Permissions-Policy: tools=(self) directive can be added.
  • A willingness to treat this as progressive enhancement — registering only when the API exists, and doing nothing otherwise.

Frequently asked questions

Does WebMCP replace normal SEO or GEO work? No — it is additive. Crawlability, structured data, and clear content still determine whether an AI even finds and understands a page. WebMCP is about what happens after that, when an agent wants to act.

Will this break a site for regular visitors? No, if implemented correctly. The API is feature-detected (if (document.modelContext)), so on every browser without it, the registration code simply never runs.

Is this stable enough to ship today? It is an active origin trial, not a finished standard — expect the API surface to keep changing. Treat an early implementation as an experiment, not a dependency core business logic relies on.


Weighing whether a site should expose tools like this, or want a broader look at how AI-discoverable it actually is? This piece on showing up in AI search is a good next read, or see how I can help. Questions about implementing WebMCP on your own stack? Get in touch.

Related posts