AI agents can already operate websites by reading text, inspecting accessibility trees, and clicking visible controls. That works, but it asks the agent to reverse-engineer an interface designed for humans.
WebMCP proposes a different model: a website can expose supported actions as structured tools. Instead of guessing which button completes a booking, an agent can discover a bookSlot
tool with a description, typed inputs, and a defined result.
WebMCP is currently an emerging Chrome capability and origin-trial technology, not a cross-browser production standard. That makes it useful to study and experiment with, but too early to use as the only path for an important workflow.
A human can look at a page and understand that “Continue” advances a checkout. An agent has to infer that meaning from surrounding text and interface state.
That approach can break when:
A structured tool gives the browser and agent a clearer contract.
A site registers tools. Each tool has a name, description, input schema, and implementation. A compatible browser can expose those tools to an agent, and the agent supplies structured arguments.
For a consultation form, the conceptual flow looks like this:
bookSlot
.The agent does not need to guess the DOM path to a submit button.
The declarative API is designed for standard HTML forms. A form can be annotated with a tool name and description while its controls become tool parameters.
<form
action="/consultations"
method="post"
toolname="book_consultation"
tooldescription="Book a 30-minute consultation slot"
>
<label>
Date
<input name="date" type="date" required>
</label>
<label>
Email
<input name="email" type="email" required>
</label>
<button type="submit">Book</button>
</form>
The important idea is progressive enhancement. The form should remain a real, usable form for people and browsers that do not support WebMCP.
Some actions do not map neatly to one form. The imperative API lets application code register a tool with a JSON schema and an execute function.
document.modelContext.registerTool({
name: "checkOrderStatus",
description: "Return the latest status for an order owned by the signed-in user",
inputSchema: {
type: "object",
properties: {
orderId: { type: "string" }
},
required: ["orderId"]
},
execute: async ({ orderId }) => {
return await api.getOrderStatus(orderId);
}
});
The tool should call the same trusted application layer used by the normal interface. WebMCP is an interaction surface, not a replacement for authorization or business rules.
A structured action can be more reliable than screen scraping, but it can also make a sensitive capability easier to invoke. Treat every tool call as untrusted input.
Good rules include:
Never assume that a tool is safe because it was called through a browser agent.
The best first tool is usually not “control my entire application.” Choose one action with clear inputs, predictable output, and an existing server-side permission check.
Useful candidates include:
These actions are easier to test than a broad tool that hides many decisions.
Test more than the happy path.
Ask whether the agent:
Chrome's developer tooling and Lighthouse work around WebMCP are useful for inspecting registered tools, but application-level tests are still necessary.
WebMCP points toward a web where agents do not have to guess how every interface works. Sites can expose supported capabilities as explicit tools while preserving their normal human-facing experience.
The opportunity is not to give agents unlimited control. It is to make a small set of user-approved actions clearer, safer, and more reliable.
Sources: