Watch the confidence numbers while you type "gluten free" into a Chrome side panel. They move mid-word.
On every keystroke, the panel picks the relevant tool on the page, fills in the arguments, and tells you how sure it is — before any chatbot turn, before you finish the query. Underneath, a small decision model is answering one question: which tool, which args?
That's Sarah Drasner's extension, built over a weekend, published with a grocery demo site and a Chrome flag standing between you and trying it yourself. Her example query is the whole case for a non-chat interface: "got anything gluten free for under two dollars?" doesn't need a conversation, it just needed search_products.
Her example query is the whole case for a non-chat interface: "got anything gluten free for under two dollars?" doesn't need a conversation, it just needed search_products.
Jev can't write words. It answers typed questions: pick one, yes or no, how much. Paired with WebMCP, that turns out to be plenty.
Last week this column asked whether the WebMCP working group would settle on a precise test for what counts as "consequential" — the line where an agent has to stop and ask a human. This week, independent builders shipped real extensions, and a different test surfaced in practice: description precision, measured live, per keystroke.
The surprise isn't that an agent can drive a site. The explainer makes that case cleanly enough — roughly 40+ DOM nodes to parse become 3 tools, called directly, no screenshots and no guessing at the DOM. The page hands over a menu of named tools with described params and enums.
The surprise is that the side panel turns description quality into visible behavior. You can watch the seam.
Two tools fighting over one sentence, the probability seesawing across a phrase: your descriptions overlap. An argument that comes back shaky, half-filled, hedged: your schema is vague. Showing confidence per tool is the clever bit, because it converts the agent from a black box into something you can actually debug.
That's the reframe. Tool descriptions are not documentation. They are the control surface for an agent-readable site.
On the declarative path, that surface is three HTML attributes: toolname, tooldescription, toolparamdescription. On the imperative path, it's name, description, and a JSON Schema — the same shape as a server-side MCP tool. Either way, a model reads each word to decide whether to call, and reads the schema to decide what to put in.
That makes authoring a craft with rules, and Drasner's rule is blunt: write these like a good commit message, not a README. Short, because long descriptions pollute context windows. Positive framing: "Searches products by keyword." Not: "Do not use this for orders."
The negative example is instructive because it fails as engineering, not etiquette. "Do not use this for orders" puts the word orders into the same token neighborhood as your checkout tool's description, in a decision that is only ever a choice among siblings. You spent tokens seeding the wrong