WebMCP in Practice: A Complete Guide to Making Your Website AI Agent-Ready

At a technical workshop during Google I/O Connect, two Google engineers — Kasper and André — gave a systematic deep dive into a rapidly emerging challenge: how to prepare your website for the age of AI Agents. As more users rely on AI agents to handle shopping, booking, information retrieval, and other tasks, web developers face an entirely new set of requirements — your site needs to be friendly not just to humans, but to agents as well.

This article distills the core content from that workshop, covering how agents "see" websites, the WebMCP web standard currently under proposal, and the accompanying debugging and auditing toolchain.

Agentic Web: Not a New Internet, but an Evolution of the Web

In computer science, an Agent is an autonomous entity: it observes its environment, gathers information, processes it, takes actions to achieve a specific goal, and continuously loops through this cycle. What's genuinely changed in recent years is the integration of LLMs as a "reasoning engine" into agent systems, unlocking entirely new capabilities.

When large language models (LLMs) are wired into agent systems, they give agents unprecedented natural language understanding and planning abilities. Traditional rule-based agents rely on hard-coded logic, while LLM-powered agents can interpret ambiguous instructions, decompose complex tasks, and dynamically adjust strategies across multi-step execution. At the heart of this paradigm shift is the LLM's function calling / tool use capability — models don't just generate text; they can recognize when to call an external tool, what parameters to pass, and how to incorporate the tool's output into subsequent reasoning. OpenAI, Google, Anthropic, and other major model providers have all made structured tool calling a first-class feature of their APIs.

André emphasized that the "Agentic Web" is not a separate, parallel internet — it is an evolution of the Web we already know and love. The essence of the web remains human creation, sharing, and consumption of content; it's just that users increasingly rely on AI agents to carry out those tasks.

Agents themselves come in several forms:

• On-site agents: Integrated directly into a website, forming part of the experience
• Browser agents: Native to the browser (e.g., Gemini in Chrome) or delivered via extensions
• Off-browser agents: Such as CLI applications that communicate with the browser via protocols like CDP

How AI Agents "See" Your Website

For users to succeed when using an agent, you first need to understand how agents perceive a webpage. The workshop identified three primary input signals agents use:

1. Visual Screenshots

Agents can "see" a page much like a human would — by taking a screenshot of the rendered page and interpreting it with a vision model. This is the perception mode closest to how humans browse.

2. The Rendered DOM Structure

Agents read the rendered DOM to analyze the structure and hierarchy of text. The nesting relationships between elements (e.g., a button inside a div) convey content hierarchy to the model; the raw text within tags tells the model what action an element performs. The DOM tree fundamentally reinforces relationships between page elements.

3. The Accessibility Tree

This is a native browser API that distills the DOM down to its most important parts — the roles, names, and states of interactive elements — giving the agent a semantic summary of the page. You may not have noticed, but this is the same technology used by screen readers.

The Accessibility Tree is a semantic, tree-shaped structure built by the browser from the DOM and ARIA attributes, exposed to external programs via the operating system's assistive technology APIs (such as Windows UI Automation or macOS NSAccessibility). Screen readers like NVDA and VoiceOver read this tree to narrate page content and navigation structure to visually impaired users. Each node contains a role (e.g., button, link, heading), an accessible name, and current state (e.g., checked, disabled). The W3C's WAI-ARIA specification defines how developers can actively shape this tree via HTML attributes (aria-label, aria-role, etc.) to improve semantic accuracy. AI agents borrow the same mechanism — essentially treating the LLM as a "super screen reader" for understanding a page.

This leads to a key insight: building a great website for humans is often the same as building a great website for AI agents. High-quality visual presentation, semantic HTML, and good accessibility — these are already hallmarks of excellent front-end engineering, and they also make your site more effective for agents to use.

The Challenge: Context Bloat in Complex Tasks

However, "just doing the basics well" isn't enough. André illustrated this with the example of booking a hotel room: when a human visits a hotel website, they need to find the search bar, pick dates, apply filters, set up a late checkout... As user journeys grow more complex, the context an agent needs to understand grows along with them.

An LLM's reasoning capacity is bounded by its context window — the maximum number of tokens the model can process in a single pass. Feeding a model the full DOM tree, accessibility tree, and visual screenshots (converted to Base64 or descriptive text) simultaneously rapidly consumes that context window, introducing latency (inference time scales with token count) and significant API costs. Google Gemini 1.5 Pro supports an ultra-long context of up to 1 million tokens, yet even so, a complex e-commerce page fully serialized could easily exceed tens of thousands of tokens.

This creates two practical problems:

• Synthesizing signals like screenshots, the DOM, and the accessibility tree requires more compute, slowing responses;
• The more complex the context, the higher the probability that the model misinterprets a signal and goes off course.

This surfaces the core question: how do we make the interaction between websites and agents faster and more reliable?

WebMCP: Exposing Structured Tools to AI Agents

WebMCP is the answer to that question — a web standard currently under proposal, designed to let existing websites expose structured tools to AI agents.

WebMCP takes its name from the Model Context Protocol (MCP), open-sourced by Anthropic in November 2024 — an open protocol that standardizes how LLMs interact with external tools and data sources. MCP uses a client-server architecture, allowing AI applications to connect to file systems, databases, APIs, and other resources through a unified interface. WebMCP can be understood as a native browser/web implementation of the MCP concept: embedding MCP's tool-exposure mechanism directly into browser standards, so that any website can declare — via HTML or JavaScript — which agent-callable operations it supports, without requiring an additional intermediary server. This direction aligns closely with W3C's long-standing web standardization efforts and signals a deep convergence between the MCP ecosystem and the open Web.

Kasper explained: when a user wants to add a pizza topping on a pizza website, rather than analyzing visuals or parsing the DOM, the agent can directly call a tool provided by the site. If a tool exists that supports the user's intent, the entire interaction journey is dramatically simplified.

The workshop demonstrated two intuitive demos:

• Restaurant reservation: The user inputs "Celebrate the workshop's success — book a table for 7", and the agent automatically calls the BookTable tool, filling in name, date, time, party size, and even special notes.
• Maze game: The website exposes tools like move, look, pick up, use, and drop. Given the high-level instruction "keep moving until you reach the exit, pick up items along the way and use them to clear the path," the agent autonomously combines these tools to solve a complex problem.

This leads to an important point: a tool's name, description, and parameter documentation aren't just docs — they're the critical context the agent uses to decide when to call a tool. Think of it as a specialized form of prompt engineering.

Two WebMCP APIs: Imperative and Declarative

WebMCP offers two ways to define tools, suited to different development scenarios.

Imperative API

Using standard JavaScript, tools are registered via document.modelContext.registerTool. Each tool requires:

• name: The tool's name
• description: A description of the tool
• input schema: Parameter definitions in JSON Schema format
• execute block: The logic to run when the tool is invoked

JSON Schema is a declarative specification (maintained by the IETF) for describing and validating JSON data structures. In WebMCP's imperative API, a tool's input schema uses JSON Schema to define parameter types, required fields, enum values, and descriptions. This isn't an arbitrary choice: the function calling interfaces of major LLMs (OpenAI, Gemini, Claude) all use JSON Schema as the standard format for tool parameter specifications, and models have been trained extensively on how to parse and comply with such schema constraints. A well-defined JSON Schema not only helps the model fill in parameters accurately — it also provides machine-readable error feedback when an agent passes an invalid value, enabling a "error → retry" self-correction loop.

The value returned by execute is sent back to the agent — this is an excellent opportunity to return parameter error messages, success status, or even "suggested next steps," because this message is addressed to the agent, not the user. To deregister a tool, you can use an AbortController; Angular developers can bind this to a component's onDestroy lifecycle hook.

Declarative API

If you already have an HTML form, you only need to add two required attributes — toolname and tooldescription — and the browser will recognize the form as a WebMCP tool. The optional toolparamdescription provides additional context for parameters.

By default, the declarative API requires the user to click the submit button for the form to actually submit (the agent only fills it in), but you can switch to automatic submission using the toolautosubmit attribute. The form's submit event gains a new agentInvoked member that is true when the submission was triggered by an agent; the respondWith method lets you return detailed information to the agent, helping it learn from errors and retry.

DevTools Debugging and Lighthouse Auditing

Google hasn't just proposed the standard — it has also built out a complete developer toolchain to go with it.

Debugging with Chrome DevTools

In DevTools, developers can inspect which tools were called, the parameters passed in, and the output returned. Since WebMCP tools are fundamentally just JavaScript functions or HTML forms, all your existing debugging techniques apply directly — including setting breakpoints and stepping through code.

On evaluation strategy, Kasper's recommendation is: test tools deterministically wherever possible, then do targeted evaluation at the LLM touchpoints — for example: given a set of tools, can the agent select the right one? Can it pass the right parameters? Can it use the output of one tool as the input to another?

Lighthouse Agentic Auditing

Lighthouse is Google's open-source automated web quality auditing tool, originally launched in 2016 with a focus on PWA (Progressive Web App) compliance. It has since expanded into a comprehensive auditing platform covering four dimensions — Performance, Accessibility, Best Practices, and SEO — and is deeply integrated into Chrome DevTools' Lighthouse panel and CI/CD workflows. The new "Agentic Browsing" audit category marks Lighthouse's extension into the AI era: just as it once provided quantitative guidance for mobile optimization and SEO, Lighthouse now delivers an actionable checklist for "agent readiness."

Starting with the Chrome 150 milestone, Lighthouse adds an "Agentic Browsing" audit category that checks the following key items:

• Accessibility: Highly relevant for agents
• Layout Shift: How much page content shifts around
• WebMCP tool validation: Whether schemas are correctly defined

In a live demo using a real website (Google Advanced Search), the audit produced specific pass/fail results and flagged forms that lacked declarative API annotations. The audit is still experimental, and Google is actively soliciting developer feedback.

Three Actionable Steps You Can Take Now

The workshop closed with three action steps for making your website AI agent-ready:

1. Try WebMCP's imperative and declarative APIs to wrap your site's core functionality as structured tools;
2. Use Lighthouse to audit your site's agentic readiness, fixing issues like accessibility problems and layout shift;
3. Join the WebMCP Origin Trial and provide real-world feedback while the standard is still being shaped.

Origin Trial is Chrome's progressive open-testing mechanism for introducing new web platform features. After applying to Google, developers receive a token that can be embedded in a page's HTTP response headers or meta tags, enabling experimental APIs that haven't officially shipped for real users in production — without requiring users to manually toggle browser flags. This mechanism lets Google collect large-scale, real-world usage data and developer feedback before a standard is finalized, while preventing experimental APIs from becoming a "de facto standard" before they're ready to change. WebMCP is currently in the Origin Trial phase, meaning its API design is still subject to adjustment, and developer participation and feedback at this stage will directly influence the direction of the final specification.

As both speakers repeatedly emphasized: agent readiness starts with principles we've always known — build your site well, and make it accessible. WebMCP builds on that foundation, providing a structured, reliable, and debuggable path for the Web to step into the Agentic era. For developers, now is the perfect time to start experimenting — and to help shape this emerging standard.

Key Takeaways