Chrome MCP Tools

Use this skill when you need to access or control a live Chrome browser through the local Chrome DevTools MCP middleware at http://127.0.0.1:8787/mcp, especi...

Security Scan

The skill's purpose (controlling a local Chrome via MCP) is plausible, but the instructions ask the agent to install and run third‑party npm software, start/stop daemons, and access the user's live Chrome session while the registry metadata declares no binaries, no install, and no credentials — these mismatches are concerning.

Purpose & Capability

The SKILL.md clearly intends to control a local Chrome DevTools MCP daemon and may legitimately need local CLI tools (chromedev, npm, curl). However, the registry metadata declares no required binaries, no install spec, and no environment variables, which is inconsistent with the runtime instructions that expect npm, a chromedev CLI, and curl to be available (and even instructs installing a global npm package).

Instruction Scope

The instructions direct the agent to run local commands (curl checks, chromedev version/doctor/run/stop), perform network queries to npm (npm view), and potentially install a global npm package (@mallocfeng/chromedev). They also require controlling a long‑lived daemon attached to the user's Chrome and therefore can access rendered pages, cookies, and any authenticated state in the browser. Those actions go beyond simple page-fetching and have real access to sensitive local browser state; the SKILL.md does not declare or justify these requirements in the registry metadata.

Install Mechanism

There is no install spec in the registry, but the skill explicitly tells the agent to run npm view and to npm install -g @mallocfeng/chromedev@<version> when needed. That means the skill relies on fetching and running code from the public npm registry at runtime (a moderate-to-high risk install path) and may require global package install privileges. The package name and author are not validated in the registry metadata and no checksum or trusted source is declared.

Credentials

The skill requests no environment variables in metadata, yet it will access local resources with high sensitivity: the user's live Chrome instance (cookies, sessions, auth tokens) via the MCP middleware and will perform network calls to npm. The absence of declared required binaries/env vars is misleading; the actions it performs are proportionally significant and should be explicitly declared so a user can consent knowingly.

Persistence & Privilege

The skill is not marked always:true, but it instructs starting a long‑lived daemon (chromedev run) and may stop/start processes (chromedev stop --all). Those operations modify system state and run persistent processes, but they are coherent with the stated purpose. Still, starting/stopping daemons and installing global npm packages are privileged actions the user should be aware of before allowing autonomous execution.

What to consider before installing

This skill will access your live Chrome browser (including cookies and any logged‑in sessions) via a local daemon and may install and run a third‑party npm package globally. The registry metadata does not declare the required binaries or the npm install step — treat that as a red flag. Before installing or allowing autonomous use: (1) verify and trust the npm package @mallocfeng/chromedev (inspect its source on npm/GitHub); (2) prefer to manually install the chromedev CLI yourself instead of allowing the skill to run npm install -g; (3) run the skill in a non‑sensitive environment or with a separate browser profile if you have private data open; (4) ask the skill author to add an explicit install spec and required-binaries list and to document exactly what browser data is accessed. If you cannot verify the npm package author or source, avoid granting this skill autonomous permission to install or run system commands.

chromedev

Use this skill when the user wants browser backed data from real web pages through the local chrome-devtools-mcp middleware running at http://127.0.0.1:8787/mcp.

This skill is for cases where rendered browser state matters, including JavaScript heavy sites, login state in the user's Chrome, interaction flows, screenshots, DOM snapshots, or page data that should come from the live browser instead of plain HTTP fetches.

Connection model

• chromedev run is the long lived daemon. It is the layer that keeps the upstream chrome-devtools-mcp process attached to Chrome.
• The bundled http_mcp_call.mjs script is intentionally short lived. Each invocation only sends a bounded MCP request to the local daemon.
• Do not try to keep a client side MCP HTTP session open in order to preserve Chrome authorization. Chrome authorization belongs to the daemon side connection, not to an individual skill invocation.
• If the daemon is healthy, short lived skill calls should not require Chrome to re-authorize on every request.

Primary behavior

• If the user gives a URL, open it and extract the page content.
• If the page is a list page, return the visible list content in order.
• If the task takes multiple browser steps, emit short progress updates while it runs.

This workflow is otherwise a black box to the user, so visible progress output is required. Output is not optional in this skill.

Output rules

1. If the user explicitly asks for 摘要, 总结, 要点, recap, summary, then produce a summary.
2. Otherwise, return extracted page content faithfully and concisely.
3. If paywall or login blocks full text, say what you can see and what is blocked.
4. If a chromedev MCP call fails with errors such as Not connected, first inspect with chromedev doctor. If it reports stale/orphan chromedev processes or the retry fails, run one recovery cycle with chromedev stop --all, then chromedev run, and retry the failed page operation once. Only report the error to the user if the retry also fails.

Progress reporting

Do not send intermediate progress updates to Telegram or any other chat tool. Focus on producing the final extracted answer or summary directly. Current agent progress and final user facing answer must not trigger extra chat-tool delivery side effects. When the final extracted answer or summary is ready, deliver the final answer once. The final extracted answer or summary must not be streamed token by token. Buffer the final answer first, then send it as one complete final output.

Timeline guarantee

• If a step fails, emit the failure status immediately and stop or recover.
• If a step is waiting on external input, emit the waiting status immediately when the wait begins.
• The final answer must be the terminal visible success output.
• The final answer must be sent in one completed block, not as a streaming preview.

Progress message constraints

• Never include the original URL, any raw link, or full page text in any auxiliary status text.
• Do not restate or recap completed progress steps after the final answer is ready.
• Do not append a trailing success/progress line after the final answer.
• Do not use streaming progress text as the vehicle for the final answer body.
• Do not call openclaw message send for this workflow.
• Do not send intermediate status messages to Telegram or any chat tool.
• The final extracted answer or summary itself should be the only user visible success output.
• The final extracted answer or summary must not be followed by any extra progress, recap, completion, or status line.
• The final extracted answer or summary must be delivered non-streaming.

Bad pattern, do not do this

• Do not send 完成, 成功, 已提取, or similar status text after the final answer body.
• Do not use a progress update as the container for the final answer.
• Do not stream the final summary or final extracted answer line by line or token by token.
• Do not let the final answer remain inside a draft/preview message lifecycle.
• Do not call openclaw message send or any equivalent chat-tool delivery command during this workflow.

Preconditions

• Check the npm published version once at the start of the session with npm view @mallocfeng/chromedev version. Then check the local CLI version with chromedev version. If chromedev is missing, the local version command is unavailable, or the npm version is newer than the local version, install the explicit npm version with npm install -g @mallocfeng/chromedev@<npm-version>, then continue. Do not repeat this check for every page task unless a command call fails.
• Check whether the local middleware is already running on 127.0.0.1:8787. If it is not running, start it automatically with chromedev run, then re-check the endpoint before using MCP tools.
• If the endpoint exists but MCP calls fail with Not connected or similar connection/binding errors, run chromedev doctor first. If there are orphan/multiple chrome-devtools-mcp processes or the retry fails, run one recovery cycle: chromedev stop --all → chromedev run → retry once.
• On first connection, Chrome may show a remote debugging authorization prompt. Wait up to 30 seconds for the user to approve it.
• Treat HTTP session errors and Chrome attachment errors differently. A missing MCP HTTP session does not by itself mean Chrome authorization was lost.

Quick endpoint check

curl -i http://127.0.0.1:8787/mcp

A response like 400 Bad Request with No sessionId means the endpoint exists and is healthy. This is expected because the daemon serves short lived stateless HTTP requests while keeping the upstream Chrome connection alive in the background.

Workflow

1. Confirm the latest npm version once per session with npm view @mallocfeng/chromedev version, then compare it with chromedev version. If the local command is missing, too old to print a version, or older than npm, force install the explicit npm version with npm install -g @mallocfeng/chromedev@<npm-version>.
2. Confirm the middleware is running. If not, run chromedev run and then re-check http://127.0.0.1:8787/mcp.
3. Connect to http://127.0.0.1:8787/mcp.
4. If any MCP tool call fails with connection-style errors such as Not connected, target closed, or similar startup/binding failures, run chromedev doctor to check for stale daemon state or multiple DevTools clients. Then try exactly one recovery cycle if needed: chromedev stop --all → chromedev run → retry the original page operation once.
5. If the user explicitly provided a URL, open the target page first with new_page. Do not try to recover by opening a blank page or any synthetic page.
6. For explicit URL tasks, do not call list_pages before the first new_page.
7. After new_page, assume the new tab is already the selected page. Do not call list_pages/select_page unless take_snapshot/evaluate_script fails with a "no selected page" or similar error.
8. If the user did not provide a URL and wants the current page or an existing tab, then inspect current pages and select the right page.
9. Prefer evaluate_script for a fast, bounded extraction (title/byline/time/body) first, then fall back to take_snapshot when the DOM is hard to parse or blocked.
10. Use wait_for only when the page is still loading and you know a stable text or UI state to wait on (keep it short).
11. Return extracted data, not protocol noise.
12. Once the final answer body is ready, buffer the full final answer and deliver only that final answer as one complete non-streaming output.

How to interpret requests

When the user gives a URL, treat it as a request to read that page.

• Open the target page directly first.
• Do not attempt recovery by opening about:blank or any placeholder page.
• Do not inspect existing pages before the first new_page for explicit URL tasks.
• If the user asks for summary, return a summary.
• If the user asks for page content, return extracted content.
• If the user asks for list content, return the visible list items in order.

Preferred tool order

• For explicit URL tasks: new_page.
• Then: evaluate_script (fast extract, keep output bounded).
• Fallback: take_snapshot (slower, but robust when the DOM is messy).
• For current-page or existing-tab tasks: list_pages, then select_page.
• wait_for only when you have a reliable, small string to wait on.
• take_screenshot only when visuals matter.

Command line client

The npm package includes a reusable request client exposed through:

• chromedev call <tool_name> [json_arguments]

It connects to the local HTTP MCP endpoint and calls one tool. Prefer chromedev call because it uses the request client bundled with the installed npm package and does not depend on the current skill directory containing a scripts folder.

This skill source also includes the same reusable script for development:

• scripts/http_mcp_call.mjs

The script is not the persistent connection holder. It is only a request client for the already running local daemon.

When using chromedev call, the npm package's bundled dependencies should be used automatically. Only install @modelcontextprotocol/sdk in the current workspace if you intentionally run scripts/http_mcp_call.mjs directly and the dependency is missing.

WORKSPACE="$(git rev-parse --show-toplevel 2>/dev/null || pwd -P)"
cd "$WORKSPACE" && npm install @modelcontextprotocol/sdk

Common commands

Check and install the latest published chromedev

REMOTE_VERSION="$(npm view @mallocfeng/chromedev version 2>/dev/null || true)"
LOCAL_VERSION="$(chromedev version 2>/dev/null | sed -E 's/^.*@([0-9]+\.[0-9]+\.[0-9]+).*$/\1/' || true)"

if [ -z "$REMOTE_VERSION" ]; then
  echo "Could not read @mallocfeng/chromedev version from npm"
elif [ -z "$LOCAL_VERSION" ] || node -e 'const [l,r]=process.argv.slice(1); const a=l.split(".").map(Number); const b=r.split(".").map(Number); process.exit(b[0]>a[0] || (b[0]===a[0] && b[1]>a[1]) || (b[0]===a[0] && b[1]===a[1] && b[2]>a[2]) ? 0 : 1)' "$LOCAL_VERSION" "$REMOTE_VERSION"; then
  npm install -g "@mallocfeng/chromedev@$REMOTE_VERSION"
  hash -r 2>/dev/null || true
fi

Start the service if the endpoint is not already listening

curl -s -o /dev/null http://127.0.0.1:8787/mcp || chromedev run

Recover from a stuck/not-connected session

chromedev doctor
chromedev stop --all
chromedev run

List current pages

chromedev call list_pages

Open a page

chromedev call new_page '{"url":"<URL>","timeout":30000}'

For explicit URL tasks, do this first. Do not begin by opening about:blank or any recovery page.

Get a snapshot

chromedev call take_snapshot

Extract title and a bounded article body (fast path)

chromedev call evaluate_script '{"function":"() => {\n  const pick = () => document.querySelector(\"article\") || document.querySelector(\"main\") || document.body;\n  const el = pick();\n  const text = (el?.innerText || \"\").replace(/\\s+\\n/g, "\\n").trim();\n  return {\n    title: document.title,\n    url: location.href,\n    byline: document.querySelector(\"[data-testid=byline]\")?.innerText || document.querySelector(\".byline\")?.innerText || \"\",\n    time: document.querySelector(\"time\")?.getAttribute(\"datetime\") || document.querySelector(\"time\")?.innerText || \"\",\n    text: text.slice(0, 20000),\n    textLength: text.length\n  };\n}"}'

Note: never forward raw URL in Telegram progress messages.

Wait for specific text

chromedev call wait_for '{"text":["<TEXT>"],"timeout":30000}'

Extraction guidance

• Fast path first: use evaluate_script to extract a bounded body string (e.g. article/main innerText) plus title/byline/time, then summarize from that.
• Fallback: use take_snapshot for readable page content and structure when extraction is blocked or the DOM is hard to parse.
• Use evaluate_script for precise fields, arrays, links, prices, tables, or JSON shaped output.
• Use wait_for only if a page is visibly still loading and you know a reliable text to wait on.
• For list pages, preserve order and return item text and link targets.
  • Link targets are allowed in the final user facing extraction output.
  • Link targets are never allowed in Telegram progress messages.
• For article pages, extract title, author, publish date when visible, then the article body text.

Operational notes

• Keep browser state intact unless the user asked for navigation or interaction.
• If a tool call hangs near connection start, assume Chrome may be waiting for the authorization dialog.
• Prefer returning concise extracted data over full raw snapshots unless the user asked for raw output.
• Do not expose the local MCP endpoint outside 127.0.0.1.
• Do not treat a per call MCP HTTP session as the source of truth for Chrome attachment. The daemon process is the long lived connection holder.
• Do not send Telegram progress updates during this workflow.
• Do not send a final Telegram/chat-tool success status after the final extracted answer or summary is ready.
• In Telegram-like channels with stream previews, never stream the final answer through the preview channel; finalize the content first and then send the final answer once.