WebMCP is a proposed web standard that lets a website declare its capabilities as tools an AI agent can call directly, instead of guessing its way through the page. Google announced it with an origin trial in Chrome, the industry immediately produced a wave of commentary, and most of it was written by people who had not implemented it. So we implemented it — on our own site, before recommending it to anyone else. This is what we learned, including the parts the documentation doesn’t mention.
The problem it solves
When an AI agent uses a website today, it does what Google calls actuation: it reads the page and simulates a human — moving a cursor, clicking buttons, typing into fields. This works about as well as you would expect. Every custom widget is a puzzle, every layout change breaks yesterday’s solution, and the agent can never be quite sure the thing it clicked did the thing it wanted.
WebMCP replaces guessing with declaring. A page registers named tools — book_appointment, filter_results, get_services — each with a typed schema saying exactly what inputs it takes. An agent working in that browser discovers the tools, calls them with structured data, and gets structured answers back. The site stops being a picture an agent squints at and becomes an interface it can use.
What we actually built
Our site now registers four tools. Every page carries two read-only ones: get_services and get_case_studies, which return what we do and what we’ve done, generated at build time from the same content that renders the pages — so they can never drift from what a human visitor sees. The booking page adds get_available_call_times, which serves our live calendar, and book_discovery_call, which wraps our real scheduling flow.
The whole build took about a day, and none of it changed anything for human visitors. Browsers without the API pay no cost at all. That ratio — one day, zero disruption — is worth knowing, because it means the sensible question isn’t whether this is worth a big project. It isn’t a big project.
The two things that surprised us
The audit before the build taught us more than the build itself.
Our spam trap would have eaten every agent submission. Like most sites, our booking form contains a honeypot: a field humans never see, which anything automated tends to fill in. Submissions that touch it are silently discarded. That is exactly correct behavior against spam bots — and exactly wrong against a legitimate prospect’s agent trying to book a call on their behalf. The uncomfortable part is the silence: the agent believes it booked, the visitor believes they booked, and nothing happened. WebMCP resolves the conflict cleanly. The tool is the defined door for legitimate automation; the trap stays armed for everything that comes in through the wall.
Our topic dropdown was invisible. Our form’s “what is this call about?” picker is a custom-built dropdown — better-looking and more accessible for humans than a native one, and completely opaque to automation, since its value lives in a hidden field no agent could reliably set. The fix we settled on is one we’d now recommend as a pattern: the booking tool reads its list of valid topics out of the real form at page load and publishes them as constraints in its schema. One source of truth; the human interface and the agent interface cannot drift apart.
The rule we’d urge anyone to copy
Booking a call sends emails and writes to calendars, which makes it what the standard politely calls a sensitive action. Google’s guidance is that these should require user interaction, and we’d put it more strongly: an agent should never be able to complete a consequential action silently. On our site, book_discovery_call assembles everything, then stops and asks the actual human — a confirmation dialog naming the time, the name, and the email about to be sent. The agent does the typing. The person still decides.
If WebMCP adoption goes wrong anywhere, it will be sites skipping this step for conversion’s sake. Don’t.
What this doesn’t do, stated plainly
There is almost no agent traffic today. The API sits behind an origin trial; mainstream consumer agents that call WebMCP tools are not yet shipping; nobody’s analytics show a meaningful “AI agent” segment. Implementing WebMCP this quarter will not move your numbers this quarter, and anyone selling it as a traffic lever is early by at least a product cycle.
It also isn’t AI search optimization. Whether AI Overviews or ChatGPT cite you is decided by retrieval and trust — the fundamentals we covered in our guide to generative engine optimization and in how AI Overviews choose the sources they cite — not by tools on your pages. WebMCP is about the visit after the citation: when software arrives to do something. (For the prior question of how models learn who you are at all, see LLM SEO.)
So why build now? Because the standard is arriving through the browser itself, not through a vendor you can evaluate later; because the build is a day, not a quarter; and because the audit that precedes it — can an agent actually complete your most valuable action? — finds problems worth fixing regardless, as our honeypot proved.
If you run a website, in order
Now: make sure the fundamentals hold — semantic markup, structured data, and a hard look at whether your critical form is silently hostile to automation. Add an llms.txt file; it costs an hour and serves today’s AI systems, not tomorrow’s.
Soon: if your business runs on a bookable, orderable, or quotable action, plan the WebMCP version of that action — one tool, with a confirmation step — so you’re implementing from a plan when agent traffic becomes real rather than reacting to it.
Watch for: WebMCP graduating from origin trial to stable Chrome, and the first consumer agents that call site tools. Either event is the signal to ship.
We’ll keep publishing what we learn from ours as real agents start arriving. And if you’d rather someone who has already done this looked at your site, that is literally our job.
