WebMCP charges browser-agent reliability to the web app team

Call `search_emails` and nothing exotic happens underneath. The browser has already collected the tools the active page registered and offered them to a compatible agent, with the schema describing valid input and page state deciding which tools exist right now ^[3]. The agent picks one and fills in structured arguments. The execute function calls the application's own `searchMailbox()`, so the authorization, validation, business rules, rate limits and audit behaviour already sitting in that path still run ^[5]. The app validates the arguments, performs the operation, updates the visible UI and returns a structured result ^[6]. According to the dev.to write-up, the design deliberately routes every action through the product's own code path, with no side door around it ^[6].

The failure being targeted is not model quality. Actuation agents inspect a page and simulate clicks, typing and scrolling ^[1], inferring behaviour from an interface built for eyes and hands: whether "Continue" submits or opens another step, whether the visible search box is scoped to the current mailbox, whether navigation has made everything the agent believed stale ^[8]. A redesign no human notices breaks the automation ^[7]. Better vision only sharpens that inference, making the guess more confident without removing it.

There is no benchmark here. The write-up asserts that structured tools improve reliability ^[14] and moves on, which is honest, but it leaves the reliability case as an argument rather than a measurement. A WebMCP-aware browser has to collect and present the registered tools ^[3], and the material names no shipping implementation and no standards track ^[18]. An agent has to prefer a declared tool over a screenshot when both are in front of it. And the workflow has to be expressible as bounded calls with schemas, which is precisely where the six-screen case gets expensive ^[7].

Four fields per tool ^[17] is a small enough contract that a product team can actually keep it current, and scoping the surface to the page means the capability model is navigation, which browsers enforce already. The return-value guidance deserves credit too: a search tool should not dump an entire mailbox or customer database into the agent's context, so return the smallest projection the task needs ^[16]. Do not confuse any of this with MCP, which connects an AI application to services and backends and can work with no visible browser session; WebMCP exposes only what the currently open site chooses to expose, executing in the page's context ^[13].

The declarative path is the cheap entry, a machine-readable name and description on a form you already ship ^[11]. If the workflow is one form, take it. If it is a permission-dependent state machine or a consequential operation, the write-up points you at the imperative API ^[12], and what you are shipping then is a public API with a UI attached: schemas to version, a projection policy per tool, and validation of types, identifiers, permissions, state and business invariants at execution time ^[15]. The mailbox example is five tools ^[19]. A real product's list is longer, and it is now on your roadmap rather than the automation vendor's.