Chrome devtools mcp
Skill mauriciovieira/skills/skills/engineering/chrome-devtools-mcp
Skills for real engineers - not vibe coding
npx -y skills add mauriciovieira/skills --skill chrome-devtools-mcpAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Scaffolds a dedicated Chrome instance with an isolated, persistent profile plus a chrome-devtools-mcp (CDP) server registration, so Claude can inspect authenticated network traffic in a web app - list open tabs, navigate, and read real requests (method, URL, sensitive headers, body, response shape) to reverse-engineer an API. Use when the user wants to inspect authenticated traffic in a browser, capture real headers/cookies for an integration, reverse-engineer a web app's undocumented API, or asks to set up chrome-devtools-mcp / CDP debugging.
SKILL.md
5.3 KB, as published. Nobody here has run it
chrome-devtools-mcp
Scaffolds the setup needed to inspect authenticated network traffic through
chrome-devtools-mcp (Google's official CDP MCP server - not Playwright). Generates:
scripts/launch-chrome.sh- opens a dedicated Chrome instance with--remote-debugging-portand an isolated--user-data-dirprofile that persists login state across runs.docs/chrome-mcp-setup.md- the usage flow: launch, log in once, register the MCP server, capture requests, turn them into probe scripts.scripts/probe/- dir (with a.gitkeep) where each captured request later becomes a minimalfetch-based reproduction script.
When to use
- Reverse-engineering an app's API by watching what the browser actually sends when logged in.
- Capturing real
Authorization/Cookie/CSRF headers to wire up an integration or MCP tool. - Any task that needs
list_pages,navigate_page,get_network_requests, orevaluate_scriptagainst an authenticated session.
Do NOT use when the target API is already documented, or when an existing
scripts/launch-chrome.sh / docs/chrome-mcp-setup.md is present for this project - diff
manually instead, this skill refuses to overwrite unless FORCE=1.
Inputs to ask the user (in this order)
- Project slug (kebab-case) - names the isolated profile dir (
~/.chrome-<slug>-profile) and titles the doc. - CDP port - e.g.
9222. Ask if another project's Chrome is already using it; each project should get its own port so instances don't collide. - Start URL - the app URL to open on launch (login page or the target feature).
- Target dir - project root to scaffold into (default
.).
How to scaffold
Run the scaffold script from the target project root:
PROJECT=myapp PORT=9222 START_URL=https://app.example.com/login \
TARGET_DIR=. ~/.claude/skills/chrome-devtools-mcp/scripts/scaffold.sh
The script:
- Renders
templates/scripts/launch-chrome.sh.tmpltoscripts/launch-chrome.sh(executable). - Renders
templates/docs/chrome-mcp-setup.md.tmpltodocs/chrome-mcp-setup.md. - Creates
scripts/probe/for later per-request reproduction scripts. - Refuses to overwrite existing files unless
FORCE=1.
Register the MCP server
Edit (or create) .mcp.json at the project root directly - merge into any existing
mcpServers, don't overwrite other entries:
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest", "--browserUrl", "http://127.0.0.1:9222"]
}
}
}
Then tell the user to restart Claude Code so the tools (list_pages, navigate_page,
get_network_requests, evaluate_script, etc) appear.
After scaffold
Tell the user, in order:
./scripts/launch-chrome.sh- opens the dedicated Chrome instance.- Log in manually (user/password/2FA) once in that window; the isolated profile keeps it logged in on later launches.
- Restart Claude Code to pick up the new MCP server.
- Use
list_pagesto confirm the right tab, thenget_network_requestsfiltered by the target domain while exercising the feature. - For each interesting request, write a
scripts/probe/<name>.mjsusing plainfetchwith the same headers, to validate reproducibility outside the browser before wrapping it as an MCP tool undersrc/.
Full walkthrough lives in the generated docs/chrome-mcp-setup.md.
Known constraints baked in
- CDP is Chrome's own protocol - the MCP server talks straight to it, no Playwright layer.
- The isolated profile is the whole point: it is what makes login persist between runs without re-authenticating on every session.
- One port and one profile per project, so multiple projects' dedicated Chrome instances don't collide.
Security notes
- The CDP port has no authentication of its own - it is only safe because it binds to localhost. Never expose it through a tunnel or a public interface.
- The profile dir (
~/.chrome-<project>-profile) holds real session cookies. It lives outside the repo; never commit it, never let it sync through Dropbox/iCloud/etc. - No token, cookie, or captured response body may enter the repo - not in probe scripts, not in commit messages, not in the generated doc.
Common mistakes
| Mistake | Fix |
|---|---|
| Reusing one port/profile across projects | Give each project its own PORT and PROJECT slug; instances collide otherwise. |
Overwriting another .mcp.json server entry | Merge the chrome-devtools key in, don't replace the whole file. |
| Committing a probe script with a real captured token | Read secrets from env vars or a gitignored local file, never hardcode them. |
Forgetting to restart Claude Code after editing .mcp.json | New MCP tools only appear after a restart. |