Browser agents need a better interface than screenshots and brittle DOM clicking. A purely visual agent has to infer which controls matter, synthesize coordinates, wait for the page to change, and recover when a button moves or a form is restyled. WebMCP reframes the page as a set of explicit tools that the browser can expose to an agent on the user’s behalf.
The core idea is simple: the website describes its actionable capabilities, and the browser mediates tool discovery, parameter filling, execution, and user consent. Chrome’s early preview describes two integration paths. The declarative path annotates ordinary HTML forms so the browser can synthesize a JSON Schema. The imperative path registers JavaScript tools through navigator.modelContext.registerTool() for workflows that do not fit a single form.
This topic focuses on the transferable engineering pattern rather than a single browser release. The pattern is useful whenever an agent acts inside a user session: ecommerce configuration, customer-service workflows, travel search, dashboards, and internal tools. The goal is to keep human UI semantics and agent tool semantics aligned without handing an LLM unbounded control over the page.
A WebMCP-style page advertises operations as named tools with descriptions and typed inputs. Instead of asking an agent to inspect pixels and infer that a search form accepts a destination, dates, and passenger counts, the page can expose a schema that says exactly which fields exist, which are required, and which values are allowed.
The browser sits between the agent and the website. That matters because the browser already owns the user session, origin security model, form submission behavior, and permission UI. A tool call can execute in the active page context without sharing passwords with the agent or requiring the site to open a separate public automation API.
Declarative tools are best for existing forms: search, checkout, booking, preferences, filters, and feedback flows. Imperative tools are better for dynamic actions such as reading the current cart total, invoking a multi-step client workflow, or calling an application service that has no visible form.
If an operation is already represented by a form or user action, the agent-facing tool should be defined beside that operation. This reduces drift between what a human can do, what the browser can validate, and what an agent is allowed to request.
The declarative model adds tool metadata to HTML. The browser reads the form-level name and description, scans form-associated controls, and derives a schema from input types, required attributes, select options, and parameter descriptions. The same form remains usable by humans, so the agent interface is progressive enhancement rather than a separate automation surface.
<form
method="post"
action="/reservations"
toolname="book_table"
tooldescription="Book a table for a date, time, and party size">
<input
name="date"
type="date"
required
toolparamdescription="Reservation date">
<select
name="party_size"
required
toolparamdescription="Number of guests">
<option value="2">2</option>
<option value="4">4</option>
</select>
<button type="submit">Reserve</button>
</form>From those semantics, the browser can expose a tool with required fields and constrained values. Some implementations also include testing APIs so developers can inspect which tools were registered and debug missing attributes or unsupported contexts.
JavaScript registration gives the application explicit control over schema, validation, and execution. The important design rule is to keep the tool narrow. A tool named perform_checkout with a vague free-text input is dangerous; a tool named apply_shipping_option with an enum and clear user-confirmation boundary is much safer.
if ("modelContext" in navigator) {
await navigator.modelContext.registerTool({
name: "apply_shipping_option",
description: "Select one available shipping option for the active cart",
inputSchema: {
type: "object",
properties: {
option_id: {
type: "string",
description: "Identifier returned by the shipping-options view"
}
},
required: ["option_id"]
},
execute: async ({ option_id }) => {
return await cart.applyShippingOption(option_id);
}
});
}Search and configuration forms are the easiest starting point. A travel site can expose origin, destination, dates, seat class, and passenger count as typed parameters. An internal admin console can expose filters, report exports, and support-ticket creation without forcing an agent to manipulate low-level DOM state.
Many valuable actions only make sense inside a signed-in browser session. Browser-mediated tools let the site reuse existing cookies, CSRF defenses, and authorization checks while still giving the agent a structured action surface. The agent requests an action; the browser and application enforce whether that action is available to the current user.
Traditional browser automation often breaks when layout or selectors change. A tool interface is tied to application semantics instead of presentation details. Teams can version, test, and observe tools like API endpoints even when the human-facing UI continues to evolve.
Use form annotations for operations that already submit data. Move to imperative registration only when a workflow needs computed options, a client-side callback, or state that cannot be captured by form controls. This keeps most agent support readable to ordinary web developers.
function registerReportExportTool(reportState) {
if (!("modelContext" in navigator)) return;
navigator.modelContext.registerTool({
name: "export_report",
description: "Export the currently visible report in an allowed format",
inputSchema: {
type: "object",
properties: {
format: { type: "string", enum: ["csv", "json", "pdf"] }
},
required: ["format"]
},
execute: async ({ format }) => {
if (!reportState.canExport) throw new Error("export is disabled");
return reportState.export(format);
}
});
}Classify tools by risk. Read-only tools can often run after a broad user grant. Mutating tools should have confirmation boundaries, clear descriptions, and server-side authorization. High-risk actions such as purchase, deletion, data sharing, or account changes should require explicit user review even if the agent assembled the parameters.
Treat tool descriptions and schemas as public contracts. Add browser tests that assert the expected tools exist, required fields are present, enums match the UI, and unsupported browsers degrade gracefully. If a field disappears from the human form, the agent schema should fail a test instead of silently drifting.