AI agents can already research trips, complete forms, and compare products. In many cases, however, they operate like very fast human visitors: they read visible text, look for buttons, and try to interpret the interface correctly. This can work, but it remains fragile. A changed button label, a redesigned layout, or an unexpected dialog may interrupt the entire workflow.
WebMCP proposes a different approach. It lets websites offer important capabilities to browser agents as clearly described, structured tools. Instead of being told to “find the right button and click it,” an agent could receive a tool named search_products with defined inputs such as a search term, price range, and category. The website keeps its regular interface for people while adding a machine-readable layer for agents.
What is WebMCP?
WebMCP is a proposed web standard that is being developed in public. The API allows a website to expose tools within the context of an open browser tab. A tool has a name, a description, an input schema, and an execution function. An agent can discover the available tools, prepare valid parameters, and ask the page to perform the selected function.
The key difference from conventional browser automation is explicit intent. A button says little beyond the fact that it can be clicked. A WebMCP tool states what it does, which information it requires, and what result to expect. JSON Schema allows inputs to be checked before an action starts.
As of August 2026, WebMCP is still experimental. Chrome has been running an origin trial since version 149, and a browser flag is available for local testing. That distinction matters for planning: teams can build prototypes and gather experience today, but they should not treat WebMCP as a universally available production interface yet.
Two approaches: enhance forms or register tools
The proposal supports both declarative and imperative APIs.
The declarative approach adds metadata to an existing HTML form. Attributes such as toolname and tooldescription explain the task, while toolparamdescription clarifies individual fields. The browser can turn those annotations into a structured tool and input schema. This works well for search forms, appointment queries, calculators, and contact forms.
The imperative approach suits complex applications. JavaScript registers a tool that can reuse business logic, page state, and asynchronous processes. The current API uses document.modelContext; older examples with navigator.modelContext are outdated.
document.modelContext.registerTool({
name: "check_availability",
description: "Checks available appointments for a service.",
inputSchema: {
type: "object",
properties: {
date: { type: "string", format: "date" }
},
required: ["date"]
},
execute: async ({ date }) => checkAvailability(date)
});
Tools can be registered, updated, removed, or aborted. Because they live in the active document, they can use page state such as a selected branch, a shopping cart, or information already entered.
WebMCP and MCP solve different problems
The similar names can create confusion: WebMCP does not replace the Model Context Protocol, nor is it simply MCP moved into the browser.
MCP typically connects AI applications to persistent server-side services, data sources, and tools. WebMCP is tied to a browser tab. Its tools are temporary, aware of the current document, and complement an interface that people also use.
The approaches can work together. A travel company might use MCP for reservation data, while WebMCP incorporates the trip selected in the tab, local validation, and visible confirmation. The choice depends on whether a capability belongs on the server or in the user's current page context.
Practical use cases
WebMCP is especially promising for tasks that currently require agents to complete several fragile clicking steps:
- An online store can expose product search, variant checks, and cart actions in a structured form.
- An appointment service can query open slots and prepare a booking up to the confirmation step.
- An insurance calculator can validate inputs and return an explainable result.
- A SaaS dashboard can filter reports, prepare exports, or change settings.
- A support portal can find relevant documentation and create a ticket with all required fields.
Structured tools also reduce interpretation work. The agent analyzes less page content and receives clearer errors, while the website controls which capabilities and parameters are exposed. The site remains usable without an agent; when one is present, it receives a defined route through selected workflows.
Security is part of tool design
A well-described function is not automatically a safe function. Prompt injection remains a central risk: content on a page or data loaded from an external source may try to manipulate an agent's behavior. The preliminary WebMCP security guidance explicitly notes that these attacks cannot be ruled out completely.
Tools should therefore follow the principle of least privilege. Read operations and write operations need to be clearly separated. Metadata such as readOnlyHint and untrustedContentHint can help an agent assess risk. Sensitive operations—including purchases, payments, cancellations, and sending personal data—should include a clear human confirmation step.
Origin boundaries matter as well. Tools are isolated to their own origin by default; cross-origin exposure must be intentional and narrowly scoped. Developers should use HTTPS, revalidate inputs on the server, enforce authorization, and keep confidential information out of descriptions and results. The tool layer does not replace authentication, rate limits, audit trails, or transaction checks.
How website teams can start today
A sensible first project is a clear, low-risk task with stable inputs and outputs.
- Identify a frequent workflow such as search or availability checking.
- Describe the goal from the user's perspective and choose an unambiguous tool name.
- Define a narrow JSON Schema and reject unknown or invalid parameters.
- Reuse existing application logic instead of duplicating business rules in the browser.
- Return structured results and actionable errors.
- Test successful flows, cancellations, missing data, and hostile content.
- Add visible human confirmation before consequential actions.
- Keep the human interface and a reliable fallback fully functional.
Declarative annotations may provide the fastest prototype for a simple form; a dynamic application may benefit from a small imperative layer. Tests should distinguish failures in the agent, tool definition, and underlying business logic.
Conclusion
WebMCP moves browser automation from visual guesswork toward explicit capabilities. Websites can tell agents what they can do, which inputs they require, and how a task can be completed reliably. The result could be fewer brittle click sequences and better cooperation between the website, the agent, and the user.
The standard is still experimental, and its API may change. This is a good time for focused prototypes rather than broad dependency. Teams can find appropriate workflows, define security boundaries, and let people and agents share dependable business logic. Organizations that describe tools precisely while keeping consequential decisions with the user will be better prepared for an agentic web.