接入你的智能体
發布者自己的指令。不是 PlugMCP 端點。
用我們的金鑰與日誌託管一份副本。
npx -y [email protected]Claude Code 沒有本機指令的安裝連結。複製下方指令並在終端機中執行。
claude mcp add chrome-devtools-axi -- npx -y chrome-devtools-axi@0.1.46在終端機中執行。
{ "mcpServers": { "chrome-devtools-axi": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}claude_desktop_config.json
遠端 URL 還是本機指令？ 兩種安裝方式的差異
來自發布者
chrome-devtools-axi wraps chrome-devtools-mcp with an AXI-compliant CLI.
AXI-compliant chrome-devtools-mcp wrapper — combined operations, TOON output, contextual suggestions
Agent ergonomics is measurable.
The axi benchmark runs the same 14 real-world browsing tasks (Wikipedia research, GitHub navigation, multi-site comparison, and more) through 7 browser automation setups - 5 repeats each, with claude-sonnet-4-6 as the agent and an LLM judge scoring task success.
chrome-devtools-axi posts the lowest input tokens, cost, duration, and turn count of all 7 conditions, with 100% task success:
Against raw chrome-devtools-mcp - the very server this CLI wraps - that is 57% fewer input tokens, 26% lower cost, and 27% fewer agent turns.
Install the chrome-devtools-axi skill in the Agent Skills format with npx skills:
npx skills add kunchenguid/chrome-devtools-axi --skill chrome-devtools-axi -g
That is the entire setup - no npm install needed.
The skill teaches your agent to run chrome-devtools-axi through npx -y chrome-devtools-axi, so the CLI comes along on demand.
The skill is not a user-facing slash command (user-invocable: false).
Just ask for anything that needs a real browser - opening a page, clicking through a flow, extracting page content, debugging console or network, auditing performance - and the agent loads the skill on its own when it recognizes the task.
For ordinary web search, curl-able pages, or static extraction, the skill tells agents to skip Chrome and use simpler fetch/curl-style tooling.
The skill frontmatter also includes Hermes Agent metadata (author plus metadata.hermes tags/category) so Hermes can list it as a first-class browser automation skill; other harnesses ignore those extra fields.
-g installs the skill for all projects (~/.claude/skills/, for example); drop it to install for the current project only (.claude/skills/).
$ chrome-devtools-axi open https://example.com
page: {title: "Example Domain", url: "https://example.com", refs: 1}
snapshot:
RootWebArea "Example Domain"
heading "Example Domain"
paragraph "This domain is for use in illustrative examples..."
uid=g1:1 link "More information..."
help[1]:
Run `chrome-devtools-axi click @g1:1` to click the "More information..." link
$ chrome-devtools-axi click @g1:1
page: {title: "IANA — IANA-Managed Reserved Domains", refs: 12}
snapshot:
...
Refs in snapshot output carry a g<N>: generation prefix that bumps every time a new accessibility tree is captured. Pass refs back exactly as printed. UID actions also verify that the tracked page has not mutated since that snapshot; if freshness cannot be confirmed (including for a legacy untagged ref), they fail loudly with STALE_REF instead of silently no-op'ing, so the agent re-snapshots and retries.
The skill also instructs agents to verify state-changing actions with a fresh snapshot, eval, or screenshot before reporting success, because a current ref can still produce no visible page change.
The skill is the recommended path, but it is not the only one.
chrome-devtools-axi is an AXI, so any capable agent can run the CLI directly with nothing installed at all. Just tell your agent:
Execute `npx -y chrome-devtools-axi` to get browser automation tools.
Want ambient browser context - including the live page state of an active session - fed into every agent session instead of loading on demand? Install the CLI globally and opt into the hook:
npm install -g chrome-devtools-axi
chrome-devtools-axi setup hooks
This installs a SessionStart hook for Claude Code, Codex, and OpenCode that surfaces the current browser session and usage guidance at the start of each session.
Restart your agent session after running this so the new hook takes effect.
Development entrypoints such as pnpm run dev and bin/chrome-devtools-axi.ts are guarded from accidental hook installation.
git clone https://github.com/kunchenguid/chrome-devtools-axi.git
cd chrome-devtools-axi
pnpm install --frozen-lockfile
pnpm run build
pnpm link
The bridge keeps one persistent MCP session across CLI invocations. With no shared URL (or a blank one), standalone mode uses the local stdio process chain below. See Configuration for the two shared-service choices.
┌───────────────────────┐
│ chrome-devtools-axi │ CLI — parse args, format output
└──────────┬────────────┘
│ HTTP (localhost:9224)
▼
┌───────────────────────┐
│ Bridge Server │ Persistent process, manages MCP session
└──────────┬────────────┘
│ stdio
▼
┌───────────────────────┐
│ chrome-devtools-mcp │ Headless Chrome via DevTools Protocol
└───────────────────────┘
In URL-only shared mode, the bridge uses Streamable HTTP directly instead:
┌───────────────────────┐
│ chrome-devtools-axi │ CLI — parse args, format output
└──────────┬────────────┘
│ HTTP (localhost:9224)
▼
┌───────────────────────┐
│ Bridge Server │ Persistent per-session MCP client
└──────────┬────────────┘
│ Streamable HTTP
▼
┌───────────────────────┐
│ Shared MCP service │ One remote MCP process + Chrome
└───────────────────────┘
~/.chrome-devtools-axi/bridge.pid, and is reused only after a deep health check (/health?deep=1, one CDP list_pages). A bridge whose browser has died is terminated and respawned. Startup waits until CHROME_DEVTOOLS_AXI_BRIDGE_TIMEOUT_MS (default 30s). On stop, the bridge kills its process group; teardown escalates SIGTERM to SIGKILL, and only when ps confirms that PID is a bridge, so stdio-launched chrome-devtools-mcp and Chrome children are reaped. A bridge also shuts itself down when its stdio chrome-devtools-mcp process exits, since it can serve nothing without it. Otherwise it runs until stop unless you opt into an idle timeout.uid= refs)eval wraps plain input as () => (<expr>) before sending it to DevTools. For multi-statement logic, pass an arrow function or function. No-arg IIFE form (...)() is accepted too and unwrapped automatically.
chrome-devtools-axi eval "document.title"
chrome-devtools-axi eval "() => { const rows = [...document.querySelectorAll('tr')]; return rows.map((row) => row.textContent) }"
By default, newpage and selectpage print the automatic accessibility tree
and snapshot-derived suggestions. Use --no-snapshot when navigating to a page
and continuing with eval or another chained command without needing element
UIDs. It suppresses only the printed tree and its derived guidance: capture
still runs, preserving page metadata and fresh element-reference generations.
Leave it off for UID-based click/fill workflows, or run snapshot explicitly.
The flag may appear before or after the URL/page ID and takes precedence over
--full.
chrome-devtools-axi newpage https://example.com --no-snapshot
chrome-devtools-axi selectpage 1 --no-snapshot
resize reads the page's viewport back and fails, naming the actual size, when it did not reach the requested size (an emulated viewport, page zoom or the window's minimum size can hold it); use emulate --viewport then.
Page-scoped tools require a selected page. pages only lists tabs and never changes the selection. selectpage sets it. newpage (and open when it has to create a tab) selects the tab chrome-devtools-mcp reports as selected in its own listing, which is the tab it just created, even when that URL is already open in another tab or changed while loading; a title continuation, no marked row, more than one [selected] line anywhere in the listing, a repeated ## Pages section or page id, or chrome-devtools-mcp's note that it moved its selection off a closed tab leaves the selection unset, and the next page-scoped command fails until selectpage. The selected column in pages is AXI's selection, not the MCP [selected] marker. Closing the selected tab clears it. There is no automatic retarget onto another tab.
If the browser reconnects in process, every page id is reissued and the selection is dropped. A command that named a page fails instead of running against a new id. open then creates a new tab rather than restoring the previous one. If a selected tab is already gone, the command instead fails with a page-unavailable error and clears that selection.
For large request or response bodies, prefer network-get <id> --response-file <path> or --request-file <path> so the body goes to disk instead of flooding agent context.
Running with no command shows the CLI home view. By default, it prepends bin
and description metadata (see Configuration to customize the
description), then includes the current snapshot when a browser session is active
or the no-session status/help block when one is not.
--help, -v, -V, and --version are top-level options. All other flags
are command-specific; the CLI rejects a flag that is not listed by
chrome-devtools-axi <command> --help.
Local output paths for screenshot, heap, network-get --response-file/--request-file, lighthouse --output-dir, and perf-start/perf-stop --file resolve against the directory where you invoke the CLI.
Saved-path output uses the resolved absolute path.
A denied or failed write exits non-zero with the tool error instead of printing success.
Snapshots truncate at about 16k characters unless --full is set. eval output keeps its head and tail when truncated.
Relative file paths for upload also resolve against the directory where you invoke the CLI, even if the bridge started in a different directory. Absolute upload paths pass through unchanged.
console --type accepts log, debug, info, error, warn, dir, dirxml, table, trace, clear, startGroup, startGroupCollapsed, endGroup, assert, profile, profileEnd, count, timeEnd, verbose, issue, and all.
network --type accepts document, stylesheet, image, media, font, script, texttrack, xhr, fetch, prefetch, eventsource, websocket, manifest, signedexchange, ping, cspviolationreport, preflight, fedcm, other, and all.
For both commands, all or an omitted --type returns every item.
Set CHROME_DEVTOOLS_AXI_DESCRIPTION to replace the home view's description with
text that fits your browser-tool routing rules. Leave it unset to keep the built-in
description, or set it to an empty string to omit the description line while
keeping the session status and help:
export CHROME_DEVTOOLS_AXI_DESCRIPTION="Use for public pages and local development."
# Or omit the description:
export CHROME_DEVTOOLS_AXI_DESCRIPTION=""
AXI honors chrome-devtools-mcp’s usage-statistics opt-out by forwarding CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS and CI to the MCP server it launches.
The bridge server port defaults to 9224. Override it with an environment variable:
export CHROME_DEVTOOLS_AXI_PORT=9225
To share one long-lived Chrome DevTools MCP service across AXI sessions on the
same host, set CHROME_DEVTOOLS_AXI_MCP_SERVER_URL to the service's Streamable
HTTP endpoint. The exact combination with CHROME_DEVTOOLS_AXI_MCP_PATH selects
how AXI reaches it:
Direct (recommended, simplest): the shared URL is nonblank and
CHROME_DEVTOOLS_AXI_MCP_PATH is absent or blank. AXI constructs a
StreamableHTTPClientTransport directly, starts no local MCP child, and
validates that the URL is an absolute http:// or https:// endpoint. The
shared service must already be running and reachable. This uses exactly one
MCP process for all named AXI bridges; each bridge still gets its own remote
MCP session/context and selected-page state.
MCP_BIN=/absolute/path/to/chrome-devtools-mcp/build/src/bin/chrome-devtools-mcp.js
node "$MCP_BIN" --http-port=9333 --isolated --headless \
--chrome-arg=--use-mock-keychain --chrome-arg=--password-store=basic &
unset CHROME_DEVTOOLS_AXI_MCP_PATH
export CHROME_DEVTOOLS_AXI_MCP_SERVER_URL=http://127.0.0.1:9333/mcp
CHROME_DEVTOOLS_AXI_SESSION=agent-a chrome-devtools-axi pages
CHROME_DEVTOOLS_AXI_SESSION=agent-b chrome-devtools-axi pages
Stdio proxy: the shared URL and CHROME_DEVTOOLS_AXI_MCP_PATH are both
nonblank. AXI checks that executable's --help advertises --serverUrl,
then starts it with only --server-url=<URL>. Use this when the selected
chrome-devtools-mcp build provides the verified proxy mode from
ChromeDevTools/chrome-devtools-mcp#2733.
The AXI bridge starts one proxy child per named bridge; manage the shared
service separately.
export CHROME_DEVTOOLS_AXI_MCP_PATH=/absolute/path/to/chrome-devtools-mcp/build/src/bin/chrome-devtools-mcp.js
node "$CHROME_DEVTOOLS_AXI_MCP_PATH" --http-port=9333 --isolated --headless \
--chrome-arg=--use-mock-keychain --chrome-arg=--password-store=basic &
export CHROME_DEVTOOLS_AXI_MCP_SERVER_URL=http://127.0.0.1:9333/mcp
CHROME_DEVTOOLS_AXI_SESSION=agent-a chrome-devtools-axi pages
CHROME_DEVTOOLS_AXI_SESSION=agent-b chrome-devtools-axi pages
If CHROME_DEVTOOLS_AXI_MCP_SERVER_URL is absent or blank, AXI keeps its
standalone stdio behavior: it starts the selected local
chrome-devtools-mcp process (in order: CHROME_DEVTOOLS_AXI_MCP_PATH, a
chrome-devtools-mcp executable on PATH, a detected global install, or
npx -y chrome-devtools-mcp@latest) and launches/attaches
Chrome according to the local settings below. A nonblank MCP_PATH without a
shared URL also remains this local stdio mode.
CHROME_DEVTOOLS_AXI_MCP_SERVER_URL takes precedence over AXI's local Chrome
launch and attach settings. Run the shared service on the same host and
filesystem as AXI, keeping the endpoint loopback-only, so saved artifact paths
refer to the same local files. Generic MCP stdio clients remain supported; the
proxy choice above only changes how AXI's bridge reaches the shared service.
Stop any existing bridges for those session names before switching between
these configurations: a running bridge retains its original transport
settings. CHROME_DEVTOOLS_AXI_SESSION=<name> chrome-devtools-axi stop stops
that session's bridge and any AXI-owned proxy child; manage the shared service's
lifecycle separately.
Connect to an existing Chrome instance instead of launching one:
export CHROME_DEVTOOLS_AXI_BROWSER_URL=http://127.0.0.1:9222
CHROME_DEVTOOLS_AXI_BROWSER_URL accepts both http:// or https:// URLs and ws:// or wss:// endpoints:
http(s):// uses --browserUrl and fetches /json/version to discover the WebSocket URL.ws(s):// uses --wsEndpoint directly.For authenticated ws:// or wss:// endpoints, pass JSON headers with CHROME_DEVTOOLS_AXI_WS_HEADERS:
export CHROME_DEVTOOLS_AXI_BROWSER_URL=wss://cluster.example/launch
export CHROME_DEVTOOLS_AXI_WS_HEADERS='{"Authorization":"Bearer token"}'
Pick which installed Chrome release channel to target with CHROME_DEVTOOLS_AXI_CHANNEL - stable (the default), beta, canary, or dev:
export CHROME_DEVTOOLS_AXI_AUTO_CONNECT=1
export CHROME_DEVTOOLS_AXI_CHANNEL=beta
This selects which Chrome --autoConnect attaches to, and which one is launched in the default and CHROME_DEVTOOLS_AXI_USER_DATA_DIR modes.
It is ignored when CHROME_DEVTOOLS_AXI_BROWSER_URL is set, since that connects to an explicit endpoint regardless of channel.
Launch a specific Chrome binary instead of the installed Chrome with CHROME_DEVTOOLS_AXI_EXECUTABLE_PATH (chrome-devtools-mcp's --executablePath).
The installer prints the executable path of the downloaded browser; set the variable to that printed path, which depends on your platform and the current stable version:
npx @puppeteer/browsers install chrome@stable --path ~/.cache/puppeteer
# macOS arm64 example; use the path the installer printed
export CHROME_DEVTOOLS_AXI_EXECUTABLE_PATH="$HOME/.cache/puppeteer/chrome/mac_arm-155.0.8059.39/chrome-mac-arm64/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing"
It applies only when this tool launches the browser (the default --isolated mode and CHROME_DEVTOOLS_AXI_USER_DATA_DIR) and is ignored in the CHROME_DEVTOOLS_AXI_AUTO_CONNECT and CHROME_DEVTOOLS_AXI_BROWSER_URL modes, where the browser is already running.
For launched browsers it takes precedence over CHROME_DEVTOOLS_AXI_CHANNEL, which is then not passed.
On macOS, prefer a Chrome for Testing build: a headless copy of the installed Chrome registers with LaunchServices under the installed browser's bundle id, so links clicked in other apps can be delivered to a windowless automation instance instead of the user's browser. Chrome for Testing uses its own bundle id and can never be chosen.
When chrome-devtools-axi launches Chrome itself - the default --isolated mode and CHROME_DEVTOOLS_AXI_USER_DATA_DIR - it always passes --use-mock-keychain and --password-store=basic.
An automation browser has no business reading, writing, or offering to reset your OS password store, so it is kept off it entirely.
Password autofill and saved-password access are therefore intentionally unavailable inside browsers this tool launches.
On macOS this also means the browser can never raise the system "Keychain Not Found ... Reset To Defaults" panel, which Chrome triggers when it tries to store its Chrome Safe Storage key and no default keychain can be resolved for the process.
Your own externally launched Chrome is unaffected: its saved passwords remain available and untouched because this tool does not read, write, move, or reset the login keychain or its Chrome Safe Storage item.
The isolation flags apply only to browsers this tool starts and are deliberately not sent in the CHROME_DEVTOOLS_AXI_AUTO_CONNECT, CHROME_DEVTOOLS_AXI_BROWSER_URL, and wsEndpoint modes, where the browser belongs to whoever launched it.
The shared MCP service is also externally launched; its operator owns Chrome's keychain policy, as illustrated by the service launch example above.
Run multiple isolated bridges at once with CHROME_DEVTOOLS_AXI_SESSION - one per agent session, worktree, or test worker:
CHROME_DEVTOOLS_AXI_SESSION=worker-1 chrome-devtools-axi open https://example.com
CHROME_DEVTOOLS_AXI_SESSION=worker-2 chrome-devtools-axi open https://example.org
Each session name gets its own bridge process, port (auto-derived from the name, or pinned with CHROME_DEVTOOLS_AXI_PORT), and on-disk state.
Outside shared-service mode, the default --isolated and CHROME_DEVTOOLS_AXI_USER_DATA_DIR launch modes each launch a Chrome per bridge, so concurrent sessions share neither browser state nor each other's stale-ref tracking.
Sessions that attach to the same external browser - multiple CHROME_DEVTOOLS_AXI_AUTO_CONNECT=1 sessions on one running Chrome, or the same CHROME_DEVTOOLS_AXI_BROWSER_URL/wsEndpoint - drive that shared browser and are isolated only at the bridge level, where the per-session generation counter does not prevent cross-talk.
A session name does not choose a connection mode or profile; for a locally launched persistent browser, give each session its own CHROME_DEVTOOLS_AXI_USER_DATA_DIR.
The default (unset) session keeps port 9224 and the legacy state paths below.
Do not export CHROME_DEVTOOLS_AXI_PORT globally when running concurrent sessions: it overrides the per-session derived port and forces every session onto the same port, so the second session fails to start - its bridge cannot bind the already-taken port, and the first session's bridge is rejected as a mismatch rather than silently shared.
Rely on the per-session default ports instead, or set CHROME_DEVTOOLS_AXI_PORT only inline per command.
State is stored in ~/.chrome-devtools-axi/ (named sessions nest under sessions/<name>/):
A bridge runs until chrome-devtools-axi stop by default, because it is detached from the shell or agent session that started it.
To have bridges clean up after sessions that never run stop, opt into an idle timeout in milliseconds:
export CHROME_DEVTOOLS_AXI_IDLE_TIMEOUT_MS=1800000 # 30 minutes
A bridge started with it set shuts itself down, together with the chrome-devtools-mcp process and any browser it launched, once that long passes with no command and no request in flight.
Every command that talks to the browser counts as activity except the home view: bare chrome-devtools-axi, which is also the page summary setup hooks shows at agent session start, does not renew the timeout, so starting new agent sessions does not keep an abandoned bridge alive.
The next command after a shutdown starts a fresh bridge, so pages and state of a browser this tool launched are lost, as after stop.
Unset, blank, or 0 keeps the default; values below 1000 are raised to 1000, and a value that is not a whole number of milliseconds is ignored.
A running bridge keeps the setting it started with.
pnpm run build # Compile TypeScript to dist/
pnpm run build:skill # Regenerate the minimal skills/chrome-devtools-axi/SKILL.md stub from src/skill.ts
pnpm run dev # Run CLI directly with tsx
pnpm test # Run tests with vitest
pnpm run test:watch # Run tests in watch mode
The committed skills/chrome-devtools-axi/SKILL.md is a minimal discovery stub generated by pnpm run build:skill; it points to the CLI for current guidance, and pnpm test fails if it drifts from createSkillMarkdown().
The generated skill and its frontmatter are owned by src/skill.ts; update the generator instead of hand-editing the committed SKILL.md.
The npm package includes skills/chrome-devtools-axi/, so published releases ship the same installable Agent Skill documented in Quick Start.
Prettier intentionally ignores generator-owned files listed in .prettierignore; use their generator checks instead of formatting them by hand.
AXI-compliant chrome-devtools-mcp wrapper — combined operations, TOON output, contextual suggestions
{ "mcpServers": { "chrome-devtools-axi": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}工具
尚無工具清單。遠端伺服器會在首次健康檢查後取得工具清單。
常見問題
在本頁複製適用於 Cursor、Claude Desktop、Claude Code 或 VS Code 的 stdio 設定。它使用發布者的安裝方式，而不是 PlugMCP 代理伺服器。
這筆記錄未列出必要的環境變數。
Chrome Devtools Axi 透過 stdio 在本機執行。
上次檢查時間：2026-11-14。 AXI-compliant chrome-devtools-mcp wrapper — combined operations, TOON output, contextual suggestions