Loading ToolBench
This server has foundational tool structure but significant quality gaps. All 5 tools have names, descriptions, and Zod-based schemas that are visible in src/server.ts. However, descriptions are generic and underdeveloped (10-50 chars), parameter descriptions lack critical context, and error handling is minimal. The schema definitions exist but are sparse, most lack detailed constraints, ranges, or examples. Tool composition is reasonable (each tool has a single responsibility), but output schemas are not documented, and error messages do not guide recovery. No per-tool error classification, no idempotent hints, no permission gates. The server registers tools correctly with the SDK, but the definitions themselves would not guide an LLM reliably toward correct usage.
Click an element on the page
Get text content of an element
Navigate to a URL
Send keys (type text) to an element
Launch a browser (chrome, firefox, or edge)
Tool descriptions are too short and generic. 'Navigate to a URL' (20 chars) does not explain WHEN to use navigate vs other tools, WHAT it returns, or dependencies.
Output schemas are not documented. Tools return { content: [{ type: 'text', text: '...' }] } but the LLM does not know the structure of the 'text' field or what properties are available. Per pattern:tool and pattern:response-shaper, return types must be explicit.
Error handling lacks recovery guidance. Code catches errors but returns raw exception messages (e.g. 'Unsupported locator strategy: ${by}'). Per pattern:recovery-guide, errors must suggest the next action: 'Use one of: id, css, xpath, name, tag, class.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions lack constraints and context. 'Locator strategy to find element' does not explain what css vs xpath means, when to use each, or valid syntax.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). start_browser and click_element modify state but have no destructive marker. get_element_text is read-only but has no hint. Per current MCP spec (2026-07-28), tools should carry these annotations.
No permission gates or scope declarations. start_browser and click_element could trigger unwanted browser automation on shared infrastructure. Per pattern:scope-declaration, tools should declare what permissions they require.
Timeout parameter in three tools (click_element, send_keys, get_element_text) has no range constraints. 'Maximum time to wait for element in milliseconds' does not specify min/max.
No batch or multi-step tools. If an agent needs to click multiple elements, it must call click_element N times sequentially, wasting tokens and latency. Per pattern:tool-chain and mxe:batch-operations, offer a batch variant or multi-action tool.