# WebMCP: Give Browser Agents Tools Instead of Buttons > Source: > Published: 2026-08-30 17:12:23+00:00 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. Most browser agents rely on **actuation**: they inspect a page and simulate human actions such as clicking, typing, and scrolling. Every step adds uncertainty: 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. 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 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. 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. 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. 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. The similar names can be misleading. 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. 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. 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. Return the smallest projection needed for the task. A search tool should not dump an entire mailbox or customer database into the agent context. 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. 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. Register a tool only while its required context exists. Cancel pending operations and remove obsolete registrations when navigation or application state changes. WebMCP is still experimental, so treat it as a progressive enhancement. 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. 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.