WebMCP In-Depth: How AI Agents Are Reshaping Web Interaction

When users are no longer satisfied with asking an AI assistant to "write an email" but instead want it to "send the email," the underlying interaction logic of the Web is facing a fundamental restructuring. In a recent technical interview with the Chrome team, engineer Andre broke down the design philosophy and implementation progress of WebMCP (Web Model Context Protocol). This is not just another lab concept—it's an infrastructure proposal that has already entered the Chrome Origin Trial and attracted players like OpenAI, Cloudflare, and Brave.

From "Humans Reading Webpages" to "Agents Using Webpages"

Andre defines the current shift as the arrival of the "Agentic Web." In the past, users mostly used AI for Q&A, summarization, and draft generation; today, user expectations have upgraded to task execution—for example, letting an agent directly complete flight searches and filtering. This means developers need to ensure their products can be "used" by agents, not just "browsed" by humans.

Andre believes the scale of this shift is comparable to or even exceeds the adoption of the mobile Web. But the core logic is not about letting agents replace users—it's about making agents a tool in users' hands to invoke your product. What developers need to do is ensure that regardless of which interface the user employs (a human browser or an agent's invocation), the product can be used smoothly.

Three Pillars of Agent-Friendliness

To make products usable by agents, the Chrome team breaks this down into three dimensions: discovery, understanding, and usability.

At the discovery level, agents need to know your product exists and what it can do. robots.txt and sitemap remain effective, but new files like llms.txt have emerged, consolidating a site's core content in one standard location to reduce the overhead of agents crawling the entire site.

At the understanding level, the key lies in the structural quality of HTML. Many agents currently cannot execute JavaScript, and pure client-side rendered empty-shell pages will leave them stuck—echoing the early history when search engines didn't execute JS. Content negotiation is another approach: when a request is identified as coming from an agent, return a more token-efficient Markdown version to help the agent understand content more efficiently.

At the usability level, most agents currently rely on the "actuation" model: screenshots, visual model recognition, simulated clicks. This requires clear page layouts, buttons that look like buttons, and form-to-button DOM relationships that conform to semantics. As a detail, Andre emphasized that these optimizations also benefit regular users—good accessibility markup and structured HTML are already Web development best practices.

llms.txt is a community-proposed site information file specification aimed at large language models. It is provided in Markdown format at the site root and typically contains a site introduction, links to core pages, documentation directories, and other structured indexes, helping models quickly locate key content without crawling the entire site. Unlike robots.txt (which specifies crawlable scope) and sitemap.xml (which lists all indexable URLs), llms.txt's goal is not "allow or disallow crawling" but "tell the model what's here and where to read, using as few tokens as possible." For content sites and documentation sites, it can significantly reduce the overhead of agents traversing the entire site. Currently, this specification has no formal standardization from browser vendors—it's a de facto convention that sites can adopt as needed.

Content Negotiation is an existing HTTP mechanism where the client declares its preferred representation via request headers (such as Accept, User-Agent), and the server returns different versions accordingly. In the Agentic Web context, its typical use is: when a request is detected as coming from an agent, return a streamlined Markdown or plain text version rather than the full HTML page. This reduces transfer size and prevents the agent from consuming context on parsing navigation, ads, scripts, and other irrelevant DOM. When implementing, note that when returning different content based on request headers, the Vary response header must be set correctly to prevent intermediate caches from incorrectly returning the agent version to human users.

What WebMCP Solves: From "Guessing" to "Calling"

Screenshots plus DOM plus accessibility tree represent a huge context burden for agents. The larger the context, the slower the response and the higher the probability of errors—clicking the wrong button, misinterpreting intent. WebMCP's core idea is: rather than having agents "guess" how a page works, let the website proactively "tell" them.

Website developers register tools through the WebMCP API, and agents call these tools directly, skipping screenshots and DOM parsing. This brings three direct benefits: less token consumption, faster responses, and higher reliability. At the same time, through tool descriptions and parameter design, developers are effectively guiding agents to use the product correctly.

WebMCP offers two registration methods: declarative (adding special attributes to existing forms to turn them into tools) and imperative (JavaScript API). The flight search demo in the interview used the imperative API—the search page registered a searchFlights tool, and the filter page dynamically registered a setFilters tool. Interestingly, tools can be dynamically registered and unregistered, and agents can even automatically discover tools registered by new pages during a single conversation and call them consecutively.

The actuation model refers to agents not relying on structured interfaces provided by websites, but instead "operating" pages like a human: capturing screenshots, using visual models to identify button and input field positions, then simulating mouse clicks or keyboard input. The advantage of this approach is universality—any webpage can be attempted; the disadvantage is fragility and expense: each step requires passing in images and DOM snapshots, context rapidly expands, and any minor page redesign, occlusion, or lazy loading can cause recognition to fail. WebMCP's approach is to replace this "visual guessing" with "explicit calling," where websites declare tool names, parameters, and semantics, and agents simply construct calls according to the schema to accomplish the same operation—shifting uncertainty from the recognition stage to controlled interface contracts. This is why the article emphasizes that its benefits center on token consumption, response speed, and reliability.

Permission Design: Read-Only Hints and Destructiveness Assessment

Whether tool calls require user confirmation is a key decision in agent UX. The WebMCP API already provides some hint mechanisms, such as read-only hints, telling agents that the tool does not change page state and only returns information. But Andre points out that read-only does not mean safe—tools that read sensitive user information may carry higher risk than some write operations.

For write-type tools, the criterion should not be "whether it writes" but "how destructive and how reversible." A flight search tool has limited impact, but a tool involving payment must be authorized cautiously. Currently, some hint capabilities are in place, while others are still evolving, and agents will also use tool descriptions to judge whether to request permission.

Origin Trial is a mechanism introduced by Chrome that allows developers to test new Web platform features not yet enabled by default in real user environments before formal standardization. Developers need to apply for a token for their origin and declare it via a meta tag or response header in the page; thereafter, visitors under that origin can enable the feature without users manually changing settings. Its significance is that standards drafts can validate API design and compatibility through real traffic while limiting the impact to sites that voluntarily opt in. For WebMCP, joining the Origin Trial means tools registered by the site can be discovered and called by agents that have enabled the protocol, but the interface may still be adjusted based on feedback, and production use requires evaluating stability risks.

Ecosystem Progress: From Experiment to Production

According to Andre, the WebMCP standard was jointly initiated by Microsoft, Google, and community members, with contributors from various companies currently participating. Chrome has opened the Origin Trial, and website developers can voluntarily join; after joining, all visiting users can use it without any action on the user side. The development environment can also be enabled directly through a Chrome flag.

Agent-side support is expanding. Gemini in Chrome is already experimenting with WebMCP; Cloudflare's Browser Run product supports it and has put WebMCP into production; Brave experimented with it in its agent Leo; and OpenAI recently added WebMCP support to its agents. Andre admits the ecosystem is still early, but interest is growing on both the website and agent sides, which is crucial for bootstrapping a two-sided ecosystem.

Chrome extensions currently call page-level APIs through content scripts to read and execute tools; there is no extension-specific API yet. Extensions can also register tools for other agents to call.

Unanswered Questions: Progress Feedback and Skill Composition

At the end of the interview, Andre mentioned the current capability boundaries of WebMCP. A typical pain point is progress feedback for long-running tasks: if tool execution takes several minutes (such as downloading a file), the page currently cannot report progress status to the agent. This is a frequently appearing need in community feedback.

Another more imaginative direction is "skills"—whether websites can give agents a "recipe" guiding them on how to combine multiple tools to accomplish more complex tasks. Andre believes this remains an open question, and WebMCP itself is just getting started.

As for the future of the Web, Andre's judgment is: browsing will not disappear, because browsing itself has value for fun and exploration; agents' strength lies in eliminating workflow friction and automating workflows. The two are not a replacement relationship but a division of labor.

For developers, the most pragmatic actions right now are perhaps: check HTML semantic structure, improve accessibility markup, assess whether llms.txt is needed, then consider joining the WebMCP Origin Trial and registering your core operations as tools—before agents become a major traffic entry point, make your product "visible, understandable, and invocable."

One-line Summary

Chrome team explains WebMCP: letting websites proactively expose tools to agents and restructuring Web interaction logic.

Paragraph Summary

Based on a technical interview with Chrome team engineer Andre, the article systematically introduces the design philosophy and implementation progress of WebMCP (Web Model Context Protocol). The author notes that user expectations for AI are shifting from "generating content" to "executing tasks," bringing the Web into the Agentic Web phase, where developers need to make products not only browsable by humans but also callable by agents. The article breaks agent-friendliness into three pillars—discovery, understanding, and usability—and explains how WebMCP lets websites proactively register tools through declarative and imperative APIs, replacing the high-overhead screenshot-plus-DOM-parsing model to reduce token consumption and improve speed and reliability. It also discusses permission design with read-only hints and destructiveness assessment, as well as ecosystem progress with the Chrome Origin Trial, Cloudflare, OpenAI, and Brave, and notes that long-task progress feedback and skill composition remain open questions.