How do I use chrome-remote-debugging-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@chrome-remote-debugging-mcp Navigate to https://example.com" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

chrome-remote-debugging-mcp

by danilin-em

Overview Schema Related Servers Score Discussions

Python

Hybrid

chrome-remote-debugging-mcp

MCP server that controls a running Chrome over the Chrome DevTools Protocol (CDP). It connects to Chrome's remote-debugging endpoint and exposes browser control as MCP tools.

Requirements

Python ≥ 3.10
A Chrome/Chromium started with remote debugging:
```
google-chrome --remote-debugging-port=9222
```

Related MCP server: @nimbus21.ai/chrome-devtools-mcp

Register with an MCP client

Example mcpServers entry:

{
  "mcpServers": {
    "chrome-remote-debugging": {
      "command": "uvx",
      "args": ["chrome-remote-debugging-mcp"],
      "env": { "CDP_URL": "http://localhost:9222" }
    }
  }
}

Tools

Tool	Args	Returns
`ping`	—	`{connected, cdp_url, browser, protocol}`
`list_tabs`	—	`{"tabs": [{id, title, url, type}, ...]}`
`navigate`	`url`, `tab_id?`	`{tab_id, url, frameId}`
`evaluate`	`expression`, `tab_id?`	`{tab_id, value, type}`
`cdp_command`	`method`, `params?`, `tab_id?`	`{tab_id, method, result}`

cdp_command is a raw CDP escape hatch: pass any CDP method + params and get the raw response, for cases the typed tools above don't cover. It targets a page socket, so page-domain methods work (Page.*, DOM.*, Runtime.*, Network.*, …); browser-level domains (Browser.*, Target.*) do not.

On any Chrome connection problem a tool returns {"error": "..."} instead of crashing.

Configuration

Env var	Default	Meaning
`CDP_URL`	`http://localhost:9222`	Chrome remote-debugging origin

SSH tunnel (optional)

To control a Chrome that only listens on a remote host's loopback, set:

Env var	Default	Meaning
`CDP_URL`	`http://localhost:9222`	Chrome endpoint. With a tunnel active, the remote-side address to forward to.
`SSH_PROXY_TO`	unset	SSH target, e.g. `user@remote`. Presence enables the tunnel.
`SSH_PROXY_PORT`	unset	Fixed local port. Auto-assigned when unset.

The server runs ssh -N -L 127.0.0.1:<local>:<host>:<port> <target> and points CDP at the forwarded port. Requires key-based SSH auth (BatchMode=yes) and the ssh client on PATH. The tunnel uses StrictHostKeyChecking=accept-new (trust-on-first-use: unknown host keys are accepted automatically on first connect).

Develop

uv sync        # venv + runtime + dev group
pytest -q

Locally, from a checkout (no publish needed):

uvx --from . chrome-remote-debugging-mcp
# or
python -m chrome_remote_debugging_mcp

Available Tools

5 tools

cdp_commandA

Send a raw CDP command and return its raw result — escape hatch.

Use when the higher-level tools don't cover what you need. method is any CDP method (e.g. "Page.captureScreenshot", "DOM.getDocument", "Network.enable"); params are its parameters. Runs against the given tab (or the first page tab). Note: this targets a page websocket, so page-domain methods work; browser-level domains (Browser.*, Target.*) do not. Returns {"tab_id", "method", "result"} or {"error": ...}.

ParametersJSON Schema

Name	Required	Description	Default
`method`	Yes
`params`	No
`tab_id`	No

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains that the tool targets a page websocket, that browser-level domains fail, and that it runs against a given tab or the first page tab. It also documents the return format. However, it does not warn about potential side effects of raw CDP commands (e.g., Page.navigate changing state), which would be useful for an escape-hatch tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: the first sentence states the purpose, the second gives usage context, and the third provides key technical details and return format. Every sentence earns its place with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential aspects for a raw CDP tool: purpose, usage context, target selection, domain limitations, and return format/error format. This is quite complete given the low complexity. The only gap is the lack of explicit mention of potential side effects or safety precautions, which would be a valuable addition for an escape hatch.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate. It does so by explaining 'method' as any CDP method with examples, 'params' as its parameters, and 'tab_id' implicitly through 'Runs against the given tab (or the first page tab).' This adds meaningful context beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Send a raw CDP command and return its raw result — escape hatch.' This is a specific verb+resource combination and it distinguishes itself from siblings by positioning itself as a low-level fallback. It also clarifies its scope (page websocket only, browser-level domains not supported), which further differentiates it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use when the higher-level tools don't cover what you need,' giving a clear guideline for when to use this tool versus alternatives. It also states the limitation that browser-level domains like Browser.* and Target.* are not supported, helping the agent avoid misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

evaluateA

Evaluate a JavaScript expression in a Chrome tab.

Uses the first page tab when tab_id is omitted. Awaits promises and returns the value by value. Returns {"tab_id", "value", "type"} on success, or {"error": ...} on failure or an uncaught JS exception.

ParametersJSON Schema

Name	Required	Description	Default
`tab_id`	No
`expression`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description itself conveys important behavioral details: promises are awaited, return values are provided with a specific structure on success, and errors are returned on failure or uncaught JS exceptions. It does not mention potential side effects or permission requirements, but the core behavior is well disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: it opens with the primary purpose, then explains default behavior, promise handling, and return format. Every sentence adds value without unnecessary padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the key operational aspects: default tab selection, promise resolution, and return/error shapes. Since there is no output schema, this return information is essential and present. Minor omissions like tab-not-found behavior or special return types prevent a perfect score, but overall it is contextually sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must clarify parameters. It explains that expression is a JavaScript expression and that tab_id defaults to the first page tab when omitted. This adds meaningful context beyond the raw schema, though it could be more detailed about expression syntax or edge cases.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: evaluating a JavaScript expression in a Chrome tab. This specific verb+resource distinction separates it from sibling tools like list_tabs and navigate, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage context by noting that the first page tab is used when tab_id is omitted, but it does not explicitly compare with alternatives or state when to use this tool over cdp_command or other siblings. The intended use is implied but not formally contrasted.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tabsA

List open Chrome page tabs.

Returns {"tabs": [{id, title, url, type}, ...]} or {"error": ...} if Chrome is unreachable.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the return format and the error behavior when Chrome is unreachable. Although it does not explicitly state the tool is read-only, the verb 'list' implies no side effects, and the error condition adds useful context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exactly two sentences, front-loaded with the primary action, and efficiently includes the return type and error condition with no unnecessary words. It is concise and well structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with no parameters and no output schema. The description fully covers its behavior: what it does, what it returns, and when it errors. That is sufficient for an agent to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the input schema is trivially complete. The description does not need to compensate for undocumented parameters, and the baseline for a zero-parameter tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'List' with the resource 'open Chrome page tabs' and further distinguishes the tool by showing the return shape (tabs with id/title/url/type). This is clearly distinct from sibling tools like navigate or evaluate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It only states what it does but does not explain when to prefer it over cdp_command or other siblings, or mention any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

navigateA

Navigate a Chrome tab to url.

Uses the first page tab when tab_id is omitted. Returns {"tab_id", "url", "frameId"} on success, {"error": ...} otherwise.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`tab_id`	No

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses return values on success and error and the default tab selection, but does not mention loading behavior, timeouts, or failure conditions beyond a generic error response.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the main verb, and contains no extraneous information. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, two parameters, and no output schema or annotations, the description provides a good overall picture including return format and default tab behavior. It could be more complete by describing load waiting or error detail, but it suffices for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds value by explaining tab_id's default behavior, but for url it only repeats the parameter name without additional format or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb and resource: 'Navigate a Chrome tab to url'. It distinguishes itself from siblings like evaluate and cdp_command by focusing on navigation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the default behavior when tab_id is omitted, which provides context for parameter usage. However, it does not explicitly discuss when to choose this tool over alternatives like evaluate or cdp_command, nor does it mention any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pingA

Check connectivity to Chrome's DevTools endpoint (CDP_URL).

Returns {"connected": True, "cdp_url", "browser", "protocol"} when Chrome answers, or {"connected": False, "cdp_url", "error": ...} when it is unreachable.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses return behavior for both success and failure cases, including the exact JSON structure. It does not mention side effects, but for a ping operation, none are expected, so this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the purpose, and includes the important return value details. Every sentence earns its place, with no redundant or verbose language.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and no output schema, the description provides sufficient detail about the return values and the operation's purpose. It could mention that it has no side effects, but the tool is simple enough that this is not a major gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is nothing to describe. Per the rubric, a baseline of 4 is appropriate since no parameter semantics need to be added beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Check connectivity to Chrome's DevTools endpoint'. It uses a specific verb ('Check') and resource ('Chrome's DevTools endpoint'), and the response format distinguishes it from sibling tools like cdp_command or navigate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage as a connectivity check, which is a sensible precursor to other CDP operations, but it does not explicitly state when to use this tool vs alternatives or provide exclusions. The context suggests it is a health check, but no direct guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Aug 2, 2026
- First observedcdp_command
- First observedevaluate
- First observedlist_tabs
- First observednavigate
- First observedping

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each high-level tool has a distinct purpose: ping checks connectivity, list_tabs enumerates tabs, navigate changes the URL, and evaluate runs JavaScript. The raw cdp_command is explicitly an escape hatch for unmatched needs, so there is minimal overlap confusion.

Naming Consistency3/5

Naming mixes bare verbs (ping, navigate, evaluate), a verb_noun (list_tabs), and a noun_noun (cdp_command). This is not fully consistent, though the intent of each tool remains clear.

Tool Count5/5

Five tools is a well-scoped set for a Chrome remote debugging server. It covers the essential actions (connect, inspect, act) without unnecessary bloat, and the raw CDP command serves as a flexible fallback.

Completeness4/5

Core workflows are covered: check connectivity, enumerate tabs, navigate, and execute JavaScript. A minor gap is the lack of tab lifecycle management (open/close) and browser-level CDP operations, but these are often accessible via cdp_command for page domains.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

browser-mcp
io.github.Shreyas-Profile
Hosted real Google Chrome MCP with per-user persistent state. Navigate, click, type, screenshot.
Browser Automation Web Scraping
2
Tap
io.github.LeonTing1010
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Browser Automation Web Scraping
217
sncro A
io.github.scottconfusedgorilla
Live browser debugging for AI assistants — DOM, console, network via MCP.
Browser Automation Developer Tools Monitoring
2
JxBrowser MCP Server A
io.github.TeamDev-IP
MCP server to assist with JxBrowser development.
Developer Tools Browser Automation
22

Related MCP Servers

superpowers-chrome
Browser Automation Web Scraping
obra
A
license
A
quality
A
maintenance
Enables direct browser control via Chrome DevTools Protocol, supporting navigation, interaction, content extraction, and screenshots through a single MCP tool.
Updated a month ago (2026-08-07 19:41 UTC)
1
346
MIT
@nimbus21.ai/chrome-devtools
Browser Automation Developer Tools Testing & QA Tools
nimbus21
A
license
Not graded
quality
C
maintenance
Lets AI coding agents control and inspect a live Chrome browser via MCP, providing Chrome DevTools capabilities for automation, debugging, and performance analysis.
Updated 5 months ago (2026-04-05 11:19 UTC)
17
Apache 2.0
chrome-pilot-mcp
Browser Automation Web Scraping
HelloiOS2014
A
license
A
quality
D
maintenance
Connects to a running Chrome instance via CDP to expose browser control as MCP tools, preserving login state, cookies, and extensions for automation.
Updated 6 months ago (2026-03-12 11:02 UTC)
19
15
MIT
chrome-devtools-mcp
Browser Automation Developer Tools
amstaff666
A
license
Not graded
quality
B
maintenance
Lets coding agents control and inspect a live Chrome browser via MCP, providing Chrome DevTools capabilities for automation, debugging, and performance analysis.
Updated a month ago (2026-08-09 00:05 UTC)
3,288,165
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/danilin-em/chrome-remote-debugging-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server