A customer with a billing question lands on a support hub, picks the second-closest form, and types the problem into a field that triage ignores. Chrome's example for WebMCP is that exact flow: an agent gets steered to the right form and fills it with details the user already gave in conversation [12]. That scope is real work, but it is narrower than the phrase agent-facing interface implies: the agent is routing and filling, not deciding on the user's behalf.
The documentation's own discoverability limitation cuts off before it reaches an answer. The passage Chrome labels tool discoverability opens with the words "clients and browsers must visit a sit", at which point the published documentation stops mid-word [10]. Whatever finishes that sentence, the mechanism begins with a browser that already has your page loaded, so WebMCP moves completion odds inside sessions you already have rather than adding sessions.
The example tool names are the clearest statement of intent in the doc. Five appear: checkout and filter_results as discovery examples, then submit_application, date_pick and run_diagnostics in the use cases [4][13]. Three of the five wrap something a human already operates, including a date_pick tool for complex date and time selection in a booking flow; two expose capability the interface buried, and run_diagnostics is described as triggering fixes otherwise hidden behind nested menus [1][13]. The second pair is where product teams should look, because a tool list is a chance to publish the functions your own navigation hides.
Two APIs means two owners. Annotating standard HTML forms lands on whoever owns the markup; defining tools in JavaScript for form input, navigation and state management lands on whoever owns application state [7]. Chrome adds that a highly complex site will likely need refactoring or new JavaScript to track application and interface state [9], which is the documentation's way of saying that a real tool surface has to function as a state machine.
Chrome claims WebMCP can significantly improve the performance and reliability of agent actuation and offers higher accuracy for agentic task completion [2], and publishes no figure for either [2]. The number an origin trial hands you cheaply is tool calls per session, which says nothing about whether the user got what they came for. Two others are worth the instrumentation: completion rate on the tool path against the click path for the same task, and the share of tool completions a human had to undo.
A sort that survives a sprint plan uses two axes: whether the action is reversible, and whether its state lives in a form or in your app. Reversible and form-shaped (search, order lookup) is the annotation quadrant, cheap because the fields exist already. Irreversible and form-shaped, such as submitting an application, is annotation plus the command Chrome provides to request a user confirmation dialog before a sensitive action [11]. Reversible and state-shaped earns an imperative tool only where you already own the state machine it needs. Irreversible and state-shaped is checkout, which waits for the completion figures Chrome has not yet published [2].
