What Is WebMCP? When to Expose Browser Tools to AI Agents

WebMCP lets a web app declare structured tools that a browser agent can call. As the WebMCP specification defines it, each tool runs inside the page with access to the user's authenticated session and current application state. That context supports actions tied to what the user already has open, such as updating the current cart, saving a draft on the active support ticket, or creating an issue in the selected workspace. On September 28, 2026, Shopify added checkout WebMCP tools that can read checkout state; update buyer details, fulfillment, discount codes, declared fields, and payment; and place an order after buyer confirmation. Shopify's checkout WebMCP changelog notes that its storefront and cart tools were already available. Cloudflare's WebMCP beta changelog says Browser Run extended support to Kitesurf that day and migrated Chrome Lab sessions from the earlier testing API to document.modelContext . WebMCP is still experimental. Its specification is a Draft Community Group Report. The project's implementation-status page lists origin trials in Chrome 149 and Edge 150, experimental Leo support in Brave, and ChatGPT Desktop support. It does not list Firefox or Safari implementations, so broad browser interoperability is not available. Use WebMCP for actions tied to the current browser session, an MCP server for capabilities that must run without the page, and browser automation when a site exposes no adequate structured agent interface. TL;DR - The WebMCP specification lets a page expose named, schema-defined tools to AI agents through the browser. - It is a good fit for session-aware actions such as searching a catalog, updating a cart, saving a draft, or changing the object open in the current tab. - It is a poor fit for unattended jobs, cross-service orchestration, or integrations that must work after the website closes. - Declarative WebMCP turns HTML forms into tools. Imperative WebMCP registers JavaScript tools through document.modelContext . - Treat it as progressive enhancement. The implementation-status page shows why the existing interface or API path must remain available while browser support is experimental. - Start with one read-only or reversible workflow. Do not make payment, deletion, publishing, or permission changes your first test. What is WebMCP? WebMCP is a browser API for exposing web application actions as structured tools. Each tool defines an action, its accepted inputs, its execution path, and what value, if any, execution returns. Imperative tools can also supply optional risk or debugging hints. The proposal has two authoring models: declarative metadata on HTML forms and imperative registration through document.modelContext . This contract lets an agent call an action directly rather than infer it from the DOM, accessibility tree, screenshots, labels, or layout. Chrome's WebMCP guide describes the structured path as more reliable and token-efficient than element-by-element navigation. The website remains the application surface. It keeps the state and business logic, while the browser exposes only the tools the page registers. How WebMCP works A typical flow has five steps: - The user opens and signs in to a web application. - The page declares or registers tools relevant to its current state. - A browser agent discovers the available tools. - The agent selects a tool and supplies arguments that match its schema. - The page executes the action. An imperative callback's serializable return value is passed to the caller; an invocation that navigates the page can resolve to null . WebMCP tools run in the page context, so they can use the session, account, cart, draft, route, or other frontend state already open. Declarative WebMCP Use the declarative API when the action is already represented by an HTML form. Add a tool name and description to the form, then describe the parameters on the relevant controls. form action: /catalog/search method: GET tool name: search_catalog tool description: Search products by query and maximum price. auto-submit: enabled query input type: search required: yes parameter description: Product name or feature to search for. maximum price input type: number minimum: 0 parameter description: Highest acceptable price in US dollars. The declarative API's toolautosubmit attribute lets the agent submit the form directly, which suits read-only searches. For payments, deletions, publishing, or permission changes, follow Chrome's security guidance and leave it off so users keep the existing review step. Declarative tools let people and agents use the same form, validation, and submission path. The team maintains one workflow for both. Imperative WebMCP Use the imperative API when the action depends on dynamic application logic or cannot be represented cleanly as a form. async function registerSupportDraftTool() { if (!("modelContext" in document)) return null; const controller = new AbortController(); await document.modelContext.registerTool({ name: "save_support_draft", description: "Save a draft reply for the support ticket open in the app.", inputSchema: { type: "object", properties: { ticketId: { type: "string", description: "The ID of the open support ticket." }, body: { type: "string", description: "The reply text to save as a draft." } }, required: ["ticketId", "body"] }, annotations: { readOnlyHint: false }, execute: async function ({ ticketId, body }) { const draft = await saveDraft({ ticketId, body }); return { draftId: draft.id, status: "saved", reviewRequired: true }; } }, { signal: controller.signal }); return controller; } The imperative API supports unregistration through an AbortSignal . In a single-page application, abort the existing registration and register a replacement when the route, selected object, or available action changes. const supportDraftRegistration = await registerSupportDraftTool(); // When the route, permissions, or state changes: supportDraftRegistration?.abort(); WebMCP vs browser automation vs a backend MCP server Choose the interface based on where the required state lives and how long the task must run. These layers can also be combined. Cloudflare's WebMCP beta shows how a browser-automation client can invoke WebMCP tools when a site exposes them and fall back to DOM, accessibility-tree, or visual interaction when it does not. | Approach | Best fit | Main advantage | Main tradeoff | |---|---|---|---| | WebMCP | Actions inside the current authenticated page | Reuses live browser state and lets the site define a stable tool contract | Experimental browser support and page-bound availability | | DOM or visual browser automation | Sites or workflows without an adequate structured tool interface | Works without cooperation from the product team | Depends on selectors, layout, visual interpretation, or other interface details that can change | | MCP server, usually remote for service-level integrations | Remote tools, background work, cross-client access, and service-level integrations | Runs independently of the page and fits MCP's client-server model | Requires a separate integration and may need explicit session or object context | MCP uses a host-client-server architecture. An MCP server can run locally or remotely and expose tools and other capabilities to a host through an MCP client. By contrast, WebMCP's page-level path does not require an MCP server, although a page tool may still call backend services. Browser automation covers sites with no WebMCP or API integration, including exploratory work and compatibility testing. Selectors, layouts, and visual cues can change, which makes the automation fragile. Chrome's comparison explains how WebMCP replaces that inference step with a contract defined by the product team. Apply the same rule to implementation: - Use WebMCP when the task depends on state in the current tab. - Use an MCP server when the state lives in a service or the task must work across clients. - Use browser automation when neither structured option exists, and budget for maintenance as the interface changes. Five signs that WebMCP fits your product 1. The current browser session matters WebMCP is useful when the user has already selected the relevant account, workspace, cart, ticket, document, or draft. The agent can act inside that context instead of reconstructing it through a second authentication and selection flow. Shopify's checkout WebMCP implementation shows the pattern. Its tools operate on the active checkout and cover reading state, updating checkout fields such as contact details, fulfillment, discounts, and payment, and placing the order after buyer confirmation. Cart-item changes remain the job of storefront or cart tools, or the checkout interface. 2. The action already exists in the interface A WebMCP tool should map to an existing interface action, such as searching the catalog, adding an item, saving a draft, creating an issue, or applying a filter. That shared path preserves a visible fallback and reuses the product's validation and business rules. Actions with no clear interface meaning usually need a narrower contract before agent use. 3. The user should remain close to the action WebMCP suits workflows where users need to inspect state before or after execution, especially payments, publishing, privacy, and access changes. Shopify's checkout tools require confirmation before completion. Apply the same boundary to consequential actions: let the agent prepare the change, while application policy and user approval govern execution. 4. The task has bounded inputs and a clear result Tools work best when their names, descriptions, schemas, and return values remove ambiguity. search_catalog is better than interact_with_store . save_support_draft is better than handle_ticket . Chrome's WebMCP best practices recommend concise descriptions, focused tools, and dynamic registration based on the current application state. If you need a long prompt to explain what a tool might do, the actio