Loading ToolBench
MCP server for browser automation using Playwright
The server defines 10 tools with complete input schemas and descriptions visible in index.ts. All tools have names following verb_noun convention and descriptions present. However, quality gaps are significant: (1) Parameter descriptions are minimal (1-10 words) and lack actionable detail about format, range, or constraints. (2) No output schemas documented, LLMs don't know what fields to expect in responses. (3) Error handling descriptions missing, tools don't explain recovery paths when operations fail. (4) Descriptions are too terse (10-40 chars vs. recommended 50-200 chars baseline). (5) No tool annotations (readOnlyHint, destructiveHint) despite clear risk classification in metadata. (6) Missing actionable parameter guidance (e.g., selector format, script constraints, timeout behavior). Per-tool analysis: browser_navigate (70), browser_screenshot (65), browser_click (60), browser_click_text (60), browser_fill (65), browser_select (60), browser_select_text (60), browser_hover (60), browser_hover_text (60), browser_evaluate (50). Average: 58.
Click an element on the page using CSS selector
Click an element on the page by its text content
Execute JavaScript in the browser console
Fill out an input field
Hover an element on the page using CSS selector
Hover an element on the page by its text content
Navigate to a URL
No output schemas documented. LLMs cannot infer what fields are returned by each tool, preventing predictable chaining and forcing agents to guess about response structure.
Parameter descriptions are minimal and lack actionable detail. E.g., 'CSS selector for element to click' (37 chars) does not explain valid CSS syntax, what happens if selector matches multiple elements, or how to handle stale elements. Should include format constraints, examples of valid inputs, and error recovery guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Take a screenshot of the current page or a specific element
Select an element on the page with Select tag using CSS selector
Select an element on the page with Select tag by its text content
No error handling guidance in tool or parameter descriptions. When browser_navigate fails (network timeout, invalid URL, certificate error), agents have no recovery path. Descriptions should state expected error conditions and recovery steps.
Tool descriptions are too terse. 'Navigate to a URL' (16 chars), 'Take a screenshot of the current page or a specific element' (58 chars) are below recommended 50 - 200 char baseline. Descriptions should include WHEN to use the tool, prerequisites (must call browser_navigate first?), and what it returns to downstream tools.
No tool annotations despite explicit risk classification in metadata. browser_click, browser_fill, browser_select, browser_evaluate, browser_click_text are WRITE operations; browser_screenshot, browser_navigate, browser_hover are READ_ONLY. Annotations (readOnlyHint, destructiveHint) should be present in tool definition to guide LLM planning and safety policies.
browser_evaluate accepts arbitrary JavaScript with no constraints or validation hints. Description should warn that this is a dangerous power-user tool, explain what code can/cannot do (no file system access, no network outside page), timeout behavior, and how to safely handle script errors.
Selector and text parameters assume CSS selector knowledge but don't document format. Should clarify: 'CSS selector (e.g. #id, .class, [attr=value]). If selector matches multiple elements, clicks first. If no match, returns error: Element not found.'