Loading ToolBench
MCP server giving OpenCode/Claude Code a persistent, headed Playwright browser (Claude-Code-style browser control): navigate, click, fill, inspect, request-human.
Five tools with clear naming (verb_noun pattern) and reasonable descriptions (80-150 chars). All tools have input schemas with type definitions. However, parameter descriptions are minimal or absent in several tools, and output schemas are not formally documented. Error handling is basic, no recovery guidance or actionable error messages. The inspect tool returns a screenshot file path but no guidance on how to interpret the element tree. Overall: solid foundation but missing LLM-optimization details that would push this to 70+.
Click an element. target can be the numeric target from browser_inspect, a CSS selector, or visible text. Highlights the element briefly before clicking.
Type a value into a text field. target can be the numeric target from browser_inspect, a CSS selector, or visible text.
Screenshot the current page and list its interactable elements with numeric targets, so you can click or fill by number. Use this before click/fill rather than guessing.
Open a URL in the persistent browser and wait for the page to load. Returns the final URL and page title.
Pause the flow and ask the human a question. Returns awaiting_human; the model must stop automation and surface this to the user, then resume only after they answer.
Parameter descriptions missing or minimal. 'target' parameter in browser_click and browser_fill has a description, but it is terse and does not explain the three resolution modes (numeric, CSS, text) clearly enough for LLMs to choose correctly on first attempt.
Output schemas not formally documented. Tools return structured objects (e.g., {url, title, element_count, elements, screenshot}) but no JSON Schema or type hints are visible in the tool definitions. LLMs cannot reliably extract fields from undocumented responses.
Error handling lacks recovery guidance. When resolveElement() throws 'No interactable element #3', the error message lists known targets but does not suggest calling browser_inspect() first. Errors should guide the LLM to the next step.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
browser_inspect description does not explain what the numeric targets are or how to use them. LLMs need explicit guidance: 'Returns a list of interactable elements, each with a numeric target ID. Pass the target number to browser_click or browser_fill to interact with that element.'
No idempotency or confirmation pattern for destructive operations. browser_click and browser_fill modify page state but have no dry-run, confirmation, or undo mechanism. If an LLM misidentifies a target, the action cannot be reversed.