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.
Why screen-driven automation is fragile
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:
- button labels change
- a responsive layout moves controls
- a modal covers the next step
- the page renders differently for another account
- an A/B test changes the interface
- an action has an important side effect that is not obvious from the label
A structured tool gives the browser and agent a clearer contract.
The basic WebMCP model
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:
- The website registers
bookSlot. - The tool describes required fields such as date, time, name, and email.
- The browser presents the tool to an agent within the page's origin and permission context.
- The agent asks for or confirms the required information.
- The website's own code performs the booking.
The agent does not need to guess the DOM path to a submit button.
Declarative tools for existing forms
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.
Imperative tools for application actions
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.
Security responsibilities do not disappear
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:
- authenticate and authorize on the server
- validate every input again on the server
- make read-only and state-changing actions easy to distinguish
- require confirmation for purchases, deletion, publication, or account changes
- return the minimum necessary data
- log important tool calls for audit and debugging
- use idempotency protection for actions that must not run twice
Never assume that a tool is safe because it was called through a browser agent.
Start with narrow, high-confidence actions
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:
- search public documentation
- check an order status
- calculate a quote without purchasing
- find available appointment times
- save a draft without publishing it
These actions are easier to test than a broad tool that hides many decisions.
How to evaluate a WebMCP tool
Test more than the happy path.
Ask whether the agent:
- chooses the tool for the right user request
- avoids it for unrelated requests
- asks for missing required information
- rejects invalid values cleanly
- explains a failure without inventing a result
- requests confirmation before a consequential action
- behaves correctly when the user is signed out or unauthorized
Chrome's developer tooling and Lighthouse work around WebMCP are useful for inspecting registered tools, but application-level tests are still necessary.
A practical adoption plan
- Keep the existing human interface fully functional.
- Select one narrow action.
- Define a clear name, description, and input schema.
- Reuse existing server authorization and validation.
- Add confirmation for meaningful side effects.
- Test successful, invalid, unauthorized, cancelled, and repeated calls.
- Treat the implementation as experimental while the API and browser support evolve.
Conclusion
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:
