Loading ToolBench
MCP server for browser DevTools and backend debugging - analyze console logs, network requests, and backend logs with AI assistance
The server defines 13 tools with explicit schemas and descriptions in src/index.ts. Most tools have reasonable descriptions (avg ~100-150 chars) and structured input schemas with typed properties. However, there are significant gaps: (1) Most tools lack output schema documentation, the code does not show what fields/structure the agent receives after invocation. (2) Parameter descriptions are inconsistent, some parameters lack detail on expected formats, ranges, or constraints (e.g., 'pattern' in console_search has no format guidance). (3) Several tools combine multiple concerns or lack clear composition guidance (e.g., error_correlate conflates console+network analysis). (4) No tool has explicit error recovery guidance in descriptions. (5) Tools dealing with IDs (tabId, processId) do not document whether human-readable names are accepted. Overall: definitions are present and structured, but lack the production-grade detail needed for reliable LLM composition.
Attach to Node.js, Deno, or Chrome debugger for runtime inspection and debugging
Stream and analyze backend application logs from various sources
Connect to a specific browser tab for debugging
Disconnect from a specific browser tab
Launch a new browser instance with debugging enabled
List all available browser tabs that can be connected to
Advanced console search with pattern matching, correlation, and statistics
Output schemas not documented. Tools like console_search, network_analyze, performance_profile, and error_correlate lack explicit documentation of their return types and fields. LLMs cannot plan downstream tool calls or extract required data without knowing the response structure. This violates the tool pattern requirement that every tool must document its output schema.
Parameter constraint details missing. Many numeric and string parameters lack explicit ranges, formats, or validation rules in descriptions. Example: 'limit' parameters describe the default (100) but not min/max bounds. 'pattern' parameter in console_search does not specify if regex syntax differs between basic/advanced modes. 'statusRange' has no guidance on whether min/max are inclusive or exclusive.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Search and filter console messages from connected browser tabs
Automatically correlate errors between console and network, find root causes
Analyze network requests and responses from connected browser tabs
Export network traffic to HAR (HTTP Archive) format
Get network performance statistics for a connected browser tab
Advanced performance profiling with bottleneck detection and recommendations
Identifier type ambiguity. Tools use 'tabId', 'processId', and 'source' as required parameters but do not clarify if these are opaque system IDs or human-readable names (e.g., tab title, process name). The pattern recommends accepting natural identifiers and resolving them server-side. Current descriptions force agents to guess the ID format.
No error recovery guidance. Tool descriptions do not indicate what errors are retryable, user-fixable, or fatal. Example: if browser_connect fails with 'connection refused', should the agent retry, launch a new browser, or report to the user? This violates the recovery-guide pattern.
Tool composition complexity. error_correlate conflates console and network analysis, it automatically correlates errors across two domains without giving the agent control. Similarly, performance_profile combines waterfall visualization and recommendations into one call. These tools combine multiple concerns, making them less composable. Per pattern:tool guidance, each tool should do exactly one thing.
Missing descriptions on complex nested parameters. console_advanced_search has nested 'patterns', 'namedPatterns', and 'correlate' objects. Their descriptions are terse (e.g., 'Pattern matching configuration') and lack examples of valid structure or when to use nested vs flat parameters. LLMs cannot reliably construct complex nested payloads without detailed examples or schema constraints.
Pagination not documented for list/search tools. console_search, network_analyze, backend_logs_stream, and console_advanced_search accept 'limit' but do not document pagination strategy (offset vs cursor) or if a 'total' or 'hasMore' field is returned. The pattern recommends pagination with a next_cursor or total count for large result sets.
browser_launch description lacks clarity on side effects and browser lifecycle management. It says 'Launch a new browser instance' but does not clarify: Is a browser launched on the server or the client? Does it persist across calls? Does browser_disconnect close it, or only the DevTools connection? This ambiguity breaks the compose pattern, agents cannot reason about state.
No explicit idempotency guarantees. Tools like browser_connect and backend_debugger_attach do not document idempotency. If an agent retries due to ambiguous failure, will repeated calls cause duplicate connections, resource leaks, or errors? Idempotency is critical for agent reliability.