Navya Agarwal watched her web app slow every time an AI agent used it: it screenshotted the page, guessed which pixels were a button, clicked, then screenshotted again — two to five seconds per action. Writing in InfoWorld on 7 July, she describes what happened once she let it read the page’s accessibility tree instead: under 500 milliseconds per action, token cost down an order of magnitude. That’s the promise behind WebMCP , the origin trial Chrome opened in June, and behind Shopify switching agent-callable tools on for every Liquid storefront by default on 5 August, nothing to install or opt into. Skip the guessing and an agent gets typed, declared instructions for what a page can do. What nobody guarantees is that those instructions keep meaning what they say: a site now carries two descriptions of itself, one for people who click, one for agents that call functions, with nothing forcing them to match.
A second definition nobody has to keep honest
Standards bodies noticed the gap early. WebKit’s standards-positions tracker
records a position: oppose on WebMCP under a concerns: duplication label — a formal way of saying a separately maintained tool registry is a second definition of what a product can do, and nothing obliges it to stay true to the interface it mirrors. Mozilla’s parallel request
landed on neutral instead — telling, because it isn’t agreement: the engines rendering the web haven’t settled this.
For whoever owns the components, that becomes a second job. A design-system engineer who moves an eligibility check into a button’s click handler hasn’t broken anything visible — the button still works. But the tool description in the agent registry, which promised that action was always safe to call, is now quietly wrong, with nothing rendering red to flag it — the same burden a survey of 157 coercion techniques across 20 design systems found teams already carrying, correcting an agent’s memory of a superseded API. Merchants on a Liquid storefront never chose this; Shopify’s tools simply went live, “nothing to install or configure.”
A separately maintained tool registry is a second definition of what a product can do, and nothing obliges it to stay true to the interface it mirrors.
Nobody has published a number for how often a declared tool drifts from the interface it describes — the load-bearing sources measure something else. Affora measured agent task performance against the interaction meaning an interface exposes; WebKit’s tracker records a concern, not an audit of a shipped registry. Read across from a model where one definition lives in markup and the other in a separate schema, though, the risk doesn’t need an incident to be visible: two accounts of one button, on different schedules, with nothing enforcing they agree.
Shopify’s cart tools quietly side with the critics
The biggest shipped implementation points the other way, though. Shopify’s 5 August changelog
turns on tools like search_catalog, get_cart, update_cart and proceed_to_checkout for every Liquid storefront, stating that “cart tools call the same standard storefront actions that apps use, so if your theme opens a cart drawer on updates, agents trigger it too.” That’s the thesis made visible: the agent surface is a second caller into the same code path, not a second implementation of it — a merchant can read the changelog and see which tools got switched on in their own store.
A design-system paper posted on arXiv on 16 September argues this is the route worth generalizing. Jin Gao’s Affora proposes connecting “user experience and agent experience through a shared interface rather than a separate agent-only surface,” and across three controlled studies plus an evaluation on independent interfaces, found agent performance tracked the interaction meaning already available in the interface itself. It echoes the fork MCP Apps’ rendering debate drew a year earlier: shared theming versus separate agent rendering. Affora is a single-author preprint, not consensus, but it argues the humbler position — better markup, not a parallel registry, may cover most of what agents need.
What the accessibility tree still can’t promise
Chrome’s own pitch contains an admission worth weighing: an accessibility tree says what a control is — a button, a field — not what it does, under which preconditions, or with what effect. InfoQ quotes a developer sharpening the point: “If a refund workflow is callable but the refund policy is stale, the agent can execute the wrong action cleanly.” A synchronized button and tool description doesn’t help if the rule behind either is stale — a problem no interface design alone resolves, as a benchmark of agentic accessibility auditors found, measuring how much a read-only check still misses.
Affora’s own evaluation cuts the same way: its improvements appeared on interfaces with an existing deficit in exposed interaction meaning, “limited where deficits were absent or outside the system’s scope.” A good human interface doesn’t by itself resolve the precondition problem typed tools exist to answer — leaving WebKit’s opposition, a standards position rather than a refutation, on one side of an argument between engines, not a settled verdict.
None of this gets resolved by a config flag. Chrome’s trial, Shopify’s rollout and Affora’s counter-proposal are three bets, running at once, about where the meaning of a button should live: in markup anyone can inspect, or in a registry only agents read. Agarwal’s agent got fast the day it stopped guessing at pixels. Whether it also stayed honest is a question the industry hasn’t yet built a way to check.
