Auto Browser 1.5: WebMCP page tools now follow your permission settings.

Auto Browser 1.5 is mostly a WebMCP release. Our v1.4 post covered the previous release, multi-tab orchestration.

---

What WebMCP is

WebMCP lets a website give an AI agent its own tools. Each tool has a name, a description and a list of the inputs it expects. When a page offers tools, Auto Browser uses them in place of clicking around the page, because the site’s own tool is usually more reliable.

It also means the agent runs code the website wrote, while you’re signed in, and passes what that code returns to the model.

WebMCP is still a draft, written by the W3C Web Machine Learning Community Group. Chrome supports it natively only behind an origin trial or a flag, so most people use a Chrome without it. On those browsers, Auto Browser provides its own WebMCP support, which we call the fallback. We tested both cases against the current draft and against Chrome 149 to 156.

---

Page tools follow your permission settings

Every page tool call now goes through the same permission check as a click or a navigation. Your permission mode, per-turn auto-approve, saved grants and the blocked-sites list all apply.

These rules stop a page from getting around that check:

• A page can label its tool as read-only or harmless. The agent passes those labels to the model, but ignores them when deciding whether to ask you.
• A page tool can’t borrow the permissions of a built-in tool by using the same name. A page tool called scroll is still checked as a page tool.
• The built-in tools that ask you questions, read the page, run scripts or answer dialogs can’t be replaced. A page tool that tries to take one of those names is dropped. Pages can still replace general tools such as form filling, which is what WebMCP is for.
• A tool inside an embedded frame is checked against the blocked-sites list by that frame’s own site. A blocked site can’t offer tools through an iframe on a site you allow.
• If the frame has moved to a different origin between your approval and the call, the call is refused.
• If the model asks for a tool that doesn’t exist, the call fails without showing you a prompt.
• Calls to a tab in the background are refused. Chrome slows background pages so much that the call would only time out.

---

How the agent reads a page tool’s result

A page tool’s result is written by the website. The agent marks it as page output, and its instructions tell the model that this text comes from the site. Anything in the result that looks like Auto Browser’s own internal messages is neutralised, and each result is capped at 16,000 characters.

Sometimes the agent can’t tell whether a tool ran. This happens when a call times out after 30 seconds, when the page returns an unclear error, or when the connection drops mid-call. The error message then says the tool may have run, and the model is told to check the page before trying again. The v1.4 resume rule is enforced in code, while this one relies on the model following its instructions.

Two smaller changes:

• Stop now cancels page tools that are still running, on every tab the agent is using.
• If one tool on a page has a broken description, only that tool is dropped. The others still work.

---

Our fallback now follows the current spec

On browsers without native WebMCP, pages talk to our fallback. We rewrote it to match the current draft:

• It lives at document.modelContext, with the interfaces and events the spec defines. Nothing is added to navigator, which matches Chrome. Chrome removed navigator.modelContext in version 152.
• registerTool and executeTool check their input and report errors the way the spec describes.
• A page can cancel a tool call with an abort signal, before or during the call.
• It also works in about:blank, srcdoc, document.write and sandboxed frames.

Pages written to the spec work with it, and so do helper libraries such as MCP-B’s @mcp-b/global.

The spec still has a few open questions. Where Chrome has already picked an answer, we follow Chrome. We ran the same tests against our fallback and against Chrome 156’s native WebMCP. The results match, apart from four things:

• the wording of error messages;
• one property on events;
• one error that Chrome 156 names differently (the spec and Chrome 158 use the same name we do);
• the tools Permissions Policy, which the fallback doesn’t check.

---

Forms are filled, then submitted with a normal click

WebMCP also lets a page turn a form into a tool by adding a toolname attribute. This is described in the WebMCP explainer, but it isn’t part of the spec.

On browsers without native WebMCP, a form tool now fills in the form but doesn’t submit it. The agent then clicks the submit button, and that click goes through your permission settings like any other. The browser’s own form checks and the site’s own submit code then run as they would if you clicked.

The agent also:

• checks that every value fits the form before writing anything, and leaves the form unchanged if one doesn’t;
• enters values in a way that sites built with frameworks such as React pick up;
• leaves disabled fields, read-only fields and hidden fields without a description out of the tool.

The downside is that a form marked to submit automatically (toolautosubmit) takes two steps, and a result the page sends back through respondWith isn’t captured. On Chrome with native WebMCP, Chrome handles these forms itself.

---

Native WebMCP through Chrome’s DevTools protocol

On Chrome with native WebMCP turned on, Auto Browser now finds and calls page tools through Chrome’s DevTools protocol, from the extension’s background worker.

Code that runs inside a page can be seen and changed by that page’s own scripts. A site could read what the agent sends, answer a call itself, or swap the tool list. The DevTools protocol works from outside the page, where page scripts can’t reach it.

It also avoids a Chrome bug that crashes the tab. On Chrome 150 to 156 with native WebMCP on, the crash happens when Auto Browser reads document.modelContext and the page also reads it from a second document, as Partytown does. Chrome 157 fixes this. The DevTools protocol doesn’t trigger it.

Working through the DevTools protocol also means:

• tools inside cross-origin iframes can be reached, when the top page has native WebMCP;
• the agent sees the page’s real error message, where native WebMCP before Chrome 158 reports only UnknownError;
• Stop cancels a running tool (in about 300 ms, in our tests on Chrome for Testing 153).

The DevTools protocol isn’t always available: on Chrome 149, after a failed connection, or after you close the debugging bar. In those cases Auto Browser reads native WebMCP from its content script, where page scripts can’t tamper with it. Chrome changed the input format executeTool accepts in version 155. Auto Browser checks which format the browser expects and never retries a call in the other format, because a retry could run the tool twice.

We tested this on Chromium 152, Chrome for Testing 153 and Chrome 156. The full test suite now has 2,919 tests.

While the agent is working on a page with native WebMCP, Chrome shows its “being debugged” bar. Auto Browser keeps the connection open for three minutes at a time, enough to cover a model call and your approval. Closing the bar switches that tab to the content-script method above. On browsers without native WebMCP, which is most of them, Auto Browser doesn’t connect the debugger to look for page tools.

Known limits:

• The agent only looks for native tools when the top page has native WebMCP. An iframe that turns WebMCP on by itself, inside a page that doesn’t, isn’t found.
• Some embedded frames’ tools aren’t seen if they were registered before the agent connected, and they’re lost when the page is restored from the back/forward cache.
• The content-script method still reads document.modelContext, so on Chrome 150 to 156 it can hit the crash above. It’s only used when the DevTools protocol isn’t available.

---

Also in the 1.4 updates

The 1.4.x updates after our last post also included these changes:

• Script approval. Before running JavaScript on a page, the agent has to say in plain words what the script is for. The approval prompt shows that above the code. Approving clicks for a turn doesn’t cover running scripts; scripts need their own approval. Settings has a “Run scripts without asking” switch with a warning, and blocked sites stay blocked.
• Gemini 3. Gemini 3 models use a different thinking setting from Gemini 2.5. Auto Browser now sends the right one for each model, which fixes answers that were cut off and reported as “unparseable output”. Requests that Google rejects (400, 401, 403, 404) are now reported as errors and not retried.
• Streaming. Responses from OpenRouter, Gemini and local models are read one complete event at a time, following the standard server-sent events format. If a response breaks off or contains something unreadable, the agent stops and doesn’t act on the partial answer.

---

Try it

Auto Browser 1.5 is on the Chrome Web Store. If you build pages with WebMCP, tools added with registerTool and form tools both work with Auto Browser, with or without native WebMCP. The spec is at github.com/webmachinelearning/webmcp. If your tool behaves differently in Auto Browser than in Chrome’s native WebMCP, beyond the differences listed above, let us know.

---

Previous posts in this series: multi-tab orchestration · the perception rewrite and the eval.