WebMCP, still experimental, suits session-scoped tools that keep the user's confirmation step

An agent call runs in five steps, according to the dev.to guide ^[9]:

1. The user opens the web application and signs in. 2. The page declares or registers tools that fit its current state. 3. A browser agent discovers the available tools. 4. The agent picks a tool and passes arguments that match its schema. 5. The page executes the action.

Step five needs design attention. A tool that submits a form and redirects can leave the agent with nothing to check. An imperative callback's serializable return value goes back to the caller, but an invocation that navigates the page can resolve to null ^[10].

The boundary is drawn well. The site keeps its state and business logic, and the browser exposes only the tools the page registers ^[17]. Each tool declares its action, its accepted inputs, its execution path and what it returns. Imperative tools can also attach optional risk or debugging hints ^[8]. An agent can reach only what the page registers, and it acts with the authority of whoever is signed in ^[1][17].

The guide's declarative example is a safe first tool. It is a GET form with action /catalog/search, registered as search_catalog, with a required query field, a maximum-price field with a minimum of 0, and auto-submit enabled ^[12]. Auto-submit is fine there because a search changes nothing ^[11].

Shopify reached checkout last. Its storefront and cart tools were already available before the September 28 release ^[3]. The guide recommends the same order: one read-only or reversible workflow first, with payment, deletion, publishing and permission changes kept out of the first test ^[16]. The checkout tools can change buyer details, fulfillment, discount codes and payment, and they hold the order itself until the buyer confirms ^[2].

Chrome's WebMCP guide calls the structured path more reliable and more token-efficient than element-by-element navigation ^[13]. The dev.to piece cites no figure for either claim. For the claim to hold on a given site, the agent's tasks have to fall inside the registered schemas. A task outside them puts the agent back to inferring actions from the DOM, the accessibility tree, screenshots, labels and layout ^[14].

My context is a single web app with a working UI and no separate agent API. There I'd register tools only for the object open in the current tab and keep the existing interface as the fallback ^[16]. Unattended jobs, cross-service orchestration and anything that must run after the tab closes go on an MCP server ^[15].