"When I asked an AI to make a reservation, for some reason only our site couldn't be completed to the end"—inquiries like this will increase going forward. Rather than clicking manually, AI agents inside browsers (such as Gemini in Chrome) will operate websites on behalf of users to complete bookings, purchases, and inquiries. If an agent gets stuck at the gateway, not knowing what to click, users will flow to competing sites. This represents a new form of lost opportunity, separate from search ranking drop-offs.
What can change that reality is the WebMCP origin trial that began in Chrome 149. WebMCP (Web Model Context Protocol) is a new browser API that enables websites to declare structured actions (tools) that agents can call. Originating from the idea of bringing Anthropic's MCP into the browser, it is jointly proposed by Google and Microsoft within a W3C community group. While the overarching picture of MCP connecting server-side AI to external systems is explained in The Complete Guide to MCP (GH Media), think of WebMCP as applying that concept directly to the screens of your own website.
Stopping agents from guessing the UI
Current browser agents operate just like humans by examining screen captures and the DOM, guessing that "this button is probably for booking." Because it is guesswork, it fails on sites with custom layouts or screens heavily assembled with JavaScript. Sites that are intuitive to humans but ambiguous to agents are precisely the ones that lose conversions via agents.
WebMCP eliminates this guesswork. If a website explicitly specifies names and arguments, declaring "this is a search tool," "this is an add-to-cart tool," and "this is a confirm-booking tool," the agent directly invokes those declared actions instead of guessing. The original Chrome documentation outlines two primary delivery methods.
| Delivery method | When to use | Concept |
|---|---|---|
JavaScript API（navigator.modelContext.registerTool） | Dynamic processes like search, filtering, and cart operations | Registering functions as tools |
| Declarative HTML attributes (annotations on existing forms) | Existing inquiry and application forms | Adding tool semantics to forms |
The key is that existing HTML forms can serve as the foundation. Rather than building a massive new mechanism from scratch, you append agent-facing semantics onto forms and search tools that are already working. This sequence of "first having working HTML, then layering features on top" aligns consistently with the mindset explored in Rebuilding with HTML-First (GH Media).
Distinct from on-device AI — Avoiding role confusion
A common point of confusion here is how this differs from Chrome's built-in AI (such as the on-device Prompt API). As covered in Custom Development for Building "Serverless AI Features" with Chrome Built-in AI (GH Media), built-in AI is about a website using AI capabilities. WebMCP, on the other hand, works in the opposite direction: it is about providing an entry point so that a website can be used by AI agents.
| Dimension | Built-in AI (Prompt API, etc.) | WebMCP |
|---|---|---|
| Direction | Site → calls AI | AI agent → calls site |
| Objective | Adds AI features inside the site | Opens site operations to agents |
| Value in custom development | New features such as summarization and assistance | Preventing missed conversions via agents |
Confusing these distinct roles leads to off-target designs, such as assuming that simply adding an AI chat widget means your site is WebMCP-ready. In our custom development work, we start by properly separating these two concepts.
Preparing agent-ready websites in custom development
WebMCP is still in the Origin Trial stage (a time-limited early implementation), and the specifications are evolving. That is precisely why, rather than attempting an immediate, full-scale rollout, a practical approach is to "move early within a safe scope that won't break things, building in a way that can track standardization." In our custom development projects, we structure the work in the following order.
Turn actions closest to conversion into tools
The first step is taking inventory of actions directly tied to revenue (search → check inventory → submit/confirm reservation). For a client operating a service booking website, we initially declared only two tools—"search available slots" and "confirm reservation"—leaving everything else as it was. There is no need to make every screen agent-ready at once; opening up the critical paths where drop-offs hurt the most is the most cost-effective approach.
Do not make modifications that break usability for humans
It defeats the purpose if adding excessive proprietary markup for agent readiness ends up breaking the experience for normal users or degrading existing accessibility. WebMCP declarations should remain strictly an enhancement on top of existing HTML, preserving a foundation that humans can operate even without JavaScript. For web accessibility fundamentals, please also read Web Accessibility Compliance Guide (GH Media).
Design guardrails for permissions and confirmation
Because agents can invoke hard-to-revert actions like confirming reservations or making payments, you must design whose authorization is required and how far execution may proceed. Chrome also cautions against untrusted tool invocations in WebMCP Tool Security. In our custom development, we always incorporate pre-confirmation steps, server-side validation, and audit logs to prevent scenarios where an agent confirms actions on its own and causes incidents. For designing transparency when allowing AI to operate interfaces, Designing Transparency UIs for AI Features in Custom Development (GH Media) is also a helpful reference.
The value of starting now — the cost of "wait and see"
While the decision to "wait until the standard stabilizes" might seem rational at first glance, agent-driven traffic is just like search traffic: sites that adapt first are chosen for their user experience. By declaring just one or two actions close to conversion during the Origin Trial stage, your website becomes one that agents can properly interact with, making the full transition much smoother once specifications are finalized. Conversely, if you remain in wait-and-see mode, your site will remain among those where agents hit dead ends, quietly accumulating lost opportunities.
Summary — "understandable to human eyes" is no longer enough
Until now, it was enough for websites to be built so that human users could understand them. Going forward, whether in-browser agents can accurately invoke actions will also directly impact conversion rates. WebMCP is the emerging standard that allows websites to provide that gateway. When approaching this through custom development, declaring a small set of tools starting with actions closest to conversion, preserving the human experience, and putting confirmation and logging guardrails around critical actions—starting from this minimal footprint is the pragmatic way to get ahead while minimizing risk.
If you would like to verify whether your site presents bottlenecks for agents, or if you want to run a small trial with WebMCP's Origin Trial, feel free to reach out via our contact form. We can start by taking inventory of your conversion user journeys.
Sources
- Join the WebMCP origin trial（Chrome for Developers）
- WebMCP tool security（Chrome for Developers）
- Inside WebMCP: how Google’s new browser API lets websites talk to AI agents natively（Rankly）
- Complete MCP Guide (GH Media)
- Custom Development for Building "Serverless AI Features" with Chrome Built-in AI (GH Media)
- Designing Transparency UIs for AI Features in Custom Development (GH Media)
