AI ASSISTANTS · WEBMCP
WebMCP tools
in a Chrome extension.
WebMCP lets a page hand an AI agent in the same browser a set of named tools with JSON schemas. While a LilLabr panel is open in Chrome’s side panel, web pages in that browser register five such tools, so an agent can start a capture and save the file without clicking through the interface. Here is what they do, who can use them today, and what they deliberately cannot do.
What WebMCP is.
WebMCP is a Chrome proposal that gives a web page a document.modelContext object on which it can register tools: a name, a description, a JSON schema for the arguments and a function to run. An AI agent that runs in the same browser can list those tools and call them instead of guessing at buttons. LilLabr uses it as an addition, not a dependency: a browser without WebMCP, or with it turned off, never notices, because no tool is registered and nothing else changes.
In Chrome, LilLabr’s tools are registered from the page world by a small script the extension injects into pages only while a LilLabr panel is open for any tab (a panel hidden behind another tab counts), and withdrawn when the last panel closes. A tool call is relayed to the extension’s background worker, which checks the sender on every message.
Who can use these tools today.
Not everyone, and not “install and go.” Three things have to be true at once: the browser exposes WebMCP, the AI product reads a page’s WebMCP tools, and the LilLabr extension is running in that same browser. As of 6 October 2026:
| Combination | Works today | Why |
|---|---|---|
| Ordinary Chrome Stable with any AI | No | WebMCP is not on by default. It runs behind the chrome://flags/#enable-webmcp-testing flag from Chrome 146, a launch flag from Chrome 150, or a Chrome 149 to 156 origin trial. Without it, nothing registers and LilLabr behaves as before. |
| Chrome with the flag and Gemini in Chrome | Not yet confirmed | Google has said its agent will read page tools “soon,” without a date. |
| Chrome with the flag and Claude in Chrome | Not by WebMCP | Its discovery of page tools was an open request as of July 2026; it falls back to screenshots and the page. It could press the panel’s buttons like a person, but LilLabr has not tested that. |
| Chrome with the flag and a developer bridge | Yes | A bridge extension or a tool inspector reads the registered tools. LilLabr’s own checks go this far: its real-Chrome test calls the tools through Chrome’s own getTools() and executeTool() in Chromium 151, and a Claude agent has used them through a stand-in bridge. No shipped AI product has been tested against them. |
| The ChatGPT desktop app’s built-in browser | Unverified, probably not | It exposes WebMCP, but it is its own browser, and whether it can run the LilLabr extension is not known. |
Until an agent product reads WebMCP tools in a browser that runs the extension, the dependable ways for an AI to use LilLabr are the panel’s own buttons, a bridge, or the local MCP server, which works with Claude Desktop, Claude Code, Cursor, Codex and the ChatGPT desktop app. Claude on the web or phone and ChatGPT on the web cannot run a local program; for them LilLabr 1.0.6 adds a hosted connector link, set up from the panel with a Google sign-in, which passes captures through LilLabr’s cloud.
The five tools in Chrome.
| Tool | What it does | Notes |
|---|---|---|
lillabr_get_status | Whether a capture is running, whether the Privacy Policy and Terms box is still unticked, what the latest capture on this device is (mode, size, layer, text and image counts, warnings, whether it can be copied or saved) and whether Save captures is on. | Read-only. Counts and flags only; no page title, address or content. |
lillabr_capture_screen | Captures what is visible in this tab. | Paced: one at a time, at least 3 seconds apart, only in the tab that is in front. |
lillabr_capture_full_page | Captures the whole loaded page. | Same pacing. |
lillabr_pick_element | Opens the element picker and returns at once; the person clicks the element. | The agent cannot pick for you. |
lillabr_save_capture | Saves the capture the agent just made as a .labr file with a plain download into the browser’s download folder, the same as the panel’s Download capture. | Returns the file’s name only, never its contents or path. At most 20 saves an hour. An agent can save only a capture its own request made on that tab. |
If you have not agreed to the Privacy Policy and Terms yet, a capture tool fails with a message telling the agent to ask you to tick the box in the panel and capture a page, because the agreement is recorded when you press Capture full page. A tool call never agrees for you. Expected failures are returned as a readable result rather than thrown, because Chrome hands an agent only a generic error for a thrown one.
What stays with you.
- A capture moves nowhere on its own. An agent-started capture is prepared and held on this device. It does not write the clipboard, does not download a file and does not upload, even with Save captures on; the panel says the capture stayed on this computer and offers Save capture for you to press.
- There is no copy or upload tool. The only way a file leaves is the save tool, a plain download of the agent’s own capture, which lands wherever your Chrome saves downloads.
- Your own captures are out of reach. A capture you made is never reachable by a tool.
- Nothing counts toward review prompts. Agent captures are not counted.
- It is on while a panel is open. There is no switch in the panel; the popup behind the Privacy Policy and Terms box says so, and closing the last panel withdraws the tools.
A saved .labr is a store-only ZIP, so an agent on the same computer can read it with any unzip tool. How to read a .labr file.
The Figma plugin registers tools too.
LilLabr Import registers seven tools when it starts: read the import status, list synced captures and flows, set the two import options, import one capture, a whole flow or the file already loaded, and cancel. They run the same code as the plugin’s buttons, so verification, rollback and counters behave identically, and the import tools are marked consequential because they add layers to the open file. There is no tool to delete a synced capture, change the Chrome connection or read a capture’s contents.
Whether any agent can reach them depends on the host. In Chrome 151, a plugin interface running in a sandboxed frame, which is how Figma runs plugin interfaces, registers its tools but the embedding page sees none of them. So today the plugin’s tools are useful for testing and for a host that does not sandbox the interface, and are inert in Figma Desktop.
Threat model.
These tools are on for every page while a panel is open, so LilLabr assumes a hostile page will try them. The page-world half shares the window with the page’s own scripts, and the page can call the tools directly. The design accepts that and limits what any request can do: a status read, a capture of this page, or a save of the capture its own request made. Other names and modes are dropped. A capture requested this way is the page’s own content, prepared locally; the page cannot copy it, upload it or read it back. Requests are paced and saves are capped, so a page cannot fill your download folder, although it can make the browser download a .labr of its own content up to the cap. Replies carry counts and flags only. The upload to Save captures and the clipboard stay with you.
Related:the local MCP server for AI apps outside the browser, the privacy policy and the Terms of Use.