Two doors

01 the claimask agent

Most of the web’s visitors are about to be agents, and the page has to decide how to receive them.

An agent reading a page has to guess what to click. An agent given a tool only has to choose one.

An agent, an AI acting in your browser, uses a site the way a stranger would: read the page, guess which control does what, click, read again. Every step is a guess, and a guess can invent a button that is not there.

Hand it a short list of things it can do instead, each with a name, a description it reads, and a schema, a precise description of the input it needs, and the guess collapses into a choice. Get the choice right and the action is almost guaranteed.

That is the promise of WebMCP: a site registers tools, small named actions such as “place a player”, for whatever agent is driving the browser. The docs tell you how to register one. They do not tell you what it changes, so this post asks a narrower question: on a real task, with a real agent, how much does it matter?

If there is a complicated task I do by hand, I can set the right tools once, and then I can say it out loud and the agent gets it done.the sentence this post has to earn

02 play with itask agent

Pick the eleven for Saturday.

A small football app with fiddly rules, and a switch that decides whether the agent gets tools.

27 players, a formation to fill, injuries, suspensions, and a European list that differs from the league one. One commitment at the end: submit the team sheet. Try it by hand first. Then pick a door, press Run, and watch a recorded agent do it with what it could see.

03 two doorsask agent

Same task, same agent, one switch.

Both runs were recorded step by step, so you can see exactly what each door cost.

Through Door A nothing is registered: the agent reads and clicks like a person. Through Door B the page registers 11 tools and the agent gets the list. The page records every click, every call and every refusal as a trace, a saved record of the run.

Door A · clicks

28median

Door B · calls

17median

Door A · task met

6of 9 runs

Door B · task met

9of 9 runs

04 the scoreask agent

Where the DOM door gives out.

Through the page the agent handed in wrong sheets and was never told; through the tools it never did, and it was faster on every task.

The numbers here are minutes and wrong sheets, not clicks. Medium through the DOM: 0 of 3 met. 2 runs confirmed a sheet the page accepted with four over-cap starters on it, and the third declined because it could not know. Through the tools, 3 of 3, and no wrong action in nine runs.

From first action to confirm: 1.4, 4.3 and 3.6 minutes through the DOM against 1.1, 1.8 and 1.9 through the tools. The difference is the refusal loop: submit, be told, fix. The DOM agent only learns at submit, and only if the app refuses; the tool door made no wrong action because the report is one call and every runner made it first.

A team sheet is a small thing to get wrong. The failure is not. A DOM agent that submits a wrong sheet and is never told is the same agent that will confirm a wrong order, a wrong transfer or a wrong booking: whatever the page accepts without objecting. The page accepted it, so the agent reported success, and nobody was told. An agent acting on someone’s behalf has to act on reliable information, and a control on a page is not information about the rules behind it. Well-defined tools are: the rules as data before the first move, the availability report as one call, a refusal that names the article. That is what WebMCP registers on the page, and it is why the tool door was right 9 times in 9 with nothing refused, in less time on every task.the point of the post

That is how agentic browsing should work: a site that registers its tools is telling an agent what it can rely on, and the agent that asks before it acts is the one you would let act for you.

The harder the task, the wider the gap.

Rule density counts how many of the nine rules a task can get wrong: easy 3, medium 6, hard 7.

05 the toolsask agent

Three tiers, and a human at the last one.

Sorting tools by what they can do is what makes it safe to let an agent use them.

06 how it is wiredask agent

Five parts, no server.

A tool is code on the page: create it, register it, and the agent can find it and call it.

There is nothing to upload to and no key anywhere. Each trace is a JSON file the reader downloads, and the post’s figures are drawn from those files.

WebMCP, in four moves.

The page declares what it can do and the agent asks the list, not the pixels. The draft is moving; 07 says where.

1. 01Create

   A tool is four things: a name the agent matches on, a description the model actually reads and reasons about, a JSON Schema for the input, and an execute that runs in the page with the page’s own state and the user’s own session. No endpoint, no key. The description is the part people underwrite, and it is the part doing the work.

   tools.ts · one of eleven

   const placePlayer = {
     name: "place_player",
     // the model reads this. Write it for a reader, not for a linter.
     description: "Put a squad player into an open slot of the current formation.",
     inputSchema: {
       type: "object",
       properties: {
         player: { type: "string", description: "Squad player's surname." },
         slot:   { type: "string", enum: SLOTS },
       },
       required: ["player", "slot"],
     },
     // hints let a client sort read-only from consequential
     annotations: { readOnlyHint: false },
     // every execute is wrapped, so the recorder sees the call and the diff
     execute: async ({ player, slot }) => record("place_player", sheet.place(player, slot)),
   };

2. 02Register

   Feature-detect before you touch it: in stable Chrome it sits behind a flag or an origin trial, and a page that assumes it exists breaks for every reader who does not have it. The September draft has no unregisterTool: you pass an AbortSignal to registerTool, and aborting it is how a tool goes away, which is exactly what you want on a route change. Chrome’s early preview and the polyfill still carry older names, navigator.modelContext among them, so write to the draft and detect.

   registered from the root layout, so it exists on every route

   if (document.modelContext) {
     const teardown = new AbortController();
   
     await document.modelContext.registerTool(placePlayer, { signal: teardown.signal });
   
     // no unregisterTool. The signal is the lifetime.
     onRouteChange(() => teardown.abort());
   }

3. 03Discover

   This is the first thing the agent does, and the reason Door B is short: instead of guessing which control does what, it asks for the list and gets names, descriptions and schemas. Call it yourself from the console; it is the fastest way to prove your catalog is really registered rather than merely written. This page switched the panel to Door B when you got here, so the eleven are registered; through Door A the list below is the site’s own tools.

   what the agent asks first

   const tools = await document.modelContext.getTools();
   
   tools.map(t => t.name);
   // 28 tools: the site's 17 (list_pages, search, list_posts, …)
   // and the app's 11: ["get_squad", "get_availability", "get_rules", "get_team_sheet", …]

4. 04Call

   The call is the tool you found in the list plus an object that satisfies its schema. What comes back is a string, whatever your execute returned; parse it and it is structured, so the agent does not have to scrape the page to find out whether it worked. A refusal is a returned error, not a silent no-op, which is what makes the whole run recoverable. submit_team_sheet is the exception: it stops and asks a person, and that confirmation lives in the page.

   one call

   const tools = await document.modelContext.getTools();
   const place = tools.find(t => t.name === "place_player");
   
   const raw = await document.modelContext.executeTool(place, {
     player: "Gordon", slot: "LW",
   });
   const result = JSON.parse(raw);   // executeTool resolves to a string
   
   // { ok: true, slot: "LW", sheet: { filled: …, open: [ … ] } }
   // and on a rule violation, an error the agent can read and act on:
   // { ok: false, error: "not_on_european_list", player: "Raphinha" }

To try it today, run the polyfill, @mcp-b/webmcp-polyfill, or turn on chrome://flags/#enable-webmcp-testing. Tools are bound to the tab: close it and the catalog is gone, which is the property that makes this safe to put on a personal site.

07 where it breaksask agent

What this does not prove.

The runs are few and the API is young, but the real risk is words on a page giving the agent orders.

08 say it out loudask agent

“Pick the eleven for Wednesday.”

With the tools set once, the hard task is a sentence said out loud.

The last run is the one the post was for. The hard task, said out loud to the agent in the browser, with Door B open. It asked for the rules, asked who was available, filled the sheet, validated it, and stopped at submit to ask me. I said yes.

09 for your siteask agent

Tools that look things up. Then tools that can be undone. Then the one that waits for you.

Ship the read-only tools first; they are safe today and they are most of what an agent needs.

Tools that only look things up cannot break anything. Then add the ones that change the page, one job each, so another tool can always put it back. The last one is worth being careful about: spending money, sending a message in your name, submitting the team sheet. So that tool is built not to finish on its own. When the agent asks for it, the request appears on your site as something you have to press. The agent can propose. Only you can commit.

Two things decide whether that is real protection or just for show. The question has to appear on your page, not in the agent’s own chat window. If the agent is the one being asked, the agent can answer, and a permission something gives itself is not permission. And the label for these tools, consequentialHint, is only a warning. It tells the agent’s software that this one is serious; it does not stop it. A polite agent slows down and a rude one carries on, so the actual stop has to be code on your own site. The label announces the lock. It is not the lock.

Use your agent with this page.

Every section and figure has an ask agent button. Pick how deep to go (Explain it simply, Go deeper or How do we know?) and it copies a prompt about that part. Select a passage for a prompt about it. Paste it into any AI; a browser agent uses this page’s tools, and any other reads the plain-text version.