AI agents can already browse a site, find a form, type into it, and click Submit.
That works—until the button moves, the label is ambiguous, the form changes state, or the workflow spans six screens.
WebMCP proposes a better contract: let the page tell the agent which actions are available, what inputs they accept, and how to call them.
Instead of making an agent reverse-engineer the UI, a web app can expose tools such as:
search_emails
get_email
start_compose
reply_to_email
move_email
The human interface stays. WebMCP adds a structured interface for the agent working alongside the human.
The problem with simulated clicks
Most browser agents rely on actuation: they inspect a page and simulate human actions such as clicking, typing, and scrolling.
Every step adds uncertainty:
- Does “Continue” submit the form or open another step?
- Is the visible search box global or scoped to the current mailbox?
- Is a disabled field unavailable, or does another field need to be completed first?
- Did navigation make the agent's previous understanding stale?
A redesign that is harmless to a person can break automation. The agent is trying to infer an application's behavior from an interface that was designed for eyes and hands.
WebMCP moves that interaction from inference toward an explicit contract.
What a WebMCP tool looks like
A page can register a tool with a name, description, input schema, and execution function.
Here is a simplified example:
await document.modelContext.registerTool({
name: "search_emails",
description: "Search email metadata in the active mailbox.",
inputSchema: {
type: "object",
properties: {
query: { type: "string" }
},
required: ["query"]
},
execute: async ({ query }) => {
return searchMailbox(query);
}
});
The application still owns searchMailbox(). Its existing authorization, validation, business rules, rate limits, and audit behavior still apply.
The difference is that the agent can call a defined capability with validated arguments instead of reconstructing the workflow from the DOM.
The three-part interaction model
1. The page registers tools
The application exposes only the capabilities that make sense in the current context.
A public product page might register get_pricing. An authenticated workspace might expose list_mailboxes. A mailbox view could add search_emails and remove it when the user navigates away.
This is important: the tool surface follows the page lifecycle. The agent does not receive permanent access to everything the product can do.
2. The browser discovers them
A WebMCP-aware browser collects tools registered by the active page and presents them to a compatible agent.
The schema tells the agent what input is valid. The page state tells it which tools are currently available.
3. The agent calls a tool
The agent selects the capability that matches the user's request and supplies structured arguments. The application validates them, executes the operation, updates the visible UI, and returns a structured result.
The action still happens inside the application. WebMCP does not create a side door around the product.
Declarative vs. imperative WebMCP
WebMCP provides two ways to expose tools.
The declarative API annotates standard HTML forms. It is useful when the workflow already maps cleanly to a form and needs only a machine-readable name and description.
The imperative API registers tools with JavaScript. It fits dynamic applications, navigation, stateful workflows, and actions that need custom validation or execution logic.
If your product has a multi-step state machine, permission-dependent actions, or consequential operations, the imperative API will usually give you the control you need.
WebMCP is not MCP in the browser
The similar names can be misleading.
- MCP connects an AI application to services, backend systems, data sources, and workflows. It can work without a visible browser session.
- WebMCP exposes capabilities from the website currently open in the browser. Actions execute in the page's context.
They solve different layers and can complement each other. A product might provide MCP for direct service integration and WebMCP for browser-native collaboration with the user.
Why security has to be part of the tool design
Structured tools improve reliability, but a well-shaped schema is not a security boundary.
Treat every call as untrusted input and design for the consequence of the action.
Validate at execution time
The schema helps an agent construct a valid request. The application must still validate types, identifiers, permissions, state, and business invariants when the tool runs.
Keep results bounded
Return the smallest projection needed for the task. A search tool should not dump an entire mailbox or customer database into the agent context.
Treat page content as untrusted
An email, support ticket, document, or product description may contain instructions aimed at an agent. Content inside the application does not gain authority merely because an agent can read it.
Require visible confirmation
Sending a message, making a purchase, deleting data, or changing permissions should not happen silently. The application should show the intended action and let the user approve or cancel it.
Bind tools to context and lifecycle
Register a tool only while its required context exists. Cancel pending operations and remove obsolete registrations when navigation or application state changes.
A practical rollout strategy
WebMCP is still experimental, so treat it as a progressive enhancement.
- Start with read-only tools.
- Feature-detect the API and preserve the normal experience for unsupported browsers.
- Add bounded, low-risk operations before consequential ones.
- Put visible confirmation in front of outbound or destructive actions.
- Measure registration failures, validation errors, cancellations, and execution outcomes without logging sensitive payloads.
- Test whether agents select the right tool—not only whether the tool succeeds when called directly.
Chrome's documentation currently describes an origin trial and a local-development flag. The proposal remains under active discussion, so APIs and browser support may change.
What web developers should do now
You do not need to rebuild your product around agents.
Pick one workflow that browser automation handles poorly today. Define the smallest safe capability that would make it deterministic. Give it a precise name, a narrow schema, strict runtime validation, bounded output, and an explicit confirmation step when consequences extend beyond the current page.
The useful question is no longer only, “Can an agent click through this interface?”
It is: What contract should this application offer an agent acting for its user?
That shift—from interpreting pixels and DOM structure to invoking explicit, contextual tools—is why WebMCP deserves every web developer's attention.
