Tabhand lets an AI agent operate the user's own signed-in Chrome through isolated background tabs without stealing focus.
Open background tabs in the user's Chrome, optionally at a URL and in a chosen Chrome profile.
List available Chrome profiles and their on/paused status.
Navigate session tabs and list or close the agent's own tabs.
Read pages as accessibility snapshots with actionable element refs.
Click, hover, drag, type, press keys, and handle confirm/prompt dialogs.
Scroll pages and capture screenshots, including full-page screenshots.
Upload local files through file fields or file-picker buttons.
Keep agent tabs separate from the user's tabs and other agents' tabs, including popups/new tabs opened by the agent.
Provides tools for controlling the user's Google Chrome browser, allowing agents to open and manage background tabs, navigate pages, read accessibility snapshots, click, type, scroll, upload files, handle dialogs, take screenshots, and work with multiple Chrome profiles without stealing focus.
https://github.com/user-attachments/assets/d5fe5c5a-c012-471f-bf3b-10fa754c382d
npx tabhand setupWorks with Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Copilot and more: 19 agents in all, plus anything else that speaks MCP.
Then add the extension from the Chrome Web Store. Setup opens the page for you. It works in Brave, Edge and Dia too.
Your logins, not a blank browser. Agents work in the Chrome you already use, so email, dashboards and admin panels just work. You never hand over a password.
You keep working. Every agent gets tabs of its own in the background, grouped under its name and muted. Chrome never jumps to the front.
Your tabs stay yours. An agent can only reach the tabs it opened, never yours and never another agent's.
You can watch. Each agent has its own cursor that glides, clicks and types, and its tabs wear its icon. The Tabhand button in Chrome's toolbar shows who's working and pauses every agent at once.
No servers. Tabhand runs entirely on your computer, with no analytics. Pages only go to the agent you're running. Read the privacy policy.
Related MCP server: byob
agent ──stdio──▶ tabhand mcp ──Unix socket──▶ native host ──native messaging──▶ extension ──chrome.debugger──▶ agent's tabsBackground by default. Each agent session opens its own tabs with active: false, inside a tab group named after the agent. Focus emulation keeps those tabs rendering, so clicks, typing and screenshots work without bringing anything to the front. Agent tabs are muted, and the agent moves on once a page is usable instead of waiting for every video to load.
Agents stay in their lane. The extension only lets a session reach tabs that session opened, plus any tabs and popups those pages open. Your tabs, and other agents' tabs, are invisible to it.
Gets along with password managers. Chrome won't let Tabhand control a page while it shows another extension's frame, such as iCloud Passwords' autofill menu. Tabhand takes those frames out of agent tabs and carries on with the step it was on.
No network port. The bridge talks over a Unix socket in a directory only you can read, with a fresh token each run. Web pages and other machines can't reach it.
Nothing sensitive logged, no telemetry. The bridge logs connect and disconnect events only: no URLs, page content or typed text.
You can watch. While an agent works in a tab, its cursor sits on the page, even across page loads. It glides to whatever the agent clicks, ripples on each click, shows typing dots while it types, waves when you switch to the tab, and fades out once the agent is done. It only animates while you're looking, and it's hidden from the agent's own screenshots.
Agent tabs stand out. While an agent works in a tab, the tab's icon becomes the agent's arrow. The site's own icon comes back when the agent is done.
Each agent wears its own colors, or yours. Claude, Codex, OpenCode, Cursor, Gemini and Copilot each get their own cursor and tab group color; anything else gets a violet cursor with its own name. To give every agent your team's name, color and icon instead, click the Tabhand icon in Chrome's toolbar, then the gear, and choose Custom. The tag's icon can be the name's first letter, one of ten marks, or none, in white or black to suit the color. To set it for every agent on the computer, run tabhand cursor --name Acme --color '#FF5A1F' --icon initial.
Stop button. Click the Tabhand icon in Chrome's toolbar and press Pause every agent, or click Cancel on Chrome's "started debugging" bar. Either pauses every agent at once.
Several Chrome profiles. If Tabhand is in more than one profile (say, work and personal), agents see each one and can ask for it: "use my Work profile". Click the Tabhand icon in a profile, then its name at the top of the panel, to give it a name agents know it by, or fill in that profile's Google email. Without a choice, agents use the profile that connected first. Pause Tabhand in one profile and new work goes to a profile where it's on. An agent that asked for a profile stays in it: if you pause that one, the agent hears so rather than signing in somewhere else.
npx tabhand setupThat's all:
It installs Tabhand in ~/.tabhand and connects it to Chrome, and to Brave, Edge and Dia (macOS) if you have them.
It adds Tabhand to every agent it finds, for all your projects. Each new session gets the browser tools, and the server's instructions tell the agent when to reach for them.
It asks before changing anything. Where an agent has its own mcp add command, setup uses it. Otherwise it edits the agent's settings file in place, keeping comments, and backs up the original to ~/.tabhand/backups.
It opens Tabhand in the Chrome Web Store, so you can add the extension (once), and waits for Chrome to connect.
Agents it knows:
Claude Code, Codex, OpenCode, Cursor, Gemini CLI, Qwen Code, VS Code (Copilot), Copilot CLI, Kiro, Amp, Factory Droid, Warp, Junie, Antigravity
Devin Desktop (Windsurf), Claude Desktop, Cline, Zed
To add it to only some of them, run npx tabhand setup --harness claude,codex.
Using Brave, Edge or Dia? Add the extension there from the same Chrome Web Store page. Edge asks you to allow extensions from other stores first. Each browser shows up to agents as one more profile: click the Tabhand icon in it and give it a name, such as "Brave", so agents can ask for it. Arc isn't supported: tab groups and screenshots never finish there, so Tabhand stays out of Arc even if you add the extension. Arc shuts down on December 22, 2026; Dia works.
tabhand status checks the install, the Chrome connection and each agent. tabhand remove undoes it all. Run npx tabhand@latest setup again to update.
Any other MCP client can run ~/.tabhand/bin/tabhand mcp itself (on Windows, %USERPROFILE%\.tabhand\bin\tabhand.cmd mcp).
You need Node.js 20 or later, from nodejs.org or winget install OpenJS.NodeJS.LTS.
In PowerShell, if npx says running scripts is disabled on this system, run npx.cmd tabhand setup instead, or use Command Prompt.
Setup registers Tabhand with Chrome and Edge (Edge comes with Windows), and with Brave if you have it, under HKEY_CURRENT_USER in the registry. Nothing needs an administrator.
Agents reach the bridge over a named pipe, not a network port, and each has to show a token kept in your own AppData, new each time Chrome starts the bridge.
Tested on Windows 11 with Chrome, and with Claude Code as the agent.
npm install
node bin/tabhand.mjs setup # builds dist/tabhand.mjs and installs it from this checkout
node bin/tabhand.mjs reload # after changing the extension's codeFrom a checkout, setup has you load the extension unpacked (Developer mode, then "Load unpacked") instead of adding it from the Chrome Web Store.
Setup copies a single bundled file (dist/tabhand.mjs, built by npm run build), because macOS doesn't let Chrome's child processes read Documents, Desktop or Downloads. Agents and Chrome both start it through ~/.tabhand/bin/tabhand. That launcher remembers which Node.js ran setup, since agent apps don't get your shell's PATH. If that Node.js is removed later, it finds another one. If Chrome never connects, the bridge's log at ~/Library/Application Support/tabhand/host.log says why.
On Windows, Chrome starts the bridge through ~\.tabhand\bin\tabhand-host.cmd, which the registry points it to, and agents run the Node.js that ran setup with ~\.tabhand\app\tabhand.mjs directly, since they start programs without a shell. The log is in %LOCALAPPDATA%\tabhand\host.log, and anything the bridge printed while failing to start is in host-errors.log next to it.
Windows-only code lives in src/windows.mjs and extension/windows.js. The shared files call into them only behind a Windows check, and keep their macOS code as it is.
Tool | What it does |
| Open a background tab in the agent's tab group, optionally loading a URL, in the Chrome profile it asks for |
| Load a URL in one of the session's tabs |
| Read the page as an accessibility outline; actionable elements, including ones a page made clickable or draggable out of plain elements, get refs like |
| Click an element by ref, or by the text it shows |
| Move the pointer over an element (by ref or text) to reveal controls that only show on hover, and get a fresh snapshot with refs for them |
| Drag one element onto another, by ref or text: reorder lists, move cards between columns. Works with the browser's own drag and drop and with pages that follow the mouse |
| Type into a field, optionally clearing it first and pressing Enter after, or choose a dropdown option by its text |
| Press a key or combination such as |
| Scroll up or down |
| Attach files from your computer to a file field, or through the button that opens a file picker (no system dialog appears) |
| Accept or dismiss a confirm or prompt dialog the page opened (alerts are closed for you) |
| Screenshot a tab, even in the background |
| List the session's tabs, in every Chrome profile |
| List the Chrome profiles that have Tabhand, by name, and whether each is on or paused |
| Close one of the session's tabs |
npm test runs all of these except the smoke test.
node test/setup.mjs runs setup, status and remove in a throwaway home folder holding existing agent configs. It checks that Tabhand gets added, that comments and other settings survive, that a second run changes nothing, and that the launcher serves the MCP server.
node test/setup-windows.mjs does the same on Windows, with the registry entries under a key of the test's own, and checks that agents' own mcp add commands get called through cmd.exe.
On Windows the tests that start a browser need TABHAND_TEST_BROWSER set to Chrome for Testing's chrome.exe.
node test/package.mjs packs the npm package, installs the tarball, and runs setup from it.
node test/activator.mjs checks, on macOS, that the helper the bridge starts to hand the front back to your app goes away with the bridge, even when the bridge is killed, and that a new bridge stops helpers an older Tabhand left running and nothing else.
node test/arc.mjs checks, on macOS, that a bridge Arc starts stays connected but out of agents' way.
node test/profiles.mjs runs two bridges against stand-in extensions, "Work" and "Personal". It checks that agents see both by name and can choose one, that a chosen profile stays chosen, and that pausing one profile sends new work to the other.
node test/profile-name.mjs names a throwaway Chrome for Testing profile in the toolbar panel and checks that agents see the name, and that the panel pauses and resumes agents.
npm run test:e2e launches a throwaway Chrome for Testing profile, runs two agents in parallel, and checks they can't reach each other's tabs and that the browser never comes to the front.
node test/new-tabs.mjs checks that links, window.open() and popups from an agent's tab never take over your tab, and that the agent gets the new tab.
node test/drag-hover.mjs checks, in a background tab, that hover-only buttons (shown by CSS :hover or by a mouseenter handler) can be reached, and that lists reorder by dragging, with the browser's own HTML5 drag and drop and with mouse events alone, including lists that want a press delay and ones that have to be scrolled while an item is held.
node test/upload.mjs checks that files reach a page byte for byte, through a file field or a button's file picker, including files over Chrome's 1 MB message cap.
node test/foreign-frames.mjs checks that an agent gets through pages where a password manager's autofill menu pops up, using a stand-in extension.
npm run test:smoke runs a short check against the Chrome you have open.
node test/live.mjs --profile Dia --app Dia runs every tool in a real browser profile you have Tabhand in (Dia, Brave, Edge or a Chrome profile), through your install: two agents at once on a local test page, checking that their tabs stay apart and that the browser never comes to the front.
node test/cursor-presence.mjs checks the cursor and tab badge show before the first action, survive page loads, and leave when the agent is done.
node test/load-speed.mjs [--real] compares how long the agent waits for pages with a plain tab.
node test/cursor-gallery.mjs renders every cursor theme side by side, and node test/badge-preview.mjs every tab badge.
Per-site approval: agents ask before using a site for the first time
Confirmation before sending, buying or deleting
Logins filled from your password manager without the AI seeing the password
Downloads and iframes
Linux
MIT
Click an element by its ref from browser_snapshot, or else by the text it shows. Waits for any page load the click starts. Links and popups that open a new tab stay in the background, join this session, and are listed in the result. Clicking an option of a dropdown chooses it.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Element ref from browser_snapshot, e.g. e123. | |
| text | No | Instead of a ref: the visible text of the element to click, for something the snapshot gives no ref but you can see in a screenshot. | |
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects well beyond the openWorldHint annotation: the call blocks waiting for a resulting page load, and new-tab links/popups are kept in the background, joined to this session, and reported in the result. That is exactly the non-obvious behavior an agent needs to predict tool output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences ordered by importance: how to identify the target, what the call waits for, and what surprises (background popups, dropdown selection) to expect. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so for the tricky case (popups listed in the result), but stays silent on what a normal successful click returns and how failed clicks (missing ref) surface. Slightly incomplete for a 3-param action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds precedence the schema only implies: ref is the primary identifier and text is the fallback. It doesn't describe tabId or error behavior when a ref is stale.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (click) and the exact target-identification modes (ref from browser_snapshot, or visible text), which distinguishes it from siblings like browser_type and browser_press_key. An agent knows immediately this is the element-activation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to browser_snapshot for refs and states a fallback ('or else by the text it shows') for elements the snapshot can't label. It also covers the dropdown subcase. It doesn't say when not to use it (e.g. typing into a field should use browser_type), so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close one of this session's tabs when you are done with it.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the main safety profile is covered. The description adds the useful scoping detail that this affects tabs in the current session and should be used after finishing with a tab, but it does not elaborate on permanence, recovery, or side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the action, with no wasted wording. It conveys the core operation and timing efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with full schema coverage and annotations covering destructive behavior, the description is nearly complete. It could mention irreversibility or how to recover tab IDs, but those gaps are minor given the structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema itself explains that tabId comes from browser_open_tab or browser_list_tabs. The description adds no parameter details beyond that, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: closing a tab in the current session. It distinguishes this from sibling tools like browser_open_tab and browser_list_tabs by making clear this is the closing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage condition: call this when you are done with a tab. It does not explicitly name alternatives or exclusions, but the close-vs-open/list distinction is obvious from the purpose and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drag one element onto another: press on the first, move to the second in small steps, and let go. For reordering lists and boards, moving cards between columns, and the like. Works with the browser's own drag and drop and with pages that follow the mouse themselves, and scrolls while holding the item if the drop target is out of sight. Name each end by its ref from browser_snapshot, or else by the text it shows. Says what moved where when the page shows it; take a new snapshot to check the result.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. | |
| toRef | No | Ref of the element to drop it on, from browser_snapshot. | |
| toText | No | Instead of toRef: the visible text of the element to drop it on. | |
| fromRef | No | Ref of the element to drag, from browser_snapshot, e.g. e123. | |
| fromText | No | Instead of fromRef: the visible text of the element to drag. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the openWorldHint annotation: it supports both native browser drag-and-drop and mouse-following pages, auto-scrolls while holding the item when the target is off-screen, and reports what moved where. It also tells the agent to re-snapshot to verify. This is rich, actionable behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and mechanics, then use cases, then edge behavior. It is on the longer side, but each sentence carries information (use cases, caveats, verification). Minor redundancy keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description explains that it reports what moved where and recommends a fresh snapshot to confirm. Combined with the ref/text sourcing guidance and scroll-while-holding behavior, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds real value by explaining the ref-or-text mechanism ('Name each end by its ref from browser_snapshot, or else by the text it shows'), reinforcing the fromRef/fromText and toRef/toText fallbacks beyond the schema's per-field notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete verb and resource ('Drag one element onto another') and even explains the mechanics (press, move in small steps, let go). Clearly distinguishes the drag operation from siblings like browser_click, browser_hover, and browser_scroll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete use cases ('reordering lists and boards, moving cards between columns'), which tells the agent the scenarios that call for dragging. It does not explicitly name an alternative tool or an exclusion condition, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer a confirm or prompt dialog the page opened: accept it (OK) or dismiss it (Cancel). The page waits until it is answered. Alerts are closed for you. Ask the user first if accepting would send, buy, delete or change something.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | What to enter, for a prompt dialog. | |
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. | |
| accept | Yes | true for OK, false for Cancel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only openWorldHint is annotated, so the description carries the behavioral burden and does it well: it discloses that the call blocks because the page waits for an answer, that alerts need no handling, and the side-effect risk behind accepting. It stops short of stating error behavior when no dialog is open or whether an unanswered dialog times out.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler, with the core action and its blocking consequence leading and the safety caution trailing. Everything earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a three-parameter tool with full schema coverage and no output schema: the modal/blocking semantics and alert exemption are the key facts an agent needs. The remaining gap is what happens when no dialog is present, which the schema and description leave silent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so tabId, accept and text are already documented at the field level. The description reinforces the accept mapping (OK vs Cancel) but adds no syntax or format detail beyond that, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (answer) and resource (confirm or prompt dialog the page opened), with the two outcomes spelled out as accept (OK) or dismiss (Cancel). No sibling tool covers dialogs, so this is unmistakable in the toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the triggering condition (a confirm/prompt dialog the page opened) and adds a caution to ask the user first when accepting would send, buy, delete or change something. Also implicitly excludes alerts by noting they are closed automatically, though it does not say what to do or what happens if no dialog is pending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move the pointer over an element and leave it there, to reveal controls that only show on hover (a delete button on an image, a menu that opens under the pointer). Pass its ref from browser_snapshot, or else the text it shows. Waits a moment for what the hover brings up, then returns a fresh snapshot, so what appeared has refs you can click. If a card or menu is still loading, take another browser_snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Element ref from browser_snapshot, e.g. e123. | |
| text | No | Instead of a ref: the visible text of the element to hover. | |
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply openWorldHint, so the description carries most of the burden and does it well: it discloses the built-in wait, that a fresh snapshot with usable refs is returned, and the fallback re-snapshot when content is still loading. No auth, rate-limit, or failure-mode detail is given, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: purpose first, targeting second, post-condition and recovery last. The parenthetical examples are short and aid recognition rather than padding; no sentence is redundant with another.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by explaining exactly what comes back — a fresh snapshot whose new elements have refs you can click — plus what to do if the hover result is still rendering. For a three-parameter interaction tool, nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters are already documented, including the ref/text alternative and the tabId source. The description echoes that refs come from browser_snapshot and that text is an alternative, which adds emphasis but no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Move the pointer over an element and leave it there' — and immediately names the observable outcome: revealing controls that only appear on hover, with two concrete examples (delete button on an image, menu under the pointer). That makes it unmistakably distinct from siblings like browser_click, browser_drag, and browser_scroll without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the situation that selects this tool (hover-only controls) and tells the agent how to target the element: a ref from browser_snapshot, or else the visible text. It also gives a recovery path — take another browser_snapshot if content is still loading. It stops short of explicitly naming an alternative tool for when the target is already visible (e.g., use browser_click instead), so it is strong context rather than full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Chrome profiles that have Tabhand (for example work and personal, each signed in to different accounts): each one's name, whether Tabhand is on or paused there, and which one your new tabs open in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful scope and return-content context, such as only profiles with Tabhand and whether Tabhand is on or paused, but it does not disclose deeper behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence that starts with the action and then clarifies scope and return fields. The parenthetical example earns its place by making the concept concrete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with no output schema, the description is mostly complete because it names the listed entities and the main fields returned. Minor gaps remain around exact identifiers or ordering, but the core call context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need parameter-specific detail and does not introduce confusing semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: list Chrome profiles that have Tabhand. It also states the useful returned fields, so an agent can distinguish this from tab-listing siblings, though it does not explicitly name browser_list_tabs as the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool is useful but provides no explicit when-to-use, when-not-to-use, or alternative guidance. With siblings such as browser_list_tabs present, the absence of routing guidance is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the tabs this session has open. Other sessions' tabs and the user's own tabs are never shown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's job is only to add context — and it does, by disclosing the visibility boundary (other sessions' and the user's own tabs are excluded). Return shape (fields per tab, ordering) is not mentioned, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place: the first gives the action, the second preempts the most likely agent misconception about tab visibility. Front-loaded and waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial zero-parameter read tool with full annotations, this covers what an agent needs to call it and to interpret the results' scope. A brief note on what a tab entry contains would close the remaining gap, since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters and an empty schema, so there is nothing to disambiguate; baseline 4 applies. The description correctly implies the tool takes no arguments by describing a single fixed scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the tabs') and immediately scopes it to the current session, which cleanly separates it from browser_list_profiles and from any notion of enumerating the user's whole browser.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope statement tells the agent this is the read path for discovering already-open tabs, but there is no explicit 'use this before browser_open_tab to avoid duplicates' or a stated alternative. Usage is clearly implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a new tab in the user's own Chrome, with their logins, and optionally load a URL. The tab opens in the background inside this session's tab group: Chrome is not brought to the front and the user's tabs are untouched, so they can keep working. Returns the tabId the other browser tools need.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page to load, e.g. https://example.com. Omit for a blank tab. | |
| profile | No | Chrome profile to open the tab in, by its name or id from browser_list_profiles. Only needed when the user has Tabhand in several profiles. Your later tabs open there too. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare openWorldHint, so the description carries the behavioral load and does it well: background opening, placement in this session's tab group, Chrome not raised to front, user's tabs untouched, and the tabId return. These are exactly the non-obvious traits an agent needs before deciding to call it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero waste, and the identifying action comes first, followed by the behavioral constraints and the return value. Nothing is repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description fills that gap by naming the tabId return. With annotations sparse but behavior fully described and params covered by the schema, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented in the schema, including the profile-to-browser_list_profiles link and the persistent-profile caveat. The description only echoes "optionally load a URL," so it adds little beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ("Open a new tab in the user's own Chrome") with scope qualifiers: optional URL, background opening, session tab group. It also separates itself from siblings by noting it returns the tabId "the other browser tools need," so an agent knows this is the entry point rather than browser_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context for use: it opens in the background so the user can keep working, and profile is only needed when the user has several profiles (pointing at browser_list_profiles). It does not explicitly state when to prefer browser_navigate over opening a new tab, so the alternative routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a key in the page: Enter, Tab, Escape, Backspace, Delete, ArrowUp/Down/Left/Right, Home, End, PageUp, PageDown, Space, a single character, or a combination such as Shift+Tab.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key or combination, e.g. Enter or Shift+Tab. | |
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only annotation is openWorldHint, so the description carries the full behavioral burden and doesn't meet it. It never states which element receives the keypress (currently focused element vs. page body), whether keydown/keyup/click events are synthesized, whether a snapshot is needed beforehand, or how failures surface — all material for a keyboard-injection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the action and spends the remainder on the key list, all of which is directly actionable. Nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a fully documented schema and no output schema, the input side is adequately covered. What's missing is focus targeting and post-press behavior, which an agent needs to invoke it reliably in a page context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description goes further by enumerating the accepted key vocabulary (navigation keys, Space, single characters) and the '+' combination form, which meaningfully expands on the schema's terse 'e.g. Enter or Shift+Tab'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Press a key in the page') plus an explicit enumeration of supported keys and combination syntax, so an agent can immediately tell this apart from browser_type or browser_click. It stops short of naming siblings, which keeps it out of the top band.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the key list hints at keyboard-driven interaction, but the description never says when to reach for this versus browser_type (text entry) or browser_click (activation), nor any prerequisites such as focusing an element first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of one of this session's tabs, even though it is in the background. Prefer browser_snapshot for reading text; use screenshots to check layout and visuals.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. | |
| fullPage | No | Capture the whole page instead of the visible area (capped at 8000 px tall). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior not in the annotations: capture works even when the tab is in the background, which affects whether the agent must focus/navigate first. It stops short of saying the return is an image payload, which is the one remaining thing an agent might want.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the capability statement first and the disambiguation second. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with full schema coverage and safety annotations, this is nearly complete. The only gap is the shape of the result (image vs. text blob), which matters for a screenshot tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: tabId is documented as coming from browser_open_tab or browser_list_tabs, and fullPage documents the 8000 px cap. The description adds no parameter detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Take a screenshot of one of this session's tabs') and immediately names the sibling that serves a different need (browser_snapshot for reading text). An agent can distinguish it from browser_snapshot and the other browser_* tools without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing guidance: prefer browser_snapshot for reading text, use this tool for layout and visuals. That is a clear when-to-use/when-not-to-use pair with the alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll the page up or down, e.g. to load more content or bring something into view for a screenshot.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. | |
| amount | No | Pixels to scroll. Defaults to 600. | |
| direction | No | Defaults to down. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply openWorldHint=true, so the description carries the burden for behavioral details. It says nothing about whether the scroll is animated, whether it waits for lazy-loaded content, or what happens when the page boundary is reached — relevant for a tool whose main use case is triggering lazy loads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the action front-loaded and the motivating examples trailing. No filler, nothing redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter interaction tool with full schema coverage and no output schema, the description covers purpose and motive adequately. It leaves open whether the result confirms the new scroll position or whether the scroll triggers waits, a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: tabId, amount (default 600), and direction (default down) are all documented with defaults in the schema. The description adds no units, magnitude guidance, or direction semantics beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Scroll the page up or down') and grounds it in concrete outcomes (load more content, bring something into view). It doesn't explicitly say the scroll applies to the tabId-specified tab, but there is no competing scroll sibling, so identification is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'e.g. to load more content or bring something into view for a screenshot' clause gives clear usage contexts, including an implied handoff to browser_screenshot. It stops short of stating when not to scroll or naming a concrete alternative tool, so it isn't a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the page as an accessibility outline (headings, text, links, buttons, fields). Elements you can act on carry a ref like e123 for browser_click and browser_type; plain elements the page made clickable show as "clickable". Refs stop working after the page changes, so take a new snapshot then.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely non-structured behavior: refs are ephemeral and invalidated by page changes, and some elements are marked 'clickable' rather than given a ref — exactly the traits an agent needs to avoid stale-ref failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the return shape and immediately followed by the actionable ref semantics and the staleness caveat. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description covers the return format (accessibility outline with headings, text, links, buttons, fields), the ref convention, and ref lifecycle. An agent can call it and interpret the result without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter tabId is fully documented in the schema (100% coverage, naming browser_open_tab/browser_list_tabs as sources). The description adds nothing about the parameter, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read the page as an accessibility outline') and enumerates the content types returned, making it immediately distinguishable from browser_screenshot's visual capture. The ref/e123 explanation further pins down the tool's role in the click/type workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly links refs to browser_click and browser_type and states the re-snapshot condition after page changes, which is real usage guidance. It never directly contrasts itself with browser_screenshot or browser_list_tabs, so the alternative-selection guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into a field. Pass the field's ref to focus it first; omit ref to type into whatever already has focus. Set clear to replace the existing text and submit to press Enter afterwards. Given a dropdown's ref, chooses the option with that text.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Field ref from browser_snapshot, e.g. e123. | |
| text | Yes | Text to type. | |
| clear | No | Replace the field's current text. | |
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. | |
| submit | No | Press Enter after typing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply openWorldHint, so the description carries the burden and does credibly: it discloses focus semantics, that clear replaces existing text, that submit sends Enter, and that a dropdown ref selects the matching option rather than typing characters. It omits failure modes (unfocused element, missing ref, disabled field) and whether typing is simulated keystroke-by-keystroke.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the action, each covering a distinct calling mode. Nothing is repeated from the schema and nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all five parameters' behavioral implications despite no output schema and thin annotations, which is the key risk for this tool. The gap is that with no output schema the agent still doesn't know what is returned or how failures surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description still adds value by explaining the ref-omitted case (type into whatever has focus) and the dropdown selection semantics for ref, neither of which the schema states. It adds little for text itself, which is self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Type text into a field') in the first three words, then adds the dropdown-option variant. An agent can distinguish this from browser_click (navigate/activate) and browser_press_key (key events) without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the two calling modes clearly: pass a ref to focus first, omit ref to type into the currently focused element, and use submit to press Enter as an alternative to browser_press_key. It gives no explicit exclusion conditions (e.g., when to use browser_click on a dropdown instead), so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach files from this computer to the page, as if the user picked them. Pass the ref of a file field, or of the button that opens a file picker (no system dialog appears).
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Ref of the file field, or of the button that opens the file picker. | |
| paths | Yes | Files to attach: absolute paths, or relative to the directory you run in. | |
| tabId | Yes | Tab id from browser_open_tab or browser_list_tabs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply openWorldHint, so the description carries most of the burden. It does contribute real behavior context — the picker dialog is bypassed and the selection is simulated — but says nothing about what happens if a path is invalid, whether the upload completes or errors, or any permission constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the action and the key behavioral detail front-loaded before the targeting instructions. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three required parameters at full schema coverage and no output schema, the description covers what an agent needs to invoke it. The remaining gap is outcome behavior on success or failure, which is not covered by annotations either.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents all three parameters, including that ref may target a field or a picker button and that paths may be absolute or working-directory relative. The description largely restates that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Attach files from this computer to the page') plus the mechanism ('as if the user picked them'), which cleanly separates it from browser_click, browser_type and the other page-interaction siblings. An agent knows exactly what effect to expect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the targeting options concretely: pass the ref of a file field or of the button that opens a picker, and notes no system dialog appears. That is clear usage context, but there are no explicit when-not-to-use conditions or named alternatives among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.11.0browser_dragbrowser_hoverv0.10.1browser_clickbrowser_close_tabbrowser_handle_dialogbrowser_list_profilesbrowser_list_tabsbrowser_navigatebrowser_open_tabbrowser_press_keybrowser_screenshotbrowser_scrollbrowser_snapshotbrowser_typebrowser_upload_fileScored across 15 tools
Every tool has a clear, highly specialized purpose within the browser automation domain. Functions like typing, clicking, hovering, and keypress simulation are distinct, and environmental controls (profiles/tabs) are separated from web interaction controls.
The tools adhere strictly to a consistent naming convention: `browser_action_noun`. This highly predictable pattern ensures immediate readability and low cognitive load for an agent.
The count of 15 is perfectly suited for a robust browser automation framework. It includes both high-level navigation and low-level granular interactions (e.g., hover, drag, keypress) without becoming overly verbose.
The surface covers nearly all core browser interaction needs, including state reading (snapshot, list_tabs) and complex interactions (drag, upload). The only minor gap is the lack of an explicit tool to retrieve the current active tab's URL.
Let AI agents use your real, signed-in Chrome: tabs, clicks, forms, screenshots and video.
Comment on AI-generated webpages; feedback flows back to your coding agent. Free, MIT, local-first.
Connect AI agents to your own Chrome with scoped access, approvals, and verified task results.
Build agents to automate any background task. Works with your ChatGPT/Claude subscription.
