WebMCP

Registration takes place either declaratively in HTML or imperatively in JavaScript. To test it, you need Chrome 150 or later and must register for the WebMCP origin trial.

What WebMCP is and what it is intended for

WebMCP addresses a fundamental problem of agentic web use: when an AI agent is supposed to complete a task on a website on behalf of a user, today it usually has to interpret the interface, recognise elements and simulate clicks and keyboard input. That is error-prone, slow and breaks as soon as the layout changes. WebMCP turns this approach around. The website itself describes which tools, i.e. which functions and forms, it offers and provides them in machine-readable form. The agent then no longer has to guess where the "Submit" button is, but calls the matching registered tool directly.

The name refers to the Model Context Protocol (MCP), which has become known as an interface between AI models and external tools. WebMCP transfers this idea to the browser: the website itself becomes a provider of tools that an agent running in the browser can use. This shifts the integration work from the agent to the page. You as the operator decide which functions you release for agents and how they are called.

WebMCP is explicitly experimental. It is a "proposed" standard at the origin trial stage, and the specification may still change. Anyone working with it today should treat it as an early test, not as a production-ready, permanently stable interface.

Declarative and imperative registration

WebMCP has two ways in which a page registers its tools. Both have different strengths:

• Declaratively in HTML: here you describe tools directly in the page's markup. This is well suited to forms and clearly delimited actions that exist in the markup anyway. The advantage is the closeness to the existing HTML and the small amount of additional logic.
• Imperatively in JavaScript: here you register tools programmatically at runtime. This is more flexible and makes it possible to provide tools dynamically depending on the state of the application, for example when a user is logged in or certain data has been loaded.

Which route fits depends on the architecture of your site. A largely static page with clear forms often manages with the declarative variant, while a dynamic single-page application will more often use imperative registration.

How WebMCP relates to agentic browsing

WebMCP is one of the four signal areas that Google Lighthouse checks in the agentic browsing category. Since Lighthouse 13.3.0 of 7 May 2026, this category has run by default, and PageSpeed Insights has adopted it too. Lighthouse checks whether a page registers tools via WebMCP. Alongside WebMCP, the four signal areas include the presence of an llms.txt in the domain root, the integrity of the accessibility tree and the cumulative layout shift (CLS).

Unlike a classic score from 0 to 100, agentic browsing delivers a pass/fail checklist with a proportional pass rate. WebMCP registration is thus a single checkpoint on this list: either your page demonstrably registers tools, or the point fails. The classification is important: agentic browsing, and therefore the WebMCP signal, is not a ranking factor. Google collects data and gives signals but does not directly influence your position in the classic search results.

A concrete example and the test prerequisites

Imagine a contact form on your website. Without WebMCP, an AI agent has to recognise the form visually, map the fields and simulate the input. With WebMCP, you register the form as a tool, for example "Send message" with the parameters name, email and message. The agent then calls this tool in a structured way, passes the values and receives a defined result back. This is more robust and predictable than imitating clicks.

To test WebMCP in practice, you need two things: Chrome version 150 or later and a registration for the WebMCP origin trial. Origin trials are the standard procedure by which Chrome enables experimental features for selected domains without activating them globally for all users. The official documentation describes registration and the API: WebMCP at Chrome for Developers. Because it is an experimental standard, the interface may change, and the origin trial is limited in time.

What you can sensibly do today

Because WebMCP is experimental, a full production roll-out rarely makes sense today. The following steps are realistic:

1. Understand which of your functions would be relevant for agents at all, such as search, basket, appointment booking or contact.
2. First ensure a clean semantic basis: an intact accessibility tree and a low CLS help agents even without WebMCP and are further signal areas of the agentic browsing category.
3. If appropriate, create an llms.txt in the domain root to cover the further signal area.
4. Test WebMCP in a delimited environment via the origin trial before rolling it out more widely.

WebMCP, llms.txt and the accessibility tree working together

WebMCP does not stand alone but complements two other mechanisms that also aim to make a website understandable to machines. It is worth separating the roles clearly, because they answer different questions. The llms.txt in the domain root is a signpost: it tells a large language model which content and entry points of a site are relevant, so it is more descriptive. The accessibility tree provides the semantic structure of an individual page, i.e. names, roles and visibility of the elements, and is thus the basis for understanding the interface. WebMCP goes a step further and enables action: it provides callable tools through which an agent executes functions directly.

In practice, the three levels interlock. An agent can use the llms.txt to find out where the areas relevant to its task are, use the accessibility tree to understand the specific page and use WebMCP to carry out the necessary action. If one of these levels is missing, the agent has to bridge the gap through interpretation and simulation, which again becomes more error-prone. That is exactly why Lighthouse checks all three in the agentic browsing category, together with the cumulative layout shift as the fourth signal area.

Typical use cases for WebMCP

WebMCP is particularly useful where a page offers clearly delimited, recurring actions that an agent could carry out on behalf of a user. Examples of such functions are:

• Search: a search registered as a tool allows an agent to search specifically for a product or content instead of having to find and fill in the search field visually.
• Basket actions: adding a product to the basket can be defined as a tool so that an agent can call it reliably without recognising the button from the image.
• Appointment booking: a booking form with defined parameters such as date and time becomes callable via a tool and thus more robust against layout changes.
• Contact and enquiry forms: standardised forms are well suited to declarative registration because their fields exist in the markup anyway.

What these cases have in common is that the action has a clear input, defined parameters and a predictable result. That is exactly what makes the difference from classic agentic use, in which the agent has to derive the intention from the interface.

Security and control aspects

A frequently overlooked point with WebMCP is control over what an agent is allowed to do at all. Because you as the operator register the tools yourself, you decide explicitly which functions are accessible to agents and which are not. That is an advantage over classic click simulation, in which an agent can in principle target anything that is visible. With WebMCP, you define a deliberate interface instead of an open surface.

At the same time, new responsibilities arise from this. Tools that trigger state-changing actions, such as submitting an order or changing data, need the same care as any other public interface: clean validation of inputs, protection against misuse and a clear idea of which actions may run without human confirmation. Because WebMCP is experimental and at the origin trial stage, you should be particularly cautious about releasing sensitive functions and test them first in a delimited environment before rolling them out more widely.

Placing WebMCP, MCP and the origin trial in context

The reference to the Model Context Protocol helps to place WebMCP in context. MCP has become established as the interface through which AI models connect external tools and data sources, such as databases, file systems or services. WebMCP transfers this tool concept to the level of the browser and the individual website: it is not a server that provides tools for a model, but the website itself that provides tools for an agent running in the browser. The conceptual core remains the same, namely clearly defined, callable functions instead of free interpretation; only the place where they are provided shifts.

The origin trial is the procedure by which Chrome rolls out this experimental feature in a controlled way. Instead of activating WebMCP immediately for all sites worldwide, individual domains register for the trial and thus enable the feature specifically for their origin. This gives browser makers and developers the opportunity to test a feature under real conditions and collect feedback before it becomes a permanent part of the browser or is discarded again. For you, this means two things: first, you can already try out WebMCP today; second, you should not rely on the interface remaining permanently in its current form.

In practice, this also means that access is tied to specific prerequisites. You need Chrome 150 or later, a registration for the WebMCP origin trial and an understanding of whether you want to provide tools declaratively in HTML or imperatively in JavaScript. The official documentation at Chrome for Developers is the authoritative reference point, because the details of an experimental standard can be tracked most reliably there.

FAQ on WebMCP

What is WebMCP in one sentence?
An experimental Chrome browser protocol through which a website registers tools so that AI agents can discover and call its forms and functions directly.

How do I register tools?
Either declaratively directly in HTML or imperatively via JavaScript at runtime. Which route fits depends on the architecture of your site.

What do I need for testing?
Chrome 150 or later and a registration for the WebMCP origin trial.

Is WebMCP connected with Lighthouse?
Yes. WebMCP tool registration is one of the four signal areas checked by the Lighthouse agentic browsing category, alongside llms.txt, the accessibility tree and CLS.

Is WebMCP production-ready?
No. It is an experimental standard labelled "proposed" at the origin trial stage, whose specification may still change.