chrome-devtools-pattern-detector

Automatically detect errors, performance regressions, and memory leaks in your browser—and get actionable suggestions, not just raw DevTools data.

Built on top of Chrome DevTools MCP, this MCP server adds a pattern detection layer that turns browser telemetry into real diagnoses.

Why this matters

Debugging today is reactive:

• You scan logs manually
• You guess which issues matter
• You lose context when the tab closes

This shifts debugging to proactive:

• Problems are detected automatically
• Patterns are grouped and quantified
• You get a suggested next step immediately

The goal is simple: stop hunting for issues—start being told about them.

Mental model

DevTools → Raw signals
↓
Pattern Detector → Finds issues
↓
Report → Explains + suggests fixes

Example

Ask your AI assistant:

Detect console error patterns on this page

Get back:

⚠️  Repeated Console Error
Message: TypeError: Cannot read properties of null (reading 'id')
Count: 5 occurrences

💡 Suggestion: Consider adding a null check before accessing .id

What this is

An MCP server that sits on top of Chrome DevTools and adds:

• Pattern detection across runtime behavior
• Automated grouping of repeated issues
• Performance regression tracking (LCP, FCP, CLS)
• Memory leak detection via heap growth
• Actionable suggestions for every detected pattern

Designed for AI-assisted debugging workflows (VS Code, Cursor, Claude Desktop via MCP).

What problems this solves

Without this: You open DevTools, scan logs manually, guess whether that error is new or recurring, and lose context when you close the tab.

With this:

• Catches flaky endpoints automatically — repeated 4xx/5xx failures are grouped, counted, and flagged with status-specific suggestions (401 → auth issue, 404 → path mismatch, 500 → server error)
• Surfaces performance regressions without manual comparison — LCP, FCP, and CLS are measured against a stored baseline so regressions are explicit, not eyeballed
• Identifies memory leaks before they become crashes — heap growth is tracked across snapshots and flagged when it exceeds configurable thresholds
• Reduces cognitive load — instead of reading raw telemetry, you get a diagnosis and a next step

The goal is to shift from noticing problems to being told about them.

7 detection tools

| Tool | What it detects | |---|---| | detect_console_patterns | Same error message repeating ≥ threshold times | | detect_network_patterns | Endpoints consistently slow (avg > 2s) | | detect_failed_requests | Endpoints returning 4xx/5xx repeatedly | | detect_performance_degradation | LCP / FCP / CLS regression vs a stored baseline | | detect_resource_failures | Broken image, CSS, or JS asset loads | | detect_memory_leaks | JS heap growth between snapshots | | get_pattern_history | Replay last detection run without re-collecting |

Every tool returns a human-readable report with the pattern, counts, timestamps, and a specific 💡 Suggestion.

Quick start

1. Start Chrome with remote debugging

open -a "Google Chrome" --args --remote-debugging-port=9222
# Linux: google-chrome --remote-debugging-port=9222
# Windows: chrome.exe --remote-debugging-port=9222

2. Add to your MCP client

No install needed — npx handles it automatically.

VS Code (.vscode/mcp.json or user settings.json):

{
  "servers": {
    "chrome-devtools-pattern-detector": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "chrome-devtools-pattern-detector"]
    }
  }
}

Kiro (.kiro/settings/mcp.json):

{
  "mcpServers": {
    "chrome-devtools-pattern-detector": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-pattern-detector"]
    }
  }
}

Cursor / Claude Desktop (mcp.json):

{
  "mcpServers": {
    "chrome-devtools-pattern-detector": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-pattern-detector"]
    }
  }
}

4. Ask your AI assistant

Detect console error patterns on the open tab
Check for slow network requests on this page
Are there any Core Web Vitals regressions vs baseline?

How it works

Each tool reads from window.__* globals injected by a capturing-phase script rather than relying on Chrome DevTools MCP's raw data (which lacks timing, resource errors, and vitals). This means all 6 detection patterns work without any changes to chrome-devtools-mcp.

MCP Client (VS Code / Cursor / Claude Desktop)
  │
  ▼  calls detect_*
chrome-devtools-pattern-detector (this server)
  │
  ▼  evaluate_script → window.__networkLog / __webVitals / __resourceErrors / __memorySnapshots
Chrome DevTools MCP
  │
  ▼
Your open Chrome tab

The test-page.html included in this repo injects all required globals and provides buttons to trigger each pattern type for local validation.

Tools reference

detect_console_patterns

Groups console errors by message. Flags any message appearing ≥ threshold times (default: 3).

⚠️  DETECTED ERROR PATTERNS

Pattern 1: Repeated Console Error
Message: TypeError: Cannot read properties of null (reading 'id')
Count: 5 occurrences
💡 Suggestion: Consider adding null check before accessing .id property

detect_network_patterns

Uses the Resource Timing API (performance.getEntriesByType('resource')) to find endpoints with average response time above threshold_ms (default: 2000ms).

detect_failed_requests

Reads window.__networkLog (populated by a fetch interceptor on the page). Groups 4xx/5xx failures by URL + status code with status-specific suggestions (401 → auth, 404 → path, 500 → server).

detect_performance_degradation

Reads window.__webVitals (PerformanceObserver at page load). First call saves a baseline; subsequent calls compare LCP, FCP, and CLS against it and report regressions above configurable thresholds.

⚠️  DETECTED PERFORMANCE DEGRADATION

Regression 1: LCP
Baseline : 56ms
Current  : 4056ms
Delta    : +4000ms (threshold: 1000ms)
💡 Suggestion: Critical LCP regression — check for new render-blocking resources

detect_resource_failures

Captures window.__resourceErrors via a capturing-phase error listener (catches <img>, <link>, <script> load failures). Groups by normalized URL, strips cache-busting query params.

detect_memory_leaks

Reads window.__memorySnapshots. Uses an explicit allocation counter (__allocatedLeakMb) as the primary signal since Chrome's performance.memory API quantizes readings for privacy. Flags growth exceeding growth_threshold_mb (default: 10MB) or growth_threshold_pct (default: 20%).

Test page

Open test-page.html in Chrome to trigger each pattern type with a button click:

• Trigger 5× repeated null error
• Trigger 4× slow requests (~2.5s each via httpbin)
• Trigger 4×404, 2×500, 2×403 failed requests
• Simulate LCP/FCP/CLS degradation vs baseline
• Inject broken <img>, <link>, <script> assets
• Allocate ~25MB of detached DOM + string buffers

Smoke test

node smoke-test-rpc.js
# Expected: ✅ All smoke checks passed (7 tools)

Requirements

• Node.js ≥ 18
• Chrome with --remote-debugging-port=9222
• An MCP client (VS Code Copilot, Cursor, Claude Desktop)

This server connects to chrome-devtools-mcp automatically via npx -y chrome-devtools-mcp@latest. No separate install needed.

License

MIT