chrome-dev-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tabsA | List all open Chrome page tabs with their targetIds, titles, and URLs. When you are unsure which tab to inspect, call this proactively to discover available tabs, then present the list to the user and ask which one to switch to — do NOT tell the user to switch tabs manually in Chrome. |
| switch_tabA | Switch the MCP connection to a specific Chrome tab. Use list_tabs first to get available targetIds. |
| get_titleA | Get the title of the currently connected tab ( |
| get_urlA | Get the URL of the currently connected tab ( |
| get_htmlA | Get the full HTML source of the currently connected tab ( |
| evaluate_jsA | Evaluate a JavaScript expression in the page, in global scope, with the same semantics as the DevTools console. Returns the real value when it serialises; objects that cannot (DOM nodes, Errors, Maps, class instances) come back as a preview instead: class name plus a first level of properties, marked |
| get_computed_styleA | Get computed CSS values for the given properties on the element matched by selector. |
| screenshotA | Capture a PNG screenshot of the current viewport (the visible page area only — not the full scrollable page, not the browser chrome, not DevTools), or of one rectangle of it with |
| get_inspected_elementA | Get the element marked for MCP inspection. To mark an element: select it in the Elements panel, then run |
| get_debugger_stateA | Get current debugger state: whether execution is paused, the pause reason, hit breakpoints, and the full call stack with file/line info. |
| get_scope_variablesA | Inspect variable values in a call frame scope. Only works when execution is paused. Use get_debugger_state first to find available frame indices. |
| set_breakpointA | Set a breakpoint by URL (exact or regex) + line number. |
| remove_breakpointA | Remove a breakpoint by ID. The ID is invalidated; use set_breakpoint to restore (returns a new ID). |
| list_breakpointsA | List breakpoints tracked by this server (set via |
| pause_executionA | Pause JavaScript execution immediately. After pausing, use get_debugger_state to inspect the call stack. |
| resume_executionA | Resume JavaScript execution after a breakpoint or pause. |
| step_overA | Execute the current line and pause at the next line (does not enter function calls). Returns the new call stack position. |
| step_intoA | Step into the function call on the current line. Returns the new call stack position. |
| evaluate_at_frameA | Evaluate a JavaScript expression in the scope of a paused call frame — it reads local variables, closure variables and the current |
| step_outA | Step out of the current function and pause at the caller. Returns the new call stack position. |
| get_console_logsA | Return browser console messages and uncaught exceptions. Includes messages already visible in DevTools before this server connected, plus new output produced afterwards. Exceptions are reported with their full stack trace (source-mapped when available). |
| get_network_requestsA | Return HTTP requests captured from the connected tab — method, URL, resource type, status, transferred size, duration, initiator, and failure reason. Capture starts when this server connects to the tab: requests issued before that are NOT visible (unlike get_console_logs, which replays pre-connect history). Requests belonging to a previous page are pruned on navigation, mirroring the DevTools Network panel default; the new document request itself is kept. A redirect chain appears as one record per hop, sharing a requestId and distinguished by |
| get_network_response_bodyA | Fetch the response body for one requestId from get_network_requests. Bodies are never buffered by this server — they are read from Chrome on demand, and Chrome discards them on navigation or when its own buffer limits are exceeded, so fetch promptly and before navigating away. Chrome stores at most one body per requestId, so for a redirect chain only the final hop has a body. Returns a JSON metadata block, then the body as a separate text block — kept separate so a large body is not JSON-escaped. Metadata carries requestId, |
| clear_capturesA | Discard the buffers this server holds, so a following get_console_logs / get_network_requests shows only what happens next. Affects this server only: nothing is cleared in Chrome or in the DevTools UI, and capture keeps running — no reconnect or reload is needed. Cannot be undone. Console entries are gone for good, because Console.enable() replays history only at attach time. Cleared network requestIds still resolve in get_network_response_body for as long as Chrome itself holds the body; once Chrome drops it the error says the data was discarded rather than that the id is unknown. Works without a connected tab. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 24 tools
Each tool has a clearly distinct purpose: page inspection, execution evaluation, debugging control, breakpoint management, tab switching, console/network capture. Even the closest pair (get_scope_variables vs evaluate_at_frame) is well separated by description: one lists variables in scope, the other evaluates arbitrary expressions in that scope.
All tool names follow a consistent snake_case verb_noun pattern: get_*, list_*, set_*, remove_*, pause_*, resume_*, step_*, evaluate_*, screenshot, clear_*. The verbs are specific and predictable, making the set easy to navigate.
At 24 tools, the server is on the heavier side, but the breadth is justified by the Chrome DevTools domain: debugging, DOM access, console, network, and tab management. Each tool addresses a distinct need, so the count feels slightly over a typical 3–15 scope but reasonable for a full-featured DevTools integration.
The surface covers the core workflows: page inspection, script evaluation, breakpoint debugging, stepping, console and network capture. Minor gaps exist—no conditional breakpoints, no full-page screenshots, no network interception—but these are workarounded via evaluate_js or are explicitly documented limitations.