DevTools telemetry in your terminal. For humans and agents. Direct WebSocket to Chrome's debugging port.
This server exposes browser debugging commands via 9 tools, all read-only. While tool names follow a reasonable verb_noun pattern (dom query, network list), the implementation has significant quality gaps: (1) Most parameter descriptions are generic and lack actionable constraints, e.g., 'Output as JSON' does not explain what JSON structure is returned, and format parameters like 'png or jpeg' are buried in descriptions rather than declared as enums. (2) No output schemas are documented anywhere in the source; LLMs cannot predict what fields to extract from responses. (3) Error handling is absent, no recovery guidance, no classification of retryable vs fatal errors. (4) The server uses STDIO transport, which blocks remote accessibility and testing. (5) Parameter naming inconsistencies: dom screenshot has both 'selector' and 'index' for element reference, but no documentation explaining when to use which or how they interact. (6) No security annotations despite exposing DOM evaluation (dom eval allows arbitrary JavaScript execution on the page). Tools are defined but lack the structure and detail expected of production-grade MCP agents.
Evaluate JavaScript expression in the page context
Get semantic accessibility structure (default) or raw HTML (--raw)
Find elements by CSS selector
Capture page or element screenshot
Show main document headers
List cookies
Export to HAR 1.2 format
Show HTTP headers
List requests with DevTools-compatible filtering
No output schemas documented. LLMs cannot predict response structure or chain tools. dom query, dom get, dom eval, and all network tools lack documented return types.
Parameter descriptions are minimal and lack actionable constraints. 'Output as JSON' appears on every tool but does not describe the JSON structure. Format enums ('png or jpeg') are buried in description text, not declared as formal enums.
No error handling or recovery guidance. Tools provide no context on when failures are retryable, what the LLM should do on invalid input, or what fields are required vs optional.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
dom screenshot parameter overload: 'selector' and 'index' both select an element, but no documentation explains when to use which, whether they are mutually exclusive, or what happens if both are provided.
dom eval tool allows arbitrary JavaScript execution without safety boundaries or permission gating. No audit trail, no scope declaration, no rate limiting documented.
network getCookies uses camelCase naming, inconsistent with snake_case convention used in other tools (network_get_cookies would be clearer).
dom screenshot has numerous optional parameters (quality, interval, limit, scroll) with no documented defaults or valid ranges. LLMs must guess sensible values.