Make Your Website Agent-Ready: What WebMCP Is and How to Prepare

Automated traffic passed human traffic on the open web for the first time in 2024, at roughly 51%, according to Imperva's 2025 Bad Bot Report. Read that stat alone and it sounds like the internet quietly filled up with helpful shopping assistants. It did not. That 51% is overwhelmingly bad bots: scrapers, credential-stuffing attempts, content thieves. The genuinely helpful kind of automated visitor, an AI agent booking an appointment or filling out a contact form on a person's behalf, is a newer and much smaller slice, arriving on top of a bot landscape that was already mostly adversarial.

That distinction matters, because it is exactly the slice WebMCP is built for. We spend most of our working hours making sure client sites get found and cited correctly by AI search systems (Google AI Mode, ChatGPT, Perplexity), so a browser standard aimed at what happens after an agent lands on your page is the natural next chapter of that problem. This post is a plain-language walkthrough of what WebMCP is, why it changes how we think about a site's conversion flows, and what a business or nonprofit owner can reasonably do about it today, while it is still experimental. For the more personal, philosophical read, here is my take on what an agent-first web means. This one stays practical.

What WebMCP actually is

WebMCP is a proposed open web standard, announced at Google I/O 2026 on May 19, 2026, backed by both Google and Microsoft and under discussion at the W3C. The core idea: a website can expose a set of typed "tools" (a name, a natural-language description, and a JSON schema describing the inputs and outputs) that an in-browser AI agent can discover and call directly. Instead of an agent screenshotting your page, guessing where the "Book Now" button sits, clicking it, waiting, and screenshotting again to check what happened, the agent reads your tool list once and calls bookAppointment(date, service, contactInfo) the way a developer calls an API. The response comes back as structured data, not a picture the agent has to reinterpret.

The name nods to Model Context Protocol (MCP), which originated with Anthropic in late 2024 to connect AI models to external tools and data sources, generally at the application or server level. WebMCP brings that same tool-calling idea down to the browser and the website itself, so any compatible in-browser agent, not just one vendor's assistant, can discover and use the tools a page exposes.

There are two ways a site can implement it. The Declarative API adds HTML attributes to forms you likely already have, so a standard booking or signup form can become agent-callable with markup changes rather than a rewrite. The Imperative API is JavaScript for more dynamic interactions, cases where the "tool" is not a simple form submit but a multi-step or conditional flow. Most business sites will lean on the declarative side first, because most of what an agent needs to do on a small business or nonprofit site (sign up, book, ask a question, buy something) is already a form.

Why the old way is slow, and why that is the whole argument

The case for WebMCP is easiest to see side by side with what an agent has to do without it. Early figures reported by Google and covered in the trade press put the old screenshot-and-click method at roughly 5 to 10 seconds per action with a 15 to 20% error rate, since the agent is reverse-engineering your UI on every step. The same coverage puts a WebMCP-style direct tool call at roughly 1 to 2 seconds per action with near-zero errors, because the agent calls a defined function instead of guessing. Treat those as early, vendor-reported figures, not a guarantee, but the mechanism behind the gap is straightforward: structured calls fail less than pixel-guessing.

For a business owner, the practical read is not "agents are about to flood my site." It is that when an agent does show up on behalf of a real customer, the difference between it completing a booking and it giving up on your contact form is largely a function of whether your site is guessable or declared. A slow, error-prone agent visit on an unclear form does not just fail quietly, it can fail the exact customer who would have converted if a human had filled it in.

What we already see when we audit a site's conversion flow

We do not have first-hand WebMCP results yet. Nobody serious does; it has been in origin trial for a matter of months. What we do have is a lot of hours auditing conversion flows for AI visibility work, and the pattern we see with clients holds up here too: the sites that struggle most with any automated interaction, search crawler, AI citation engine, or eventually an agent, are the ones where the "form" is really a JavaScript widget with no labels and no semantic structure. A healthcare organization we work with had a contact flow built entirely in unlabeled divs; when we rebuilt it with proper form elements and labels for an unrelated accessibility and AEO pass, both screen readers and AI crawlers immediately handled it better. [PLACEHOLDER: Dahlia adds the real before/after detail from that project, results may vary.] Whatever makes a flow legible to assistive technology and today's AI crawlers is the same groundwork WebMCP tooling will build on. You are not preparing for a hypothetical; you are finishing work that already pays off.

In nonprofit client work, the flows that break most often are donation and event-registration forms with conditional logic, a field that only appears after another is filled. That is exactly the case the Imperative API exists for. [PLACEHOLDER: Dahlia adds a specific nonprofit conditional-form example if available, anonymized, results may vary.] None of this means writing WebMCP code today. It means the audit you would run to prepare is the same audit that improves the flow for humans and today's crawlers right now.

How to prepare, without building anything yet

Because WebMCP is experimental, the right move for almost every business or nonprofit site is preparation, not implementation. Four things are worth doing this quarter.

None of this requires a developer sprint. It requires the same audit discipline we already bring to AEO and GEO work: walk the site as if you were not a person, and see where it breaks.

Key takeaways

• WebMCP is a proposed standard (Google I/O 2026, backed by Google and Microsoft) in origin trials in Chrome 149. It is experimental, not stable or widespread.
• It lets sites expose typed "tools" that in-browser agents call directly, via a Declarative API (HTML attributes on forms) or an Imperative API (JavaScript for dynamic flows).
• Early figures from Google and coverage suggest roughly 5 to 10 seconds per action and a 15 to 20% error rate for screenshot-and-click agents, versus roughly 1 to 2 seconds with near-zero errors for direct tool calls. Treat these as early, not guaranteed.
• The 51% bot-traffic figure from Imperva's 2025 report is mostly bad bots, not helpful AI agents. Do not confuse the two when sizing this up.
• Prepare now by auditing your key conversion flows, keeping forms semantic and well-labeled, watching the origin trial, and thinking in "tools." Do not build production WebMCP code yet.