What can chrome-devtools-mcp do?

live-browser-control-via-mcp-protocol, accessibility-snapshot-extraction-with-aria-semantics, javascript-execution-and-evaluation-in-page-context, mcp-tool-schema-definition-and-validation, daemon-mode-server-with-persistent-browser-session, token-optimized-response-formatting-for-llm-consumption, performance-trace-analysis-with-devtools-frontend-integration, network-request-inspection-and-response-capture, console-output-capture-and-error-logging, dom-element-interaction-with-selector-based-targeting, page-navigation-and-wait-strategies, browser-instance-lifecycle-management-with-connection-strategies, emulation-and-device-simulation, screenshot-and-visual-capture-with-format-options

chrome-devtools-mcp

MCP ServerFree

Chrome DevTools for coding agents

Open Source

/ 100

14 capabilities

Capabilities14 decomposed

live-browser-control-via-mcp-protocol

Medium confidence

Exposes Chrome browser automation through the Model Context Protocol (MCP) using a STDIO transport layer, enabling AI agents to send structured tool requests that are serialized into Puppeteer commands and executed against a live Chrome instance managed by a single-threaded Mutex-protected execution pipeline. The system translates natural language agent intents into browser operations (navigation, interaction, inspection) and returns token-optimized structured responses designed for LLM consumption.

Solves for

I want my AI agent to control a real Chrome browser and get live feedback on page stateI need to automate browser interactions (clicks, typing, navigation) through an LLM without writing custom Puppeteer codeI want to integrate Chrome DevTools capabilities into my AI coding assistant workflow

Best for

AI agent developers building autonomous browser automation workflows

Teams integrating Claude, Gemini, or Cursor with live browser testing

Developers creating LLM-powered web scraping or testing agents

Requires

Node.js 18+

Chrome browser installed locally or accessible via HTTP debug protocol (Chrome 144+)

MCP client implementation (Claude, Gemini, Cursor, VS Code Copilot, or custom)

Limitations

Single-threaded Mutex-based execution model means only one tool action processes at a time per server instance, creating sequential bottlenecks for parallel browser operations

STDIO transport limits throughput compared to WebSocket or gRPC alternatives; no built-in connection pooling across multiple browser instances

Requires Chrome 144+ for auto-connect mode; older Chrome versions require explicit --browserUrl configuration

What makes it unique

Implements MCP as a standardized protocol bridge between LLM agents and Chrome DevTools, using Puppeteer as the underlying automation engine with token-optimized response formatting specifically designed for LLM context windows. The Mutex-protected single-threaded execution model ensures deterministic browser state across sequential agent actions without race conditions.

vs alternatives

Provides standardized MCP protocol integration (vs proprietary APIs) with native support for multiple AI clients (Claude, Gemini, Cursor) and token-optimized output, whereas raw Puppeteer requires custom serialization and context management per LLM integration.

accessibility-snapshot-extraction-with-aria-semantics

Medium confidence

Captures a structured accessibility snapshot of the current page by traversing the DOM and extracting element properties (role, name, state, value, ARIA attributes) into a hierarchical JSON representation. This snapshot is optimized for LLM consumption by filtering out noise and preserving semantic relationships, enabling agents to understand page structure without visual rendering. The system uses Chrome DevTools Protocol (CDP) to query the accessibility tree directly rather than parsing raw HTML.

Solves for

I want my agent to understand the semantic structure of a page (buttons, forms, landmarks) without needing visual screenshotsI need to extract ARIA labels and roles to verify accessibility compliance or interact with complex widgetsI want to debug accessibility issues by inspecting the computed accessibility tree

Best for

Accessibility testing automation agents

LLM-powered web testing tools that need semantic page understanding

Developers building screen-reader simulation for automated testing

Requires

Chrome browser with DevTools Protocol support

Page must be fully loaded before snapshot (no automatic wait for dynamic content)

JavaScript execution must be enabled for CDP accessibility tree queries

Limitations

Snapshot is point-in-time and does not capture dynamic ARIA updates triggered by JavaScript after initial load

Complex shadow DOM structures may not be fully traversed depending on Chrome version and CDP protocol version

ARIA attributes are extracted as-is without validation against WCAG standards; malformed ARIA is passed through unchanged

What makes it unique

Uses Chrome DevTools Protocol accessibility tree queries (not DOM parsing) to extract semantic structure with ARIA attributes, producing LLM-optimized hierarchical JSON that preserves parent-child relationships and element roles without visual rendering overhead. Specifically designed for agents that need to interact with complex widgets (comboboxes, trees, tabs) by understanding their semantic roles.

vs alternatives

Extracts semantic structure via CDP accessibility tree (vs parsing raw HTML or screenshots), providing accurate ARIA semantics and role information that enables agents to interact with complex widgets, whereas visual screenshot analysis requires OCR and cannot reliably detect ARIA state changes.

javascript-execution-and-evaluation-in-page-context

Medium confidence

Executes arbitrary JavaScript code in the page context using Chrome DevTools Protocol Runtime domain. The system evaluates JavaScript expressions and returns the result as structured JSON (primitives, objects, arrays). Code execution is sandboxed within the page context, enabling access to page variables, DOM, and global objects. The system supports both synchronous evaluation and asynchronous function execution with promise handling. Return values are serialized for LLM consumption; functions and circular references are converted to string representations.

Solves for

I want to extract data from the page using JavaScript (e.g., scrape table data, extract JSON from page state)I need to call page functions or access page variables to verify application stateI want to execute custom logic in the page context to prepare data for extraction

Best for

Data extraction agents that need to run custom JavaScript

Agents testing application state by accessing page variables

Developers debugging page behavior by executing diagnostic code

Requires

Chrome browser with DevTools Protocol Runtime domain support

JavaScript execution must be enabled

Page must be loaded before code execution

Limitations

Code execution is sandboxed in page context; cannot access Node.js modules or external APIs directly

Return values must be JSON-serializable; functions, DOM nodes, and circular references are converted to strings, losing type information

Execution timeout is fixed (default 30s); long-running scripts may timeout without partial results

What makes it unique

Executes JavaScript in page context via Chrome DevTools Protocol Runtime domain with JSON serialization of return values, enabling agents to extract data and access page state without DOM parsing. The system handles promise resolution and provides detailed error messages for debugging.

vs alternatives

Executes code in page context via CDP (vs DOM parsing), enabling access to page variables and functions, whereas DOM parsing only extracts static HTML structure without access to application state.

mcp-tool-schema-definition-and-validation

Medium confidence

Defines and validates MCP tool schemas that expose Chrome DevTools capabilities to LLM agents. Each tool is defined with a JSON schema specifying input parameters (type, required, description) and output format. The system validates agent requests against these schemas before execution, ensuring type safety and preventing invalid arguments. Tool schemas are introspectable by MCP clients, enabling agents to discover available capabilities and their parameters. The system provides detailed error messages when schema validation fails, helping agents correct malformed requests.

Solves for

I want to define tools that my agent can call with validated parametersI need to ensure agents only call tools with correct argument types and required fieldsI want agents to discover available tools and their parameters automatically

Best for

MCP server developers integrating Chrome DevTools with LLM agents

Teams building agent frameworks that need tool schema validation

Developers ensuring type safety in agent-to-tool communication

Requires

MCP client implementation that supports tool schema introspection

JSON Schema v7 compatible validator (included in dependencies)

Limitations

Schema validation is JSON Schema v7 compatible; complex validation rules (conditional fields, cross-field validation) may require custom logic

Schema introspection is read-only; agents cannot modify tool schemas at runtime

Error messages are based on JSON Schema validation; may not be user-friendly for complex schema violations

What makes it unique

Implements MCP tool schema definition and validation using JSON Schema v7, enabling type-safe tool calling with automatic schema introspection. The system validates requests before execution, preventing invalid arguments and providing detailed error messages.

vs alternatives

Provides schema-based validation via MCP (vs untyped function calling), ensuring type safety and enabling agent discovery of tool parameters, whereas raw function calling requires manual validation and documentation.

daemon-mode-server-with-persistent-browser-session

Medium confidence

Runs the MCP server in daemon mode as a long-lived process with a persistent browser session, enabling multiple agent interactions across a single browser instance. The system manages server lifecycle (startup, shutdown, signal handling) and maintains browser connection state across tool invocations. Daemon mode is configured via CLI flags and supports systemd integration for automatic restart on failure. The system logs all activity to a file for debugging and monitoring.

Solves for

I want to run a persistent MCP server that maintains browser state across multiple agent interactionsI need to integrate Chrome DevTools MCP with my application as a background serviceI want to monitor server health and automatically restart on failure

Best for

Production deployments requiring persistent browser automation

Applications integrating Chrome DevTools as a background service

Teams running MCP servers on servers or containers with systemd

Requires

Node.js 18+

Chrome browser installed locally or accessible via HTTP debug protocol

systemd (optional, for automatic restart)

Limitations

Daemon mode requires manual process management (systemd, supervisor, etc.); no built-in clustering or load balancing

Single browser instance per daemon; high-concurrency scenarios require multiple daemon processes

Log files can grow large; no automatic log rotation or cleanup

What makes it unique

Implements daemon mode with persistent browser session and systemd integration, enabling long-lived MCP server deployments with automatic restart on failure. The system manages browser connection state across multiple agent interactions, reducing overhead of browser launch/shutdown.

vs alternatives

Provides daemon mode with persistent session (vs stateless server), reducing browser launch overhead and enabling stateful interactions, whereas stateless servers require browser restart per request.

token-optimized-response-formatting-for-llm-consumption

Medium confidence

Formats all tool responses as compact JSON optimized for LLM context windows, using abbreviated field names, removing unnecessary whitespace, and filtering out non-essential data. The system prioritizes information density and readability for LLMs over human readability. Response formatting is consistent across all tools, enabling agents to parse responses reliably. The system includes optional verbose mode for debugging, which expands response details at the cost of token usage.

Solves for

I want tool responses to be compact and token-efficient for my LLM agentI need consistent response format across all tools for reliable parsingI want to debug tool responses with detailed information when needed

Best for

Agents with limited context windows that need token-efficient responses

Teams optimizing LLM API costs by reducing token usage

Developers building reliable agent-to-tool communication

Requires

MCP client that can parse JSON responses

Limitations

Abbreviated field names may be less intuitive for human debugging; verbose mode required for detailed inspection

Token optimization may remove context that some agents need; no per-tool customization of response format

Filtering logic is hardcoded; cannot customize which fields are included/excluded

What makes it unique

Implements token-optimized response formatting with abbreviated field names and filtered data, specifically designed for LLM context windows. The system maintains consistent response structure across all tools, enabling reliable agent parsing.

vs alternatives

Optimizes responses for token efficiency via abbreviated fields and filtering (vs verbose responses), reducing LLM API costs and context usage, whereas standard responses include all details at higher token cost.

performance-trace-analysis-with-devtools-frontend-integration

Medium confidence

Collects Chrome DevTools performance traces (CPU profiling, memory snapshots, network waterfall, Core Web Vitals) using the Chrome DevTools Protocol and analyzes them using chrome-devtools-frontend components for deep insights. The system records traces during page load or user interactions, parses the trace JSON, and extracts metrics like LCP (Largest Contentful Paint), FID (First Input Delay), CLS (Cumulative Layout Shift), and memory heap snapshots. Results are formatted as structured JSON with actionable bottleneck identification.

Solves for

I want to measure Core Web Vitals (LCP, FID, CLS) for a page and identify performance bottlenecksI need to detect memory leaks by comparing heap snapshots before and after user interactionsI want to analyze CPU profiling data to find slow JavaScript execution or rendering bottlenecks

Best for

Performance testing automation agents

CI/CD pipelines that need automated performance regression detection

Developers debugging LCP and memory leak issues in production-like environments

Requires

Chrome browser with DevTools Protocol support

Page must complete load cycle for accurate metrics

chrome-devtools-frontend package installed (included in dependencies)

Limitations

Trace collection adds 500ms-2s overhead per measurement depending on page complexity; not suitable for real-time performance monitoring

Memory heap snapshots are point-in-time and require manual comparison logic to detect leaks; no built-in leak detection algorithm

Core Web Vitals are measured in lab environment (not field data); results may differ from real-world user experiences due to different hardware/network conditions

What makes it unique

Integrates chrome-devtools-frontend components for deep trace analysis (not just raw CDP metrics), enabling parsing of complex trace JSON and extraction of actionable insights like LCP bottleneck identification and memory leak detection. The system provides structured JSON output specifically formatted for LLM agents to reason about performance issues.

vs alternatives

Provides deep trace analysis using DevTools Frontend (vs raw CDP metrics), enabling detection of specific bottlenecks (e.g., 'LCP delayed by 800ms JavaScript execution in vendor.js'), whereas generic performance tools only report aggregate metrics without root cause analysis.

network-request-inspection-and-response-capture

Medium confidence

Intercepts and logs all network requests and responses during page load or user interactions using Chrome DevTools Protocol Network domain. The system captures request headers, response bodies (with automatic decompression for gzip/brotli), status codes, timing data, and resource types. Responses are stored in memory with configurable size limits and can be filtered by URL pattern, resource type, or status code. The captured data is formatted as structured JSON for LLM analysis of API calls, failed requests, and data flow.

Solves for

I want to inspect API calls made by a page and verify request/response payloadsI need to detect failed network requests (4xx, 5xx) and understand why they occurredI want to analyze network timing (DNS, TCP, TLS, request, response) to identify slow endpoints

Best for

API testing automation agents

Debugging agents that need to understand data flow between frontend and backend

Security testing tools that need to inspect request/response payloads for vulnerabilities

Requires

Chrome browser with DevTools Protocol Network domain support

Page must be navigated or interactions performed after network inspection is enabled

Sufficient memory for storing response bodies (configurable limit)

Limitations

Response bodies are stored in memory; large responses (>10MB) may cause memory pressure; no automatic cleanup of old requests

Binary response bodies (images, videos, PDFs) are captured but not decoded; only text-based responses are human-readable

Request/response interception does not support modifying requests in-flight; read-only inspection only

What makes it unique

Uses Chrome DevTools Protocol Network domain to intercept requests at the browser level (not proxy-based), capturing full request/response payloads with automatic decompression and timing breakdown. Provides structured JSON output with filtering capabilities, enabling agents to analyze specific API calls without manual log parsing.

vs alternatives

Captures network traffic at browser level via CDP (vs proxy interception), providing accurate timing data and automatic decompression, whereas proxy-based tools require additional setup and may miss browser-cached requests or WebSocket traffic.

console-output-capture-and-error-logging

Medium confidence

Captures all console output (log, warn, error, info) and JavaScript errors (uncaught exceptions, promise rejections) from the page using Chrome DevTools Protocol Runtime domain. The system logs messages with timestamps, severity levels, and stack traces. Errors are categorized by type (SyntaxError, TypeError, ReferenceError, etc.) and source location (file, line number). Output is formatted as structured JSON for LLM analysis of application behavior and debugging.

Solves for

I want to capture JavaScript errors and warnings to detect application issuesI need to see console.log output from the page to understand application flowI want to detect unhandled promise rejections and uncaught exceptions

Best for

Debugging agents that need to understand application errors

QA automation tools that verify error handling

Developers troubleshooting production issues in automated testing

Requires

Chrome browser with DevTools Protocol Runtime domain support

Page must be navigated after console capture is enabled

JavaScript execution must be enabled

Limitations

Console output is captured after page load; early initialization errors may be missed if capture is not enabled before navigation

Stack traces are limited by browser's error reporting; minified/obfuscated code produces unhelpful stack traces without source maps

Large console output (>10MB) may cause memory issues; no automatic log rotation or cleanup

What makes it unique

Captures console output and JavaScript errors via Chrome DevTools Protocol Runtime domain with automatic categorization by error type and source location. Provides structured JSON with stack traces and timestamps, enabling agents to correlate errors with user actions and page state.

vs alternatives

Captures errors at browser runtime level via CDP (vs parsing error logs), providing accurate stack traces and error categorization, whereas log file analysis requires manual parsing and may miss runtime errors not written to logs.

dom-element-interaction-with-selector-based-targeting

Medium confidence

Enables agents to interact with page elements (click, type, focus, blur, scroll) using CSS selectors or XPath expressions. The system resolves selectors to DOM elements using Chrome DevTools Protocol DOM domain, validates element visibility and interactability, and executes the requested action (click, keyboard input, mouse movement). Actions are queued and executed sequentially through the Mutex-protected pipeline to ensure deterministic state. The system returns success/failure status with error details if interaction fails (element not found, not clickable, etc.).

Solves for

I want to click a button or link identified by CSS selectorI need to type text into a form field and submit the formI want to scroll to an element and verify it's visible before interacting with it

Best for

Web automation agents performing user workflows (login, form submission, navigation)

Testing agents that need to simulate user interactions

Agents building web scraping workflows that require interaction before data extraction

Requires

Chrome browser with DevTools Protocol DOM domain support

Page must be loaded and DOM must be stable before interaction

Element must exist in DOM and be interactable (not disabled, not hidden)

Limitations

Selector must be valid CSS or XPath; invalid selectors fail silently or throw errors without helpful debugging

Element visibility check is based on computed styles; elements hidden by CSS (display: none, visibility: hidden) are detected, but elements obscured by other elements may not be

Keyboard input does not trigger all JavaScript events (e.g., custom input handlers may not fire); only standard DOM events are guaranteed

What makes it unique

Uses Chrome DevTools Protocol DOM domain to resolve selectors and validate element interactability before executing actions, with Mutex-protected sequential execution ensuring deterministic state across multiple interactions. Provides detailed error messages (element not found, not clickable, etc.) enabling agents to handle failures gracefully.

vs alternatives

Validates element interactability via CDP before action execution (vs blind action attempts), reducing flaky interactions and providing detailed error feedback, whereas raw Puppeteer may execute actions on non-interactable elements causing silent failures.

page-navigation-and-wait-strategies

Medium confidence

Navigates to URLs and implements configurable wait strategies (wait for navigation, wait for element, wait for network idle, wait for function) using Chrome DevTools Protocol Page domain. The system supports multiple wait conditions: networkidle0 (no network activity), networkidle2 (at most 2 network connections), domcontentloaded (DOM parsing complete), load (all resources loaded), or custom JavaScript function evaluation. Navigation timeout is configurable (default 30s). The system returns page metadata (title, URL, status code) and waits for the specified condition before returning control to the agent.

Solves for

I want to navigate to a URL and wait for the page to fully load before proceedingI need to wait for a specific element to appear on the page after navigationI want to navigate and wait for network activity to settle before extracting data

Best for

Web automation agents that need reliable page load detection

Data extraction agents that must wait for dynamic content to load

Testing agents that need to handle slow or unreliable network conditions

Requires

Chrome browser with DevTools Protocol Page domain support

Valid URL (http/https)

Network connectivity to target URL

Limitations

networkidle0 wait strategy may timeout on pages with persistent background requests (analytics, polling); networkidle2 is more practical but less strict

Custom JavaScript function evaluation requires the function to be defined in the page context; external functions cannot be passed

Wait timeout is global; no per-condition timeout customization

What makes it unique

Implements multiple wait strategies (networkidle, domcontentloaded, load, element, custom function) via Chrome DevTools Protocol, enabling agents to handle different page load patterns (SPA, server-rendered, dynamic content). The system provides detailed wait timing and status, allowing agents to reason about page readiness.

vs alternatives

Offers multiple wait strategies via CDP (vs single wait-for-load), enabling agents to handle SPAs and dynamic content reliably, whereas basic navigation only waits for load event which may complete before dynamic content renders.

browser-instance-lifecycle-management-with-connection-strategies

Medium confidence

Manages browser instance lifecycle (launch, connect, disconnect, close) with support for multiple connection strategies: launch new instance, auto-connect to existing instance via user data directory, or connect via HTTP debug protocol URL. The system uses Puppeteer for browser automation and supports configuration flags (--headless, --isolated, --userDataDir) to customize launch behavior. Connection state is managed through a singleton pattern with automatic reconnection on failure. The system ensures proper cleanup on shutdown to prevent zombie processes.

Solves for

I want to launch a fresh Chrome instance for isolated testingI need to connect to an existing Chrome instance without launching a new oneI want to reuse the same browser instance across multiple agent interactions

Best for

Agents that need long-lived browser sessions across multiple interactions

Testing environments that require isolated browser instances per test

Developers integrating with existing Chrome instances (e.g., user's running browser)

Requires

Chrome browser installed locally (for launch strategy) or accessible via HTTP debug protocol (for connect strategy)

Node.js 18+

Puppeteer package (included in dependencies)

Limitations

Launch strategy requires Chrome binary to be installed locally; no support for remote Chrome instances via SSH

Auto-connect strategy only works with Chrome 144+; older versions require explicit --browserUrl

Singleton pattern means only one browser instance per server process; multiple instances require multiple server processes

What makes it unique

Implements multiple connection strategies (launch new, auto-connect via user data directory, HTTP debug protocol) with singleton pattern for browser instance management. The system abstracts connection complexity, enabling agents to work with browser instances without managing Puppeteer directly.

vs alternatives

Supports multiple connection strategies via configuration flags (vs single launch approach), enabling reuse of existing browser instances and integration with user's running Chrome, whereas raw Puppeteer requires manual connection management per strategy.

emulation-and-device-simulation

Medium confidence

Simulates different device types, screen sizes, user agents, and network conditions using Chrome DevTools Protocol Emulation domain. The system supports predefined device profiles (iPhone, iPad, Android, desktop) or custom viewport dimensions, user agent strings, and device pixel ratios. Network throttling can be configured (4G, 3G, slow, offline) to simulate different connection speeds. Geolocation and timezone can be spoofed. The system applies emulation settings before page navigation, ensuring consistent behavior across test runs.

Solves for

I want to test how a page renders on mobile devices without owning physical devicesI need to simulate slow network conditions (3G, 4G) to test performance on mobileI want to test geolocation-dependent features by spoofing location

Best for

Responsive design testing agents

Mobile performance testing automation

Agents testing geolocation or timezone-dependent features

Requires

Chrome browser with DevTools Protocol Emulation domain support

Emulation settings must be applied before page navigation

Limitations

Device emulation simulates viewport and user agent but not actual hardware constraints (e.g., touch latency, GPU limitations); behavior may differ from real devices

Network throttling is applied at CDP level; actual network requests may not be throttled if using system proxy or VPN

Geolocation spoofing requires page permission; pages that check geolocation without user interaction may not work

What makes it unique

Uses Chrome DevTools Protocol Emulation domain to apply device profiles, network throttling, and geolocation spoofing at the browser level, enabling consistent simulation across test runs. Supports both predefined device profiles and custom configurations, providing flexibility for different testing scenarios.

vs alternatives

Applies emulation via CDP (vs visual viewport resizing), providing accurate device simulation including user agent and network throttling, whereas simple viewport resizing does not simulate network conditions or device-specific behavior.

screenshot-and-visual-capture-with-format-options

Medium confidence

Captures screenshots of the current page or specific elements using Chrome DevTools Protocol Page domain. The system supports full-page screenshots (including off-screen content), viewport-only screenshots, and element-specific screenshots. Output formats include PNG (default) and JPEG with configurable quality. Screenshots are base64-encoded for embedding in JSON responses. The system can capture screenshots at different device scales (1x, 2x, 3x) for testing responsive design. Captured images are optimized for LLM vision models by default.

Solves for

I want to capture a screenshot of the current page state for visual verificationI need to capture a full-page screenshot including off-screen contentI want to capture a specific element's screenshot for comparison or analysis

Best for

Visual regression testing agents

Agents that need to verify page rendering before proceeding

Developers debugging visual layout issues

Requires

Chrome browser with DevTools Protocol Page domain support

Page must be rendered (not just loaded); layout must be stable

Limitations

Full-page screenshots can be very large (>10MB for complex pages); base64 encoding adds 33% overhead, increasing response size

Screenshots are static; dynamic content (animations, hover states) are not captured

Element-specific screenshots may not capture pseudo-elements or overlays positioned outside element bounds

What makes it unique

Captures screenshots via Chrome DevTools Protocol with support for full-page, viewport, and element-specific modes, with base64 encoding for JSON embedding. The system optimizes output for LLM vision models by default, enabling agents to analyze visual state without external image storage.

vs alternatives

Provides multiple screenshot modes via CDP (vs single viewport screenshot), enabling full-page capture and element-specific screenshots, whereas basic screenshot tools only capture visible viewport.

Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.

Related Artifactssharing capabilities

Artifacts that share capabilities with chrome-devtools-mcp, ranked by overlap. Discovered automatically through the match graph.

MCP Server42

@executeautomation/playwright-mcp-server

Model Context Protocol servers for Playwright

javascript-code-execution-in-page-contextbrowser-session-and-context-management

2 shared capabilities

MCP Server46

chrome-devtools-mcp

MCP server for Chrome DevTools

javascript-execution-in-page-contextremote-browser-automation-via-devtools-protocol

2 shared capabilities

MCP Server40

@executeautomation/playwright-mcp-server

Model Context Protocol servers for Playwright

page-content-extraction-and-analysispage-navigation-and-context-management

2 shared capabilities

MCP Server24

Website Snapshot

** - A MCP server that provides comprehensive website snapshot capabilities using Playwright. This server enables LLMs to capture and analyze web pages through structured accessibility snapshots, network monitoring, and console message collection.

javascript execution and interaction simulationplaywright-based website snapshot capture with accessibility tree extraction

2 shared capabilities

MCP Server21

Puppeteer

** - Browser automation and web scraping.

page-content-extraction-and-analysisbrowser-context-and-session-management

2 shared capabilities

MCP Server47

Playwright MCP Server

Automate browsers and run web tests via Playwright MCP.

javascript execution and dom manipulationaccessibility-tree-based page state capture

2 shared capabilities

Best For

✓AI agent developers building autonomous browser automation workflows
✓Teams integrating Claude, Gemini, or Cursor with live browser testing
✓Developers creating LLM-powered web scraping or testing agents
✓Accessibility testing automation agents
✓LLM-powered web testing tools that need semantic page understanding
✓Developers building screen-reader simulation for automated testing
✓Data extraction agents that need to run custom JavaScript
✓Agents testing application state by accessing page variables

Known Limitations

⚠Single-threaded Mutex-based execution model means only one tool action processes at a time per server instance, creating sequential bottlenecks for parallel browser operations
⚠STDIO transport limits throughput compared to WebSocket or gRPC alternatives; no built-in connection pooling across multiple browser instances
⚠Requires Chrome 144+ for auto-connect mode; older Chrome versions require explicit --browserUrl configuration
⚠Snapshot is point-in-time and does not capture dynamic ARIA updates triggered by JavaScript after initial load
⚠Complex shadow DOM structures may not be fully traversed depending on Chrome version and CDP protocol version
⚠ARIA attributes are extracted as-is without validation against WCAG standards; malformed ARIA is passed through unchanged

Requirements

Node.js 18+Chrome browser installed locally or accessible via HTTP debug protocol (Chrome 144+)MCP client implementation (Claude, Gemini, Cursor, VS Code Copilot, or custom)TypeScript/JavaScript runtime for server executionChrome browser with DevTools Protocol supportPage must be fully loaded before snapshot (no automatic wait for dynamic content)JavaScript execution must be enabled for CDP accessibility tree queriesChrome browser with DevTools Protocol Runtime domain support

Input / Output

Accepts: MCP tool request JSON with structured parameters, Natural language instructions from LLM agents (converted to tool calls by client), Browser URLs, selectors, input text, keyboard/mouse events, Page URL or loaded page context, Optional CSS selectors to filter snapshot scope, JavaScript code string (expression or function), Optional function arguments (serialized as JSON), Optional timeout in milliseconds, Tool definition (name, description, input schema, output schema), Agent request with parameters, CLI flags for daemon configuration (--daemon, --logFile, etc.), Tool execution result, Optional verbose flag, Page URL, Optional trace duration (milliseconds), Optional interaction sequence (clicks, typing) to profile during user actions, Optional URL pattern filter (regex or string match), Optional resource type filter (xhr, fetch, document, stylesheet, image, etc.), Optional status code filter (e.g., only 4xx/5xx errors), Optional severity filter (error, warn, info, log), Optional message pattern filter (regex), CSS selector or XPath expression, Action type (click, type, focus, blur, scroll, hover), Optional action parameters (text to type, scroll distance, key to press), URL to navigate to, Wait strategy (networkidle0, networkidle2, domcontentloaded, load, element, function), Optional wait condition parameter (CSS selector for element, JavaScript function for custom condition), Connection strategy flag (--autoConnect, --browserUrl, or default launch), Optional launch flags (--headless, --isolated, --userDataDir), Optional browser URL for HTTP debug protocol connection, Device profile name (iPhone, iPad, Android, desktop) or custom viewport dimensions, Optional user agent string, Optional network throttling profile (4G, 3G, slow, offline) or custom bandwidth/latency, Optional geolocation (latitude, longitude, accuracy), Optional timezone string, Screenshot type (fullPage, viewport, element), Optional CSS selector for element screenshots, Optional format (png, jpeg), Optional quality (0-100 for JPEG), Optional device scale (1x, 2x, 3x)

Produces: Structured JSON responses with page state, element properties, performance metrics, Accessibility snapshots (DOM tree with ARIA attributes), Screenshot data (base64-encoded PNG), Network request/response logs, Console output and error messages, Hierarchical JSON with element nodes containing: role, name, state, value, ARIA attributes, parent/child relationships, Flattened text representation of page structure for LLM parsing, Execution result (JSON-serialized return value), Error message if execution failed or timed out, Execution time in milliseconds, Tool schema JSON (for introspection), Validation result (valid/invalid with error details), Tool execution result, Server startup confirmation, Log file path, Process ID (PID), Compact JSON response (default), Detailed JSON response (verbose mode), Structured JSON with Core Web Vitals metrics (LCP, FID, CLS values in milliseconds), CPU profile data with function call stacks and execution time, Memory heap snapshot with object counts and retained size, Network waterfall with request/response timings and resource sizes, Bottleneck summary with actionable recommendations, Structured JSON array of network requests with: URL, method, status code, headers, response body (text), timing breakdown, Filtered request logs based on specified criteria, Summary statistics (total requests, failed requests, average response time), Structured JSON array of console messages with: timestamp, severity, message text, source file, line number, stack trace, Categorized error summary (count by error type), Filtered logs based on severity or pattern, Success/failure status, Error message if interaction failed (element not found, not clickable, etc.), Updated page state after interaction (optional screenshot or accessibility snapshot), Page metadata (title, URL, status code), Error message if navigation failed or wait timeout exceeded, Actual wait time in milliseconds, Browser instance handle (internal to system), Connection status (connected, disconnected, error), Error message if connection fails, Confirmation of emulation settings applied, Error message if emulation failed, Base64-encoded image data (PNG or JPEG), Image dimensions (width, height), File size in bytes

UnfragileRank

Adoption41%(30% weight)

Quality45%(25% weight)

Ecosystem60%(25% weight)

Match Graph10%(15% weight)

Freshness75%(5% weight)

UnfragileRank is computed from adoption signals, documentation quality, ecosystem connectivity, match graph feedback, and freshness. No artifact can pay for a higher rank.

Type: MCP Server

14 capabilities

Visit chrome-devtools-mcp→

Repository Details

36,646

Stars

2,263

Forks

TypeScript

Language

Apache-2.0

License

Topics

browserchromechrome-devtoolsdebuggingdevtoolsmcpmcp-serverpuppeteer

Last commit: Apr 21, 2026

About

Chrome DevTools for coding agents

Alternatives to chrome-devtools-mcp

wink-embeddings-sg-100d24Repository

100-dimensional English word embeddings for wink-nlp

Compare →

voyage-ai-provider30API

Voyage AI Provider for running Voyage AI models with Vercel AI SDK

Compare →

@vibe-agent-toolkit/rag-lancedb27Agent

LanceDB implementation of RAG interfaces for vibe-agent-toolkit

Compare →

vectra41Repository

A lightweight, file-backed vector database for Node.js and browsers with Pinecone-compatible filtering and hybrid BM25 search.

Compare →

Are you the builder of chrome-devtools-mcp?

Claim this artifact to get a verified badge, access match analytics, see which intents users search for, and manage your listing.

Claim this artifact →Verification via email

Get the weekly brief

New tools, rising stars, and what's actually worth your time. No spam.

Data Sources

github awesomemcp registry

Looking for something else?

Search →

Capabilities14 decomposed

live-browser-control-via-mcp-protocol

Medium confidence

Solves for

Best for

AI agent developers building autonomous browser automation workflows

Teams integrating Claude, Gemini, or Cursor with live browser testing

Developers creating LLM-powered web scraping or testing agents

Requires

Node.js 18+

Chrome browser installed locally or accessible via HTTP debug protocol (Chrome 144+)

MCP client implementation (Claude, Gemini, Cursor, VS Code Copilot, or custom)

Limitations

Single-threaded Mutex-based execution model means only one tool action processes at a time per server instance, creating sequential bottlenecks for parallel browser operations

STDIO transport limits throughput compared to WebSocket or gRPC alternatives; no built-in connection pooling across multiple browser instances

Requires Chrome 144+ for auto-connect mode; older Chrome versions require explicit --browserUrl configuration

What makes it unique

vs alternatives

accessibility-snapshot-extraction-with-aria-semantics

Medium confidence

Solves for

Best for

Accessibility testing automation agents

LLM-powered web testing tools that need semantic page understanding

Developers building screen-reader simulation for automated testing

Requires

Chrome browser with DevTools Protocol support

Page must be fully loaded before snapshot (no automatic wait for dynamic content)

JavaScript execution must be enabled for CDP accessibility tree queries

Limitations

Snapshot is point-in-time and does not capture dynamic ARIA updates triggered by JavaScript after initial load

Complex shadow DOM structures may not be fully traversed depending on Chrome version and CDP protocol version

ARIA attributes are extracted as-is without validation against WCAG standards; malformed ARIA is passed through unchanged

What makes it unique

vs alternatives

javascript-execution-and-evaluation-in-page-context

Medium confidence

Solves for

Best for

Data extraction agents that need to run custom JavaScript

Agents testing application state by accessing page variables

Developers debugging page behavior by executing diagnostic code

Requires

Chrome browser with DevTools Protocol Runtime domain support

JavaScript execution must be enabled

Page must be loaded before code execution

Limitations

Code execution is sandboxed in page context; cannot access Node.js modules or external APIs directly

Return values must be JSON-serializable; functions, DOM nodes, and circular references are converted to strings, losing type information

Execution timeout is fixed (default 30s); long-running scripts may timeout without partial results

What makes it unique

vs alternatives

Executes code in page context via CDP (vs DOM parsing), enabling access to page variables and functions, whereas DOM parsing only extracts static HTML structure without access to application state.

mcp-tool-schema-definition-and-validation

Medium confidence

Solves for

Best for

MCP server developers integrating Chrome DevTools with LLM agents

Teams building agent frameworks that need tool schema validation

Developers ensuring type safety in agent-to-tool communication

Requires

MCP client implementation that supports tool schema introspection

JSON Schema v7 compatible validator (included in dependencies)

Limitations

Schema validation is JSON Schema v7 compatible; complex validation rules (conditional fields, cross-field validation) may require custom logic

Schema introspection is read-only; agents cannot modify tool schemas at runtime

Error messages are based on JSON Schema validation; may not be user-friendly for complex schema violations

What makes it unique

vs alternatives

daemon-mode-server-with-persistent-browser-session

Medium confidence

Solves for

Best for

Production deployments requiring persistent browser automation

Applications integrating Chrome DevTools as a background service

Teams running MCP servers on servers or containers with systemd

Requires

Node.js 18+

Chrome browser installed locally or accessible via HTTP debug protocol

systemd (optional, for automatic restart)

Limitations

Daemon mode requires manual process management (systemd, supervisor, etc.); no built-in clustering or load balancing

Single browser instance per daemon; high-concurrency scenarios require multiple daemon processes

Log files can grow large; no automatic log rotation or cleanup

What makes it unique

vs alternatives

Provides daemon mode with persistent session (vs stateless server), reducing browser launch overhead and enabling stateful interactions, whereas stateless servers require browser restart per request.

token-optimized-response-formatting-for-llm-consumption

Medium confidence

Solves for

Best for

Agents with limited context windows that need token-efficient responses

Teams optimizing LLM API costs by reducing token usage

Developers building reliable agent-to-tool communication

Requires

MCP client that can parse JSON responses

Limitations

Abbreviated field names may be less intuitive for human debugging; verbose mode required for detailed inspection

Token optimization may remove context that some agents need; no per-tool customization of response format

Filtering logic is hardcoded; cannot customize which fields are included/excluded

What makes it unique

vs alternatives

performance-trace-analysis-with-devtools-frontend-integration

Medium confidence

Solves for

Best for

Performance testing automation agents

CI/CD pipelines that need automated performance regression detection

Developers debugging LCP and memory leak issues in production-like environments

Requires

Chrome browser with DevTools Protocol support

Page must complete load cycle for accurate metrics

chrome-devtools-frontend package installed (included in dependencies)

Limitations

Trace collection adds 500ms-2s overhead per measurement depending on page complexity; not suitable for real-time performance monitoring

Memory heap snapshots are point-in-time and require manual comparison logic to detect leaks; no built-in leak detection algorithm

Core Web Vitals are measured in lab environment (not field data); results may differ from real-world user experiences due to different hardware/network conditions

What makes it unique

vs alternatives

network-request-inspection-and-response-capture

Medium confidence

Solves for

Best for

API testing automation agents

Debugging agents that need to understand data flow between frontend and backend

Security testing tools that need to inspect request/response payloads for vulnerabilities

Requires

Chrome browser with DevTools Protocol Network domain support

Page must be navigated or interactions performed after network inspection is enabled

Sufficient memory for storing response bodies (configurable limit)

Limitations

Response bodies are stored in memory; large responses (>10MB) may cause memory pressure; no automatic cleanup of old requests

Binary response bodies (images, videos, PDFs) are captured but not decoded; only text-based responses are human-readable

Request/response interception does not support modifying requests in-flight; read-only inspection only

What makes it unique

vs alternatives

console-output-capture-and-error-logging

Medium confidence

Solves for

Best for

Debugging agents that need to understand application errors

QA automation tools that verify error handling

Developers troubleshooting production issues in automated testing

Requires

Chrome browser with DevTools Protocol Runtime domain support

Page must be navigated after console capture is enabled

JavaScript execution must be enabled

Limitations

Console output is captured after page load; early initialization errors may be missed if capture is not enabled before navigation

Stack traces are limited by browser's error reporting; minified/obfuscated code produces unhelpful stack traces without source maps

Large console output (>10MB) may cause memory issues; no automatic log rotation or cleanup

What makes it unique

vs alternatives

dom-element-interaction-with-selector-based-targeting

Medium confidence

Solves for

I want to click a button or link identified by CSS selectorI need to type text into a form field and submit the formI want to scroll to an element and verify it's visible before interacting with it

Best for

Web automation agents performing user workflows (login, form submission, navigation)

Testing agents that need to simulate user interactions

Agents building web scraping workflows that require interaction before data extraction

Requires

Chrome browser with DevTools Protocol DOM domain support

Page must be loaded and DOM must be stable before interaction

Element must exist in DOM and be interactable (not disabled, not hidden)

Limitations

Selector must be valid CSS or XPath; invalid selectors fail silently or throw errors without helpful debugging

Element visibility check is based on computed styles; elements hidden by CSS (display: none, visibility: hidden) are detected, but elements obscured by other elements may not be

Keyboard input does not trigger all JavaScript events (e.g., custom input handlers may not fire); only standard DOM events are guaranteed

What makes it unique

vs alternatives

page-navigation-and-wait-strategies

Medium confidence

Solves for

Best for

Web automation agents that need reliable page load detection

Data extraction agents that must wait for dynamic content to load

Testing agents that need to handle slow or unreliable network conditions

Requires

Chrome browser with DevTools Protocol Page domain support

Valid URL (http/https)

Network connectivity to target URL

Limitations

networkidle0 wait strategy may timeout on pages with persistent background requests (analytics, polling); networkidle2 is more practical but less strict

Custom JavaScript function evaluation requires the function to be defined in the page context; external functions cannot be passed

Wait timeout is global; no per-condition timeout customization

What makes it unique

vs alternatives

browser-instance-lifecycle-management-with-connection-strategies

Medium confidence

Solves for

Best for

Agents that need long-lived browser sessions across multiple interactions

Testing environments that require isolated browser instances per test

Developers integrating with existing Chrome instances (e.g., user's running browser)

Requires

Chrome browser installed locally (for launch strategy) or accessible via HTTP debug protocol (for connect strategy)

Node.js 18+

Puppeteer package (included in dependencies)

Limitations

Launch strategy requires Chrome binary to be installed locally; no support for remote Chrome instances via SSH

Auto-connect strategy only works with Chrome 144+; older versions require explicit --browserUrl

Singleton pattern means only one browser instance per server process; multiple instances require multiple server processes

What makes it unique

vs alternatives

emulation-and-device-simulation

Medium confidence

Solves for

Best for

Responsive design testing agents

Mobile performance testing automation

Agents testing geolocation or timezone-dependent features

Requires

Chrome browser with DevTools Protocol Emulation domain support

Emulation settings must be applied before page navigation

Limitations

Device emulation simulates viewport and user agent but not actual hardware constraints (e.g., touch latency, GPU limitations); behavior may differ from real devices

Network throttling is applied at CDP level; actual network requests may not be throttled if using system proxy or VPN

Geolocation spoofing requires page permission; pages that check geolocation without user interaction may not work

What makes it unique

vs alternatives

screenshot-and-visual-capture-with-format-options

Medium confidence

Solves for

Best for

Visual regression testing agents

Agents that need to verify page rendering before proceeding

Developers debugging visual layout issues

Requires

Chrome browser with DevTools Protocol Page domain support

Page must be rendered (not just loaded); layout must be stable

Limitations

Full-page screenshots can be very large (>10MB for complex pages); base64 encoding adds 33% overhead, increasing response size

Screenshots are static; dynamic content (animations, hover states) are not captured

Element-specific screenshots may not capture pseudo-elements or overlays positioned outside element bounds

What makes it unique

vs alternatives

Provides multiple screenshot modes via CDP (vs single viewport screenshot), enabling full-page capture and element-specific screenshots, whereas basic screenshot tools only capture visible viewport.

Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.

Alternatives to chrome-devtools-mcp

wink-embeddings-sg-100d24Repository

100-dimensional English word embeddings for wink-nlp

Compare →

voyage-ai-provider30API

Voyage AI Provider for running Voyage AI models with Vercel AI SDK

Compare →

@vibe-agent-toolkit/rag-lancedb27Agent

LanceDB implementation of RAG interfaces for vibe-agent-toolkit

Compare →

vectra41Repository

A lightweight, file-backed vector database for Node.js and browsers with Pinecone-compatible filtering and hybrid BM25 search.

Compare →

chrome-devtools-mcp

Capabilities14 decomposed

live-browser-control-via-mcp-protocol

accessibility-snapshot-extraction-with-aria-semantics

javascript-execution-and-evaluation-in-page-context

mcp-tool-schema-definition-and-validation

daemon-mode-server-with-persistent-browser-session

token-optimized-response-formatting-for-llm-consumption

performance-trace-analysis-with-devtools-frontend-integration

network-request-inspection-and-response-capture

console-output-capture-and-error-logging

dom-element-interaction-with-selector-based-targeting

page-navigation-and-wait-strategies

browser-instance-lifecycle-management-with-connection-strategies

emulation-and-device-simulation

screenshot-and-visual-capture-with-format-options

Related Artifactssharing capabilities

@executeautomation/playwright-mcp-server

chrome-devtools-mcp

@executeautomation/playwright-mcp-server

Website Snapshot

Puppeteer

Playwright MCP Server

Best For

Known Limitations

Requirements

Input / Output

UnfragileRank

Repository Details

About

Categories

Alternatives to chrome-devtools-mcp

Are you the builder of chrome-devtools-mcp?

Get the weekly brief

Data Sources

chrome-devtools-mcp

Capabilities14 decomposed

live-browser-control-via-mcp-protocol

accessibility-snapshot-extraction-with-aria-semantics

javascript-execution-and-evaluation-in-page-context

mcp-tool-schema-definition-and-validation

daemon-mode-server-with-persistent-browser-session

token-optimized-response-formatting-for-llm-consumption

performance-trace-analysis-with-devtools-frontend-integration

network-request-inspection-and-response-capture

console-output-capture-and-error-logging

dom-element-interaction-with-selector-based-targeting

page-navigation-and-wait-strategies

browser-instance-lifecycle-management-with-connection-strategies

emulation-and-device-simulation

screenshot-and-visual-capture-with-format-options

Related Artifactssharing capabilities

@executeautomation/playwright-mcp-server

chrome-devtools-mcp

@executeautomation/playwright-mcp-server

Website Snapshot

Puppeteer

Playwright MCP Server

Best For

Known Limitations

Requirements

Input / Output

UnfragileRank

Repository Details

About

Categories

Alternatives to chrome-devtools-mcp

Are you the builder of chrome-devtools-mcp?

Get the weekly brief

Data Sources