Chrome Devtools

Chrome DevTools MCP — Ultra-fast Testing & Debugging

[!IMPORTANT] This skill MUST be executed strictly under the Omni-Architect Agent Protocol v1.0. All tool executions, code modifications, and communications MUST adhere to the 13 core protocols.

📌 When to Activate (Automatic Trigger)

This skill activates automatically when the agent needs to:

1. Test a web interface (verify elements exist, forms work, user flows are correct)
2. Debug errors (browser console, network requests, CORS, JS errors)
3. Audit performance (LCP, CLS, TBT, Lighthouse)
4. Validate accessibility (DOM inspection, ARIA attributes)
5. Fill and submit forms programmatically
6. Execute JavaScript in the context of the page

🔴 CRITICAL RULE: CDP-First, Visual-Second

Do I need to interact with a browser?
│
├─ Is it to READ data (DOM, Network, Console, accessibility)?
│   └─ ✅ USE chrome-devtools MCP (evaluate_script, list_network_requests, list_console_messages)
│
├─ Is it to AUTOMATE actions (clicks, forms, navigation)?
│   └─ ✅ USE chrome-devtools MCP (click, fill, fill_form, navigate_page, press_key)
│
├─ Is it to AUDIT performance?
│   └─ ✅ USE chrome-devtools MCP (performance_start_trace, lighthouse_audit)
│
├─ Is it to VERIFY that something LOOKS right (design, colors, layout)?
│   ├─ Can I verify via DOM/CSS?
│   │   └─ ✅ USE chrome-devtools MCP (evaluate_script to read computed styles)
│   └─ Do I really need a visual screenshot for the user?
│       └─ ⚠️ USE chrome-devtools MCP → take_screenshot (1 single shot, no subagent)
│
└─ Is it a visual demonstration for the user or a recording?
    └─ 🔄 USE browser_subagent (ONLY valid case — see "handling-browser-5mb-limit" Skill)

NEVER use browser_subagent to:

• Read page content (use evaluate_script or take_snapshot)
• Verify if an element exists (use wait_for or evaluate_script)
• Fill out forms (use fill or fill_form)
• Navigate between pages (use navigate_page)
• Inspect network/console (use list_network_requests, list_console_messages)

🛠️ Available Tools (34 tools)

Input Automation

Navigation

Emulation

Performance

Network

Debugging

📋 Operation Protocols

Protocol 1: UI Testing

1. navigate_page → Dev server URL
2. wait_for → Key element selector
3. evaluate_script → Verify content/state
4. fill_form → Fill forms if applicable
5. click → Interact with buttons/links
6. list_console_messages → Verify 0 errors
7. list_network_requests → Verify OK responses

Protocol 2: Debugging

1. navigate_page → Problematic URL
2. list_console_messages → Look for errors/warnings
3. list_network_requests → Look for failed requests
4. get_network_request → Inspect specific request
5. evaluate_script → Inspect app state

Protocol 3: Performance Audit

1. navigate_page → URL to audit
2. lighthouse_audit → Full audit
3. performance_start_trace → Detailed trace
4. [Simulated user interactions]
5. performance_stop_trace → Trace data
6. performance_analyze_insight → Bottleneck analysis

Protocol 4: Responsive Testing

1. navigate_page → URL to test
2. resize_page → 375x667 (mobile)
3. take_screenshot or evaluate_script → Verify layout
4. resize_page → 768x1024 (tablet)
5. resize_page → 1440x900 (desktop)

🔗 Integration with Other Skills

• handling-browser-5mb-limit: If you need a visual capture, use take_screenshot from this MCP instead of the browser_subagent, eliminating the risk of exceeding the 5MB limit.
• Pre-Delivery Gate: Use lighthouse_audit to verify Performance ≥ 90 and Accessibility ≥ 95 before delivery.

⚠️ Known Limitations

1. Does not generate recordings/videos: For recorded video demos, use browser_subagent.
2. Does not emulate visual human interaction: If the user wants to SEE what the flow looks like step-by-step like a human, use browser_subagent.
3. Requires Chrome to be open: If Chrome is not running, some tools may fail.

Remember: This MCP is your primary tool. The browser_subagent is your fallback for visual evidence. Speed > Captures.