Loading ToolBench
Local evidence-first web debugging MCP server for Codex, Claude Code, and other MCP clients.
Server has 14 tools with basic schemas and descriptions, but significant quality gaps. Most tool descriptions are terse (10-50 chars), well below the 50-200 char baseline for LLM-optimized descriptions. Parameter descriptions are minimal or absent. The submit_payment tool (fixture) is a security red flag, payment amounts should never be exposed as tool parameters. Tool naming is inconsistent: web_* prefix is verbose; some names conflate multiple concerns (web_browser_action bundles navigate/click/fill/press/select/check/hover/scroll/wait/reload). No output schemas documented. Error handling guidance is absent. Only 1 of 14 tools has descriptions approaching adequacy.
Submit one positive checkout amount up to 1000000.
Set a breakpoint in the debugging session
Execute a browser action in the debugging session
Control debugger execution (pause, resume, step)
Evaluate JavaScript expression in the debugging session
Verify a fix against recorded scenarios
Capture issue evidence including screenshots and DOM state
submit_payment exposes payment amounts as tool parameters, critical security anti-pattern. Sensitive operations must use server-side secret injection and confirmation flows, never raw parameters.
web_browser_action bundles 10 distinct actions (navigate, click, fill, press, select, check, hover, scroll, wait, reload) into one tool. This violates single-responsibility principle and forces LLMs to reason about which action to invoke. Should split into separate tools: click_element, fill_input, navigate_url, etc.
13 of 14 tools have descriptions under 50 characters (baseline 50-200 for LLM optimization). Examples: 'Get current web session status' (30 chars), 'Inspect next element or state' (29 chars). Descriptions lack WHEN to use, prerequisites, or return value guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2025-06-18+ | v2 |
Inspect next element or state in the debugging session
Detect web project configuration and framework
Seek to a specific point in the replay timeline
Record a reproduction scenario
Close a web debugging session
Start a new web debugging session
Get current web session status
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing return structure. E.g., does web_session_start return sessionId, session_id, or id?
Parameter descriptions are minimal or absent. 'action' in web_browser_action is described only as 'Browser action to execute (navigate, click, fill, ...)' with no guidance on format, required fields, or error cases. Parameters lack type clarity and constraints.