WebMCP: what it means when AI agents can use your website
AI agents can already open a website, read a page and click through an interface. The experience is still fairly fragile. A changed button label, an unexpected pop-up or a slightly different layout can derail the task.
WebMCP gives websites a more reliable way to tell an AI agent what can be done and what information each action needs.
For a customer, that could mean asking a browser assistant to find a suitable appointment and make a booking. For a business, it creates a new question: which parts of your website should an agent be able to use on a customer's behalf?
The short answer
WebMCP is an emerging browser API that lets a website expose selected functions as structured tools for AI agents.
A form could expose a submit_application tool. A booking site could expose find_available_times. A customer portal could expose download_invoice or update_contact_details.
The agent receives a name, a plain-language description and a defined set of inputs for each tool. It can then call the right function directly, instead of working out the interface from screenshots and simulated clicks.
The WebMCP specification is being developed through the W3C Web Machine Learning Community Group. As at August 2026, it is a draft Community Group report rather than a formal W3C Standard.
What changes for the customer
Consider a commercial property website with dozens of listings and a detailed enquiry form.
A customer could tell their browser assistant:
Find office space in Brisbane for 40 to 60 people, available before February, with parking and public transport nearby. Shortlist the best 5 options and prepare an enquiry for each.
Today, an agent may need to interpret filters, open listings one at a time and work through each form field. With WebMCP, the site could provide tools for searching listings, checking availability and preparing an enquiry.
The customer still sees the website and can review the work. The agent has a defined route through the task.
This pattern can apply to service bookings, product configuration, insurance forms, support portals, travel planning and other interactions that involve several steps or detailed inputs.
How WebMCP works
WebMCP has 2 ways for a website to describe its tools.
The imperative API lets a developer register JavaScript functions with a tool name, description and input schema. This suits actions with application logic behind them, such as searching records, changing a design or running a calculation.
The declarative API uses annotations on standard HTML forms. This can help an agent understand what a form does, which fields matter and how to submit it correctly.
The browser sits between the agent and the page. It handles discovery and tool calls within the site's existing browser context. The site's normal authentication, interface state and client-side logic remain part of the interaction.
Google's current Chrome documentation describes WebMCP as a progressive addition to a website. Existing human interfaces remain in place.
WebMCP and MCP solve different parts of the problem
Model Context Protocol (MCP) connects an AI system to external tools and information, often through a server. A business might use an MCP server to give an assistant access to a CRM, document store or project platform.
WebMCP works inside the browser. It lets the website itself describe the actions available on the current page.
The distinction matters. A backend MCP connection may let an agent work directly with a service, away from the website. WebMCP keeps the website in the interaction, including its interface, logged-in session and business rules.
The 2 approaches can coexist. A customer-facing task may happen through WebMCP while an internal agent uses MCP to work across business systems.
The commercial question behind the technical one
WebMCP will matter most for websites where customers come to complete a task.
Content sites may see limited immediate benefit. Portals, marketplaces, booking services, online applications and software products have a clearer case because their value sits in what users can do.
Digital teams should start with a few practical questions:
- Which customer tasks involve repeated clicks, filters or form fields?
- Where do users abandon a process or contact support for help?
- Which actions can be prepared by an agent and reviewed by a person?
- What information should never be exposed to an agent?
- Which action would create the clearest improvement for the customer?
This is service design work before it is development work. A poorly defined process will remain poorly defined when an agent uses it.
Security and control need deliberate design
Giving agents structured actions creates a new surface for mistakes and abuse. Tool descriptions can be manipulated. An agent can misunderstand intent. A tool can request more information than the task requires.
The draft specification deals directly with prompt injection, tool poisoning, privacy leakage and origin boundaries. Chrome's implementation also uses origin isolation and browser permissions policies. Sites can request user confirmation for sensitive actions such as making a purchase.
Those controls are a starting point. Each business still needs to decide which actions are safe to expose, what needs explicit approval, what gets logged and how a user can correct or cancel an action.
A useful first tool has limited consequences. It helps someone search, prepare or preview. Transactions and irreversible actions deserve far more scrutiny.
What businesses should do now
WebMCP is early. Chrome currently provides local testing and an origin trial, and the API remains subject to change.
A typical corporate website can use this period to map the tasks customers may soon delegate to browser agents. A broad implementation can wait until the standard and browser support settle.
If you run a web application or a transaction-heavy website, choose 1 contained task and test it. Measure whether an agent completes it more reliably, whether the customer remains in control and whether your existing business rules still hold.
The websites that handle this well will have made clear decisions about their services, permissions and customer experience. The code comes after that.