{ "SchemaVersion": "1", "Kind": "DirectoryEntry", "SubjectType": "mcp-server", "Slug": "chrome-devtools-mcp", "Name": "Chrome DevTools MCP", "Title": "Chrome DevTools MCP MCP Server | Pod", "Description": "MCP server for Chrome DevTools", "CanonicalUrl": "https://askpod.ai/mcp/chrome-devtools-mcp", "MarkdownUrl": "https://askpod.ai/mcp/chrome-devtools-mcp.md", "JsonUrl": "https://askpod.ai/mcp/chrome-devtools-mcp.json", "DatePublished": "2026-08-31T23:50:54.202Z", "DateModified": "2026-08-31T23:50:54.202Z", "RegistryName": "io.github.ChromeDevTools/chrome-devtools-mcp", "RepositoryUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp", "VerificationStatus": "unverified", "Identities": [], "Sources": [ { "Source": "github_issues", "LastSeenAt": "2026-08-31T23:50:54.202Z" }, { "Source": "official_mcp_registry", "ExternalId": "io.github.ChromeDevTools/chrome-devtools-mcp", "LastSeenAt": "2026-08-31T23:50:54.202Z" } ], "Categories": [], "FirstParty": false, "Deployments": [ { "Kind": "package", "PackageRegistry": "npm", "PackageIdentifier": "chrome-devtools-mcp", "ConfigSnippet": "{\n \"mcpServers\": {\n \"chrome-devtools-mcp\": {\n \"command\": \"npx\",\n \"args\": [\n \"-y\",\n \"chrome-devtools-mcp\"\n ]\n }\n }\n}" } ], "Tools": { "Claimed": [], "ClaimedCount": 0, "Observed": null, "ObservedCount": null, "Verified": false, "Mismatch": null }, "Measured": null, "Usage": { "Registry": "npm", "DownloadsLast30d": 9951385 }, "Issues": [ { "Title": "Isolated/temp-profile Chrome survives MCP death on macOS (puppeteer_dev_chrome_profile orphans, ppid=1)", "Excerpt": "## Summary\n\nOn macOS, Chrome instances launched by `chrome-devtools-mcp` via Puppeteer's **temporary profile** (`puppeteer_dev_chrome_profile-*`) keep running after the MCP server process is gone. They reparent to `launchd` (`ppid=1`) and accumulate for hours.\n\nThis is **not** \"please add a close-browser MCP tool\" (#484) and **not** \"idle page CPU in connected mode\" (#2599). It is also distinct from #1765, where SIGTERM of a still-alive MCP server *does* clean up Chrome. The hole is: **MCP dies ", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2621", "PublishedAt": "2026-08-26T16:12:31.000Z", "State": "open", "Comments": 1, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Question: optional release-evidence gate for MCP artifact workflows", "Excerpt": "Hi maintainers — I’m maintaining a small, independent downstream consumer for the experimental MCP Registry #1404 receipt shape: https://github.com/yandexuanxuan/mcp-evidence-gate\n\nWould you be open to trying one optional `workflow_dispatch` job on a fork or branch that verifies a release artifact with this immutable Action reference?\n\n yandexuanxuan/mcp-evidence-gate@7b1569284e321976b4b61378c223ce6a28fbdb9b (v0.1.0-alpha.1)\n\nThe Action does not scan source, install packages in the consumer r", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2616", "PublishedAt": "2026-08-26T07:53:53.000Z", "State": "closed", "Comments": 1, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "docs(security): add a HOL Guard client-side tool-call protection example", "Excerpt": "### Context\n\n`SECURITY.md` correctly puts validation of inputs, including tool calls and parameters, on the calling agent/client, and recommends client-side precautions against prompt injection. There is currently no concrete example showing users how to put a pre-tool security gate in front of `chrome-devtools-mcp`.\n\n### Proposal\n\nWould you be open to a small optional documentation addition, ideally in `SECURITY.md` or the security-facing usage docs, for **HOL Guard** as a client-side protectio", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2611", "PublishedAt": "2026-08-24T07:08:58.000Z", "State": "closed", "Comments": 1, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Long-lived server can retain active page indefinitely and keep consuming CPU after client activity stops", "Excerpt": "### Summary\n\nOn a long-lived self-hosted `chrome-devtools-mcp` 1.7.0 deployment, a page left open after an agent finishes can continue consuming substantial CPU indefinitely even though there are no MCP tool calls in flight.\n\nThis appears distinct from the 1.6.0 memory/source-map issues in #2431 / #2456, which are marked fixed in 1.7.0. The problem here is lifecycle: an active page remains live forever unless the client explicitly navigates it away/closes it or the server/browser process is recy", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2599", "PublishedAt": "2026-08-20T12:15:30.000Z", "State": "open", "Comments": 3, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Logpoints: log runtime values without modifying source code", "Excerpt": "### Is your feature request related to a problem? Please describe.\n\nWhen an agent needs to know what a page actually *does* at runtime — which branch\nran, what a value held, in what order events fired — its only real option today is to\nedit the source, add `console.log`, rebuild, reload, read the output, and then remove\nthe calls again. That has four costs:\n\n1. It's a **write to the user's codebase to answer a read-only question**, and stray\n `console.log` calls get left behind and committed.\n", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2584", "PublishedAt": "2026-08-17T07:00:11.000Z", "State": "open", "Comments": 1, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Lighthouse secondary fetches can cross --allowed-url-pattern after redirects", "Excerpt": "### Description of the bug\n\nIn `chrome-devtools-mcp@1.7.0`, Lighthouse secondary fetches for\n`/robots.txt` and `/llms.txt` can follow an HTTP redirect from an allowed\norigin to an origin excluded by `--allowed-url-pattern`.\n\nThe direct control behaves as expected: a normal subresource request from the\naudited page to the excluded origin is blocked and the excluded server receives\nno request. During `lighthouse_audit`, however, the same excluded server\nreceives the redirected `/robots.txt` and `/", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2567", "PublishedAt": "2026-08-12T19:48:05.000Z", "State": "closed", "Comments": 8, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Large Audits backlog starves all page-facing tool calls", "Excerpt": "### Description of the bug\n\nWhen `chrome-devtools-mcp` connects to a long-lived Chrome session whose page targets have accumulated a large DevTools Audits backlog, page-facing MCP tools consistently time out even though the browser-level CDP endpoint and every individual page target remain responsive.\n\nIn the affected session, the MCP process repeatedly writes:\n\n```text\nNo handler registered for issue code PerformanceIssue\n```\n\nThis looks like a regression or broader consequence of #1850 / #1852", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2556", "PublishedAt": "2026-08-11T23:29:09.000Z", "State": "closed", "Comments": 9, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Add option to automatically skip JavaScript debugger pauses", "Excerpt": "### Is your feature request related to a problem? Please describe.\n\nWhen using chrome-devtools-mcp for browser automation, some pages contain `debugger;` statements or anti-debugging scripts.\n\nOnce the MCP server connects through Chrome DevTools Protocol (CDP), these debugger statements cause JavaScript execution to pause, making the page appear frozen. This affects automation workflows because actions such as clicking, evaluating scripts, and navigation may become unreliable.\n\nCurrently, users ", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2539", "PublishedAt": "2026-08-11T07:12:27.000Z", "State": "closed", "Comments": 2, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Feature Suggestion: Optional token metering & paid API key support via `neuforge-pay`", "Excerpt": "Hi @ChromeDevTools,\n\nLove the work on `ChromeDevTools/chrome-devtools-mcp`! As usage grows across AI agent frameworks, server compute costs can start adding up quickly.\n\nWould you be open to adding an optional usage metering & billing decorator using `neuforge-pay`? It allows developers hosting instance deployments of your MCP server to automatically meter tokens, track real-time LLM COGS, and attach paid Stripe keys in 3 lines of code.\n\nExample Integration:\n```python\nfrom neuforge_pay import me", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2537", "PublishedAt": "2026-08-11T05:20:15.000Z", "State": "closed", "Comments": 1, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "`--screenshotMaxWidth` returns images at twice the bound on a HiDPI display", "Excerpt": "### Description of the bug\n\n`--screenshotMaxWidth` caps the image before the device scale factor is applied, so on a 2x display the returned screenshot is twice the requested width. Asking for 800 gives back 1600, four times the area.\n\nThat matters most where the flag came from: #1823 added it to keep screenshots under the 8000 pixel limit behind #879, and a cap picked to stay under that would still exceed it by the same factor.\n\nThe overshoot is also what gets billed. Anthropic prices an image ", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2531", "PublishedAt": "2026-08-10T10:32:47.000Z", "State": "closed", "Comments": 4, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Unknown CLI flags are silently ignored, so a typo'd `--browserUrl` launches a browser instead of connecting", "Excerpt": "### Description of the bug\n\nThe MCP server accepts unrecognized CLI flags without an error or a warning, so a single character typo in `--browserUrl` is silent and the server falls back to launching its own browser. The agent then works against an empty browser while its configuration says it is attached to an existing one.\n\nThe CLI's `start` command launches the same server under `.strict()`, with `--browserUrl` as its own documented example, so the two entry points disagree about the same flag", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2530", "PublishedAt": "2026-08-10T10:25:17.000Z", "State": "closed", "Comments": 2, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "URL allow/block policy not re-validated after HTTP redirect in loadResource", "Excerpt": "### Description of the bug\n\nThe URL allowlist/blocklist policy is only validated against the initial navigation target. If an allowed origin responds with an HTTP redirect (e.g. a 302), the browser follows it to the final destination without re-checking that destination against the configured policy.\n\nThis means a URL that passes the allow/block check can still cause navigation to a URL that the policy was specifically configured to block, as long as an attacker can influence a redirect response", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2502", "PublishedAt": "2026-08-08T05:55:03.000Z", "State": "closed", "Comments": 2, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "`performance_start_trace` silently truncates traces by enabling `invalidationTracking`", "Excerpt": "### Description of the bug\n\n`performance_start_trace` always enables `disabled-by-default-devtools.timeline.invalidationTracking`. On a page that invalidates style heavily, that category fills the trace buffer within a few hundred milliseconds, so the recording stops long before the interaction being measured finishes. Nothing reports this: the tool returns a normal result and the trace parses fine, it just no longer contains the work you were looking at.\n\nThe category list carries this comment:", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2499", "PublishedAt": "2026-08-07T23:10:55.000Z", "State": "closed", "Comments": 3, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "[Security] DevTools source-map requests bypass --blocked-url-pattern & defense-in-depth gaps", "Excerpt": "### Description of the bug\n\nDuring a security review (previously reported to Google VRP, who suggested opening a public issue here), I identified a security control bypass in DevTools resource loading, along with a few defense-in-depth gaps in the default configuration.\n\nThe core issue is that --blocked-url-pattern does not block internal network requests made by Chrome's DevTools source-map resolver, allowing an attacker-controlled webpage to bypass network restrictions and interact with localh", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2493", "PublishedAt": "2026-08-07T02:00:08.000Z", "State": "closed", "Comments": 1, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "A client that never answers roots/list blocks every tool for 60s", "Excerpt": "### Description of the bug\n\n`getContext()` awaits `updateRoots()` whenever it builds a new `McpContext`, and `ToolHandler.handle()` has already taken the tool mutex by then. So the server blocks on a `roots/list` request to the client while holding the lock that serializes every tool call.\n\nIf the client negotiated the `roots` capability but does not answer, that request only settles when the SDK's default request timeout of 60s expires. The tool call then completes normally – it never needed th", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2476", "PublishedAt": "2026-08-05T13:09:51.000Z", "State": "closed", "Comments": 0, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Release workflow downloads `mcp-publisher` from another org's `releases/latest` unpinned, then hands that binary the OIDC publishing credential", "Excerpt": "`.github/workflows/publish-to-npm-on-tag.yml`, as on `main`.\n\n## The shape\n\n`id-token: write` is granted at **workflow** level, so every job inherits it:\n\n```yaml\npermissions:\n id-token: write # Required for OIDC\n contents: read\n```\n\nThat permission is the publishing credential — the npm step uses trusted publishing and there is no\ntoken secret anywhere in the file:\n\n```yaml\nnpm publish --provenance --access public\n```\n\nThe second job inherits it and declares no override:\n\n```yaml\n publish-to", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2470", "PublishedAt": "2026-08-05T00:58:44.000Z", "State": "closed", "Comments": 2, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Support isolatedContext page-scoped tool routing for multi-agent workflows", "Excerpt": "## Problem\n\nPR #991 adds `isolatedContext` to `new_page`, enabling agents to create pages with isolated cookies, storage, and sessions. However, all subsequent tools (`take_screenshot`, `take_snapshot`, `navigate_page`, `evaluate_script`, `emulate`, `click`, `fill`, `press_key`, etc.) resolve their target page via the global `getSelectedPage()`. This means agents must call `select_page` before each operation, which introduces a race condition in multi-agent workflows.\n\nThe internal mutex seriali", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/1019", "PublishedAt": "2026-02-23T11:09:10.000Z", "State": "closed", "Comments": 23, "Reporter": "Contributor", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Accessibility tree/element(s) snapshot - exposing semantics, roles, states, ARIA,...", "Excerpt": "**Is your feature request related to a problem? Please describe.**\nI miss more functionality to extract accessibility information from DevTools with MCP. One basic thing that would be a great start is perhaps an snapshot of the accessibility tree (probably as an extension to the \"text-only\" snapshot or similar.\n\n**Describe the solution you'd like**\nAdd a feature for accessibility tree snapshot of the whole page or of a single selector (CSS, XPATH) or a group of selectors (CSS, XPATH) - so that I", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/363", "PublishedAt": "2025-10-13T08:25:20.000Z", "State": "closed", "Comments": 23, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "A tool to \"Select an element in the page to inspect it\"", "Excerpt": "**Is your feature request related to a problem? Please describe.**\n\n`Select an element in the page to inspect it` could arguably be the most used Chrome Dev Tools \"tool\".\n\nThis allows the (human) programmer to focus on just that part of the DOM he is interested in. On the other hand, most tools we put in the hands of AI agents today always give back the full DOM. The AI is then forced to first filter out all the irrelevant parts leading to the context window filling up extremely fast, and the ag", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/268", "PublishedAt": "2025-10-04T02:51:50.000Z", "State": "open", "Comments": 26, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Cannot connect to the Chrome-devtools mcp server using the claude code", "Excerpt": "**Describe the bug**\nclaude code showed it's failed to reconnect to chrome-devtools when I reconnect it.\n\n\"Image\"\n\n**To Reproduce**\n1. exec command:\nclaude mcp add chrome-devtools npx chrome-devtools-mcp@latest\n2. exec command:\nclaude code\n3. found 1 mcp failed\n\n\"Image\"\n\n\"Image\"", "SourceUrl": "https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/111", "PublishedAt": "2025-09-24T10:05:33.000Z", "State": "closed", "Comments": 25, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" } ], "Observations": [], "ObservationCount": 0, "Related": [], "Indexable": true, "ContentMarkdown": "# Chrome DevTools MCP MCP Server\n\nMCP server for Chrome DevTools\n\n**Publisher claimed.** No tool list reported, and Pod has not connected to this server.\n\n## Status\n\nPod has not dialled Chrome DevTools MCP yet, so everything on this page is what its publisher reported rather than what we observed. Registries describe servers; they do not connect to them. Until a check runs, treat the tool list below as a claim.\n\n## Connect\n\nPublished as `chrome-devtools-mcp` on npm. Runs locally.\n\n## Known issues\n\n**408 problems reported by people outside the maintainer team.** Issues filed by the project's own owners, members and collaborators are excluded — those are release checklists and internal refactors, not things that will go wrong for you. Showing 12.\n\n### Most discussed\n\n### Support isolatedContext page-scoped tool routing for multi-agent workflows\n\n## Problem\n\nPR #991 adds `isolatedContext` to `new_page`, enabling agents to create pages with isolated cookies, storage, and sessions. However, all subsequent tools (`take_screenshot`, `take_snapshot`, `navigate_page`, `evaluate_script`, `emulate`, `click`, `fill`, `press_key`, etc.) resolve their target page via the global `getSelectedPage()`. This means agents must call `select_page` before each operation, which introduces a race condition in multi-agent workflows.\n\nThe internal mutex seriali\n\n[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/1019) · 2026-02-23 · closed · outside contributor · 23 comments\n\n### Accessibility tree/element(s) snapshot - exposing semantics, roles, states, ARIA,...\n\n**Is your feature request related to a problem? Please describe.**\nI miss more functionality to extract accessibility information from DevTools with MCP. One basic thing that would be a great start is perhaps an snapshot of the accessibility tree (probably as an extension to the \"text-only\" snapshot or similar.\n\n**Describe the solution you'd like**\nAdd a feature for accessibility tree snapshot of the whole page or of a single selector (CSS, XPATH) or a group of selectors (CSS, XPATH) - so that I\n\n[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/363) · 2025-10-13 · closed · external user · 23 comments\n\n### A tool to \"Select an element in the page to inspect it\"\n\n**Is your feature request related to a problem? Please describe.**\n\n`Select an element in the page to inspect it` could arguably be the most used Chrome Dev Tools \"tool\".\n\nThis allows the (human) programmer to focus on just that part of the DOM he is interested in. On the other hand, most tools we put in the hands of AI agents today always give back the full DOM. The AI is then forced to first filter out all the irrelevant parts leading to the context window filling up extremely fast, and the ag\n\n[Read the thread](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/268) · 2025-10-04 · open · external user · 26 comments\n\n### Cannot connect to the Chrome-devtools mcp server using the claude code\n\n**Describe the bug**\nclaude code showed it's failed to reconnect to chrome-devtools when I reconnect it.\n\n\"Image\"\n\n**To Reproduce**\n1. exec command:\nclaude mcp add chrome-devtools npx chrome-devtools-mcp@latest\n2. exec command:\nclaude code\n3. found 1 mcp failed\n\n