kunchenguid/chrome-devtools-axi

chrome‑devtools‑axi – Agent‑friendly Chrome automation

What it is

• A command‑line interface that talks to chrome‑devtools‑mcp (a headless Chrome controller) and presents the results in the AXI format, a compact token‑efficient representation designed for large‑language‑model agents.
• The CLI is deliberately built to be agent‑ergonomic: a single command can navigate, capture a page snapshot, and return actionable hints for the next step, all while keeping the data size low (TOON‑encoded output saves ~40 % of tokens vs raw JSON).

Why it matters for AI agents

• Many LLM‑powered agents need a real browser to perform tasks that simple HTTP fetches can’t handle (e.g., clicking through multi‑step flows, handling dialogs, running JavaScript, extracting dynamic content). chrome‑devtools‑axi gives those agents a stable, low‑overhead bridge to Chrome.
• The tool integrates with the AXI ecosystem (see https://axi.md) and can be installed as an Agent Skill via npx skills, letting agents load it on‑demand without any manual npm install.

How it works

1. Bridge server – a detached process keeps a persistent MCP session alive across CLI invocations, so Chrome does not restart for every command.
2. CLI – parses arguments, sends the request to the bridge over HTTP (default localhost:9224), receives a TOON‑encoded snapshot, and prints a human‑readable summary plus a help hint for the next action.
3. Persistence options –
   • Standalone: bridge spawns a local chrome‑devtools‑mcp child (default).
   • Shared service: point CHROME_DEVTOOLS_AXI_MCP_SERVER_URL at an already‑running MCP server to reuse a single Chrome instance across many agents.
4. Output – snapshots of the accessibility tree are encoded in TOON, with interactive elements given stable @g<N>:<uid> references. Agents can feed those refs back to the CLI for clicks, fills, etc.

Key commands (agent‑facing)

Command	What it does
open <url>	Loads a page, captures an accessibility snapshot, and returns a short summary plus a help suggestion (e.g., click link @g1:1).
click @<uid>	Clicks the element identified by the reference from the latest snapshot.
fill @<uid> <text>	Types into a form field.
eval <js>	Executes arbitrary JavaScript in the page context and returns the result (wrapped as a TOON value).
snapshot	Captures the current page’s accessibility tree without navigation.
screenshot …	Saves a PNG/JPEG/WebP of the viewport or full page.
lighthouse …	Runs a Lighthouse audit and writes the report to disk.
perf‑start / perf‑stop	Starts and stops a Chrome performance trace.
setup hooks	Installs a session‑start hook for Claude Code, Codex, and OpenCode so the agent automatically receives the current browser context at the beginning of each chat.

Installation & activation

1. Agent‑skill route (recommended)

   npx skills add kunchenguid/chrome-devtools-axi --skill chrome-devtools-axi -g
   

   The skill tells an AXI‑compatible agent to run npx -y chrome-devtools-axi … whenever it needs a real browser.
2. Zero‑setup run – an agent can invoke the CLI directly with npx -y chrome-devtools-axi without any prior install.
3. Global install (for manual use or hook setup)

   npm install -g chrome-devtools-axi
   chrome-devtools-axi setup hooks
   

4. From source – clone, pnpm install --frozen-lockfile, pnpm run build, pnpm link.

Performance highlights (from the README’s benchmark)

Metric	chrome‑devtools‑axi	Next best
Avg. input tokens per task	79 141	82 532 (dev‑browser)
Avg. cost per task	$0.074	$0.078
Avg. duration	21.5 s	24.6 s
Avg. agent turns	4.5	4.8
Success rate	100 %	99 %
The tool reduces token usage by ~57 % compared with raw chrome‑devtools‑mcp and cuts the number of LLM‑agent turns by ~27 %.

Typical use‑cases for an LLM‑agent

• Research workflows – open a Wikipedia page, click related links, extract tables, and let the agent summarize.
• GitHub navigation – browse repositories, open PR pages, click “Files changed”, and pull diffs.
• Multi‑site comparison – load several product pages in parallel tabs, scrape price elements, and compute differences.
• Performance auditing – run Lighthouse or Chrome tracing on a page the agent is evaluating for SEO or UX.
• Form automation – fill login forms, submit, and verify resulting page state before proceeding.

Limitations / gotchas

• The CLI is not a user‑facing slash command; it is meant to be called by an agent, not directly typed by a human.
• References (@g<N>:…) become stale if the page changes without a fresh snapshot; the CLI will abort with STALE_REF so the agent must re‑snapshot.
• Snapshot output is truncated to ~16 KB unless --full is used, which may be necessary for very large pages.
• The bridge process writes a PID file under ~/.chrome-devtools-axi/; if that file becomes corrupted the bridge may need manual cleanup.
• To share a single Chrome instance across many agents you must run a compatible chrome‑devtools‑mcp service and set the appropriate environment variables.

Bottom line chrome-devtools-axi is a purpose‑built bridge that lets LLM agents control a real Chrome browser efficiently. By encoding results in the token‑saving TOON format and providing built‑in “next‑step” hints, it reduces the back‑and‑forth between the model and the tool, leading to cheaper, faster, and more reliable agent‑driven web automation.