Chrome DevTools MCP Skill

Use Chrome DevTools MCP through UXC over local stdio for page navigation, DOM/a11y snapshots, network inspection, console inspection, and performance tooling...

Security Scan

The skill's instructions mostly match its stated purpose (driving Chrome DevTools via MCP), but there are a few mismatches and supply‑chain/runtime risks you should consider before installing.

Purpose & Capability

Name/description align with the instructions: the skill drives Chrome DevTools MCP via uxc and npx. However, registry metadata declares no required binaries/env but the SKILL.md explicitly requires uxc and npx (and network access). The metadata omission is an inconsistency that could mislead users about runtime requirements.

Instruction Scope

SKILL.md stays on purpose: it only instructs using uxc and npx to run chrome-devtools-mcp and to attach to local Chrome (autoConnect, browserUrl, or headless isolated). It does recommend evaluate_script and other page-mutating actions — which are expected for a DevTools skill but inherently grant access to page DOM, cookies, localStorage, and network traces. The doc includes explicit guardrails (confirm before mutating, prefer read-first flows).

Install Mechanism

This is instruction-only (no packaged install) and relies on dynamic npx invocations (npx -y chrome-devtools-mcp@latest). Using the unpinned '@latest' tag means remote code can change over time (supply‑chain risk). The SKILL.md references the GitHub repo, but there is no pinned version nor verification step. Moderate risk from dynamic fetching via npm.

Credentials

The skill requests no credentials or env vars. That matches its local-dev tooling purpose. It does expect access to local Chrome remote-debugging endpoints (127.0.0.1:9222) and to network for package fetch; both are reasonable for this functionality.

Persistence & Privilege

The skill does not require always:true and is invocable normally. It recommends creating uxc link commands (chrome-devtools-mcp-cli, etc.), which will persist wrapper commands via uxc but doesn't appear to modify other skills or system-wide configs. Creating long‑lived link wrappers is a behavior to be aware of but not inherently privileged.

What to consider before installing

This skill appears to do what it says (drive Chrome DevTools over MCP) but take precautions before installing: 1) The SKILL.md requires uxc and npx even though the registry metadata lists none—make sure you have those tools and understand the runtime requirements. 2) It uses 'npx ...@latest' which dynamically fetches and runs code from the npm ecosystem; prefer a pinned specific version or examine the package source before running. 3) Running this skill against a live browser can expose page DOM, cookies, localStorage and network traffic — avoid attaching it to browsers with sensitive logged‑in sessions unless you trust the package. 4) The skill suggests creating persistent 'uxc link' commands; be aware they create entrypoints you or other processes could invoke. If you need higher assurance, ask the author to: provide explicit required-binaries metadata, pin the package version, include checksum or provenance for the npm package, and document exactly what evaluate_script can do and when it will be used.

Use this skill to run Chrome DevTools MCP operations through uxc using a fixed stdio endpoint.

Reuse the uxc skill for generic MCP discovery, daemon reuse, JSON envelope parsing, and error handling.

Prerequisites

• uxc is installed and available in PATH.
• npx is available in PATH (Node.js installed).
• Chrome 144+ is running locally with remote debugging enabled from chrome://inspect/#remote-debugging if you use the default live-browser flow.
• Network access is available for first-time chrome-devtools-mcp package fetch.

Core Workflow (Chrome DevTools MCP-Specific)

Endpoint candidate inputs before finalizing:

• Raw package form from official docs:
  • npx chrome-devtools-mcp@latest
• Reliable non-interactive form:
  • npx -y chrome-devtools-mcp@latest
• Default live-browser endpoint for this skill:
  • npx -y chrome-devtools-mcp@latest --autoConnect --no-usage-statistics
• Explicit browser-url endpoint:
  • npx -y chrome-devtools-mcp@latest --browserUrl http://127.0.0.1:9222 --no-usage-statistics
• Fallback isolated endpoint:
  • npx -y chrome-devtools-mcp@latest --headless --isolated --no-usage-statistics
• Running local Chrome auto-connect mode:
  • npx -y chrome-devtools-mcp@latest --autoConnect --no-usage-statistics

1. Verify protocol/path from official source and probe:
   • Official source:
     • https://github.com/ChromeDevTools/chrome-devtools-mcp
   • probe candidate endpoints with:
     • uxc "npx -y chrome-devtools-mcp@latest --autoConnect --no-usage-statistics" -h
   • Confirm protocol is MCP stdio (protocol == "mcp" in envelope).
2. Detect auth requirement explicitly:
   • Run host help or a minimal read call and inspect envelope.
   • Default local stdio flow requires no OAuth/API key.
   • Existing Chrome attachment requires remote debugging to be enabled separately, but not API auth.
3. Use a fixed link command by default:
   • command -v chrome-devtools-mcp-cli
   • If missing, create it:
     • uxc link chrome-devtools-mcp-cli "npx -y chrome-devtools-mcp@latest --autoConnect --no-usage-statistics"
   • Optional explicit browser-url link:
     • command -v chrome-devtools-mcp-port
     • uxc link chrome-devtools-mcp-port "npx -y chrome-devtools-mcp@latest --browserUrl http://127.0.0.1:9222 --no-usage-statistics"
   • Optional isolated fallback link:
     • command -v chrome-devtools-mcp-isolated
     • uxc link chrome-devtools-mcp-isolated "npx -y chrome-devtools-mcp@latest --headless --isolated --no-usage-statistics"
   • chrome-devtools-mcp-cli -h
4. Inspect operation schema before execution:
   • chrome-devtools-mcp-cli new_page -h
   • chrome-devtools-mcp-cli take_snapshot -h
   • chrome-devtools-mcp-cli list_network_requests -h
   • chrome-devtools-mcp-cli lighthouse_audit -h
5. Prefer read-first interaction:
   • Start with new_page, list_pages, take_snapshot, list_network_requests, or list_console_messages.
6. Confirm before mutating page state:
   • click
   • fill
   • fill_form
   • press_key
   • upload_file
   • evaluate_script
   • handle_dialog

Guardrails

• Keep automation on the JSON output envelope; do not rely on --text.
• Use chrome-devtools-mcp-cli as the default command path.
• Prefer the live-browser default endpoint when you need real logged-in state, current tabs, network diagnostics, console inspection, or performance analysis.
• Prefer --autoConnect first when browser-side remote debugging is available.
• Use chrome-devtools-mcp-port only when you intentionally run a Chrome instance with --remote-debugging-port=9222.
• If no debuggable Chrome is available, fallback to chrome-devtools-mcp-isolated.
• Prefer take_snapshot over screenshots for model-action loops.
• Prefer list_network_requests / get_network_request over raw script evaluation when inspecting network behavior.
• Treat lighthouse_audit, performance_start_trace, and take_memory_snapshot as heavier operations; use them intentionally.
• Use evaluate_script only when an existing higher-level DevTools tool cannot answer the question.

References

• Invocation patterns:
  • references/usage-patterns.md