Right now, when an AI agent visits your website, it behaves like a slightly lost first-time visitor. It looks at the screen. It guesses which thing is the “Add to cart” button. It clicks, waits, looks again. It’s slow, it breaks the moment you change your layout, and it burns a pile of tokens reading your entire page just to find one form.
Google and Microsoft think there’s a better way — and on May 19, at Google I/O, they shipped the first real public test of it. It’s called WebMCP, and it’s now in an origin trial in Chrome 149.
If you own a website — a shop, a booking page, a SaaS app, even a contact form — you’re going to keep hearing this word. So here’s the honest question, and an honest answer: should you actually wire your site up for it right now?
What WebMCP actually is
WebMCP — it stands for Web Model Context Protocol — lets your website hand an AI agent a set of tools, instead of forcing the agent to reverse-engineer your site by staring at it.
Picture the difference. In one version, a customer walks into your shop and has to wander every aisle, read every sign, and guess where things live. In the other, you hand them a menu: here’s what we do, here’s how to order it. WebMCP is the menu.
In plainer technical terms: your site declares a list of tools — named actions like search_flights, apply_coupon, or checkout, each with a short description and a defined set of inputs. When an AI agent — say, Gemini built into Chrome — wants to do something on your site, it calls the tool directly. No screenshot. No guessing which <div> is the button. No scraping.
That fixes three real problems with how agents use the web today. They’re fragile — a small CSS change breaks the whole flow. They’re token-hungry — sending full-page snapshots to the model costs thousands of tokens per step. And they’re unreliable — the model misreads a label or a hidden field and does the wrong thing. WebMCP swaps all of that for a stable, named contract. Early numbers from Chrome’s testing put the token saving somewhere around 90%.
Two facts to anchor this before we go further.
It’s brand new, and officially experimental. WebMCP is a draft from a W3C community group — that’s the early, exploratory end of how a web standard gets made, not the finished-and-blessed end. The Chrome 149 release is an “origin trial,” which means Google is letting real sites switch it on to test it, send feedback, and — almost certainly — change it.
It’s a Google-and-Microsoft project. Both companies are building it together, which is a genuinely good sign for it sticking around. But — and this matters — Mozilla, which makes Firefox, and Apple, which makes Safari, have raised objections and haven’t signed on. For now, this is a Chrome thing.
The two ways to add it
There are two routes into WebMCP, and the effort gap between them is enormous.
The easy way: annotate a form
If your site already has HTML forms — a search box, a contact form, a checkout — you can turn one into a WebMCP tool by adding two attributes to the <form> tag: a toolname and a tooldescription. Optionally, a one-line toolparamdescription on each field. That’s it. No JavaScript.
<form toolname="search-cars" tooldescription="Search car make and model">
<input name="make" toolparamdescription="The make, e.g. BMW or Ford" required>
<input name="model" toolparamdescription="The model, e.g. 330i or F-150" required>
</form>
The browser reads the form, works out its fields, and exposes the whole thing to agents as a tool. For a simple, well-built form, this really is a few-minutes job. As one developer testing it summed it up: one HTML annotation, and then “no screenshot, no DOM parsing, no pixel clicking.”
The hard way: write the tools in code
The other route is the imperative API — navigator.modelContext — where you register tools in JavaScript. You name the tool, define its inputs as a schema, and write the function that runs when an agent calls it.
This is more work, and it’s the route you need for anything that isn’t a plain form: a multi-step flow, a tool that pulls live data, an action with real business logic behind it. For a small app with one or two important flows, that’s an afternoon-to-a-couple-of-days job. For a big, complicated web app, mapping every action into a clean, safe tool catalog is a multi-week project. Be honest with yourself about which one you’re looking at.
The case for now — and the case for waiting
The case for doing it now is mostly about being early. Expedia, Shopify, and Booking.com were already demoing WebMCP integrations at Google I/O. Google is heavily hinting that “works well with AI agents” is about to become something your site gets judged on — the way “works well on a phone” went from nice-to-have to non-negotiable a decade ago. Wiring up a couple of key forms now is cheap insurance, and you learn the thing before your competitors do.
The case for waiting is just as real. It’s an origin trial — the spec can shift under you, and the developers building early integrations are already pestering Google with exactly that worry. It’s Chrome-only, so most of your visitors can’t use it yet. And it’s genuinely experimental: more than one early implementer reported getting “stuck on async patterns” and unsure how to handle the edge cases.
So here’s the rule of thumb. If adding it is a few-minutes form annotation, the downside is basically zero — do it. If it’s a multi-week engineering project, wait until the spec settles and a second browser commits.
What this means for you
If you run an online shop or a booking site: This is the category WebMCP was built for. Multi-step flows — search, pick, pay; choose a date, book the room — are exactly where blind agent-clicking fails most. Expedia and Shopify are testing it for a reason. Annotate your search and checkout forms. Small job, real upside.
If you run a SaaS app or a dashboard: You probably have a lot of actions worth exposing — but doing it properly is the multi-week version, not the afternoon one. Start with your highest-value forms (sign-up, your main “create” action), do those declaratively, and treat the full tool catalog as a later project once the spec firms up.
If you run a static marketing or content site: Mostly skip it for now. WebMCP makes actions callable, and a brochure site doesn’t have many. The one exception: a lead form or a contact form. Annotating that single form so an agent can submit an inquiry is worth five minutes.
If you’re a freelance web developer: Learn it now, even though no client is asking yet. This is a small, learnable skill that’s about to land on client briefs. Being the developer who already knows how to make a site “agent-ready” is worth more than the line of work itself.
If you run your site on Squarespace, Wix, or Shopify: You don’t do anything yet. You wait for your platform to add WebMCP as a setting — and since Shopify is already testing it, that won’t be a long wait. Your only job right now is to recognize the word when your site builder announces support.
What WebMCP can’t do (yet)
It can’t reach non-Chrome visitors. Firefox and Safari haven’t committed. Most of the world isn’t on Chrome 149. WebMCP is an addition for the agents that support it — never a replacement for a site that works the normal way.
It isn’t finished. Origin trial means the API can still change — method names, how schemas work, all of it. Anything you build today, you may have to revisit. Early builders are openly asking Google what’s stable and what isn’t.
It doesn’t make your site smart. WebMCP just exposes your tools. The intelligence is the agent’s. A vague tooldescription will confuse an agent exactly the way a badly labeled button confuses a person — garbage in, garbage out.
It doesn’t handle security for you. Letting an AI call your checkout function is precisely as risky as it sounds if you’re careless about it. The spec gives you ways to require explicit user confirmation for sensitive actions — but you have to actually use them. One developer flatly called the whole concept “a security nightmare” if rushed. He’s not entirely wrong.
It won’t bring you traffic. This is the big misread. WebMCP makes your site easier for an agent to operate once it’s already there. It does nothing to make an agent choose you in the first place. Getting recommended is still about being visible, trusted, and well-reviewed — a completely separate job.
The bottom line
WebMCP is a real shift, and the direction it points is clear: the web is slowly being rebuilt so AI agents can actually use it, instead of squinting at it. A year from now, “is your site agent-ready?” will be an ordinary question.
But “the direction is clear” and “you must act today” are not the same sentence. The smart move right now is small and cheap. Got an important form — a checkout, a booking, a lead capture? Spend the few minutes to annotate it and watch what happens. If wiring up your site means a serious engineering project, put it on the roadmap and let the spec stop moving first.
Early, not reckless. That’s the whole play.
If you want to understand the AI agents this is all being built for — what they are, what they can really do, how to work with them — our AI Fundamentals course is a calm, free place to start. And if you’re a developer who wants to build for this new agent-driven web, Claude Code Mastery and Prompt Engineering for Developers go deep on building alongside AI.
Sources
- Chrome for Developers — WebMCP
- W3C Web Machine Learning Community Group — WebMCP
- WebMCP — Declarative API explainer
- PPC Land — Chrome 149 origin trial puts WebMCP in developers’ hands
- Scalekit — WebMCP: the missing bridge between AI agents and the web
- DataCamp — WebMCP Tutorial: Building Agent-Ready Websites
