What is WebMCP and how does it work?
Author: Domeny.ForSale editorial team Published
In brief: WebMCP is a browser interface under development that lets a website expose its functions as tools for AI agents. Instead of guessing which button to click, an agent can use a described operation, such as searching for a product or filling in a form. It is not an AI model or a way to guarantee a site’s visibility in search engines. Before deploying it, check the current status of the specification and browser support.
How WebMCP helps an agent use a website
An AI agent is a program that uses an AI model to perform tasks, often in several steps and with additional tools. In a browser, these tasks might include finding a transport connection, comparing products or preparing a booking according to the user’s instructions.
Without a dedicated interface, an agent can analyse the page’s appearance or its DOM—the document structure that describes its elements. It then tries to identify fields, buttons and the successive steps in a process. This kind of automation is possible, but a change in page layout or an ambiguous label can make the task harder to complete.
WebMCP lets the website’s developer explicitly describe the available operations. Here, a tool means a function with a defined task and inputs, not a separate application. This gives the agent a more structured way to interact with the website than simply interpreting an interface designed for humans.
However, this does not mean the agent will always choose the right operation. The quality of descriptions, data validation and error handling still matter. WebMCP reduces the need to guess how to use a website, but it does not eliminate errors in the model or the application.
How WebMCP differs from MCP and a conventional API
MCP, or Model Context Protocol, connects applications that use AI models to tools and data sources. A typical implementation includes a client and a server that provides these capabilities. WebMCP, by contrast, concerns tools exposed by a website within the browser context.
WebMCP should therefore not be treated as another name for an MCP server. The idea of described tools is similar, but the point of integration and the way those tools are used differ. With WebMCP, the context of the open page matters, including the state of its interface and the user’s session.
A conventional API is an interface through which programs exchange data or request operations. A website may already use an API to retrieve search results or save form data. WebMCP does not have to replace it: it can expose an operation to the agent that then uses the application’s existing logic and communication with the server.
The practical difference is who the interface is designed for. An application’s API is usually designed for known software integrations, whereas a WebMCP tool should also clearly explain to the agent what it does and what data it needs.
Two ways to expose functions
WebMCP supports declarative and imperative approaches. The declarative approach describes capabilities in the page structure, primarily in HTML forms. The imperative approach registers tools using JavaScript and defines their behaviour in code.
The declarative approach suits actions that already take the form of a form: entering search criteria, selecting dates or supplying data. The imperative approach gives developers more control over complex operations and how responses are prepared for the agent.
The exact interface names, attributes and requirements may change as WebMCP develops. Before implementing it, consult the official Chrome documentation to confirm the current syntax, feature availability and any testing requirements. A description of the concept alone is not evidence that it already works in all popular browsers.
Example: finding an available appointment
Imagine a garage website where a user wants to find an available appointment for a tyre change. With conventional automation, the agent has to identify the form, select the service, navigate the calendar and read the available times.
With WebMCP, the website could expose a “find available appointments” tool that accepts a service type and a date range. The agent would pass these inputs to the described operation, and the application would return the available appointments. This would still be the garage application’s function doing the work, not an AI model determining availability on its own.
Finding an appointment and booking it should be separate operations. The first only reads data; the second changes the system’s state and may have consequences for the user. Keeping them separate makes it easier to require explicit confirmation before making a booking.
This is also a useful test of an implementation’s usefulness: an operation with a clear purpose, predictable inputs and an unambiguous result is easier to expose to an agent without giving it unnecessary freedom to act.
What to check before deployment
WebMCP makes the most sense on websites where users perform specific tasks. For a website containing only informational text, adding tools may offer little benefit. This technology should not be treated as a substitute for clear content, accessible forms or a well-functioning interface.
Before a pilot, check:
- Technical support: the current browser and agent environment requirements, and how the website behaves without WebMCP.
- Permissions: server-side access controls; calling a tool must not replace authorisation.
- Consequences: confirmation requirements for payments, data deletion and other significant changes.
- Data and errors: parameter validation, limits on disclosed information and clear failure messages.
Start with one read-only operation, such as searching for available appointments. Check whether the agent correctly identifies it and handles a lack of results before exposing functions that change data.
See also: What is Apache?
Read also
