Loading ToolBench
MCP server for detecting and analyzing client-side web errors - perfect for AI coding agents using CRUSH
The server implements 3 tools with reasonable naming (verb-starting) and present input schemas validated with Zod. However, descriptions lack the LLM-optimization depth required for A-grade tools. Parameter documentation is inconsistent, some have detailed descriptions while others are sparse. Output schemas are not formally documented. Error handling exists but lacks recovery guidance. The server follows a single-concern pattern (error detection/analysis) but the composition of tools could be clearer regarding data flow and dependencies.
Analyzes a previously collected error session to identify patterns, common errors, and generate suggestions for remediation
Detects and collects client-side web errors by navigating to a URL and monitoring for JavaScript errors, network errors, console warnings, and optionally capturing screenshots
Retrieves detailed information about a specific error including stack traces, context, and metadata
Output schemas not documented. Tools return data but LLMs cannot see field structures in advance. detect_errors and analyze_error_session return unspecified WebError collections; get_error_details returns error details with undocumented format. LLMs cannot plan downstream tool calls or extract required fields.
Descriptions are functional but lack LLM-optimization depth. detect_errors (99 chars) and analyze_error_session (106 chars) meet minimum length but don't include WHEN to use vs similar tools or prerequisite clarity. Baseline for A-grade is 50-200 chars with explicit reasoning hints. Current descriptions are bottom-quartile of that range.
Missing parameter dependency documentation. detect_errors accepts sessionId (optional) to reuse a session, but there's no guidance on when a sessionId is valid, how to obtain one, or what happens if an invalid/expired sessionId is passed. analyze_error_session requires sessionId but doesn't explain error recovery if the session doesn't exist.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error responses lack recovery guidance. Code shows generic error handling (createErrorResponse, createInvalidArgsResponse) but responses don't tell LLMs what to do next. E.g. 'Missing or invalid arguments for detect_errors' doesn't explain which argument is invalid or how to fix it.
No documented result limits or pagination. detect_errors can monitor a URL for an arbitrary waitTime (1-60s) and collect potentially hundreds of errors. analyze_error_session returns all matching errors filtered by severity. Without documented limits or pagination, LLMs risk blowing the context window. No page/offset/limit parameters present.
Tool descriptions don't clarify state mutations. detect_errors creates sessions and modifies browser state (navigates, captures screenshots). No description explicitly states this is a side-effecting operation. LLMs need to know which tools are safe to retry and which have irreversible consequences (e.g. screenshot capture, browser navigation).
Parameter 'severity' enum in analyze_error_session lacks documentation of what each value filters. Enum ['error', 'warning', 'info', 'all'] is present but descriptions don't explain when to choose each or what 'info' means in the error context (stack traces? network timing?).