Loading ToolBench
MCP server (TypeScript) that drives ANY Chromium-based browser (Chrome, Edge, Brave, Opera, Vivaldi, plain Chromium, headless launchers) over the Chrome DevTools Protocol. Pass any --remote-debugging-port and get full automation: navigate, click, fill, scroll, screenshot, evaluate, cross-origin iframe support.
14 tools with complete schemas and descriptions, but quality is uneven. All tools have input schemas with typed parameters and descriptions (baseline met). Tool names follow verb_noun convention (navigate, click, fill, screenshot, etc.). However, descriptions are terse (avg ~80 chars, below the 194-char baseline for A+ tools) and lack context on WHEN to use each tool or dependencies between them. No output schemas documented, LLMs cannot predict what fields to expect. Error handling is absent from descriptions. No tool annotations (readOnlyHint/destructiveHint). Parameter descriptions are minimal; many lack format/constraint guidance. No pagination support despite tools that could return large results (query_selector_all, get_page_content). Security: host/port are exposed as parameters rather than server-side config.
Click an element on the page by CSS or XPath selector.
Probe the Chromium debug endpoint. Returns the browser version and the list of available page targets (id, url, title). Use this first to confirm a port is reachable and to discover target_id values.
Evaluate a JavaScript expression in the page context and return the result.
Fill a form field (input, textarea, contenteditable) by CSS or XPath selector.
Get an attribute value of an element by CSS or XPath selector.
Get the text content of an element by CSS or XPath selector.
Get the full HTML content of the current page.
No output schemas documented. LLMs cannot predict return types or plan downstream tool calls. E.g., connect() returns browser version and targets, but structure is undocumented.
Descriptions are terse (avg ~80 chars vs 194-char baseline). Missing context on WHEN to use each tool, dependencies, and error recovery. E.g., 'Click an element on the page by CSS or XPath selector' lacks guidance on selector format or failure modes.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes without explicit hints. E.g., screenshot and navigate both modify state but lack annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Get the text content of the current page (innerText).
Navigate the page to a URL.
Query all elements matching a CSS or XPath selector and return their text content.
Take a screenshot of the current page and save it to a file.
Scroll the page by a given amount (pixels or to an element).
Wait for an element to appear on the page (by CSS or XPath selector) with a timeout.
Wait for the page to navigate to a new URL with a timeout.
Host and port exposed as tool parameters instead of server-side config. Agents can pass arbitrary hosts/ports, creating security and operational risks. Should use environment variables or config file.
No error handling guidance in descriptions. Tools like click, fill, wait_for_element can fail (selector not found, timeout) but descriptions do not explain recovery steps or error categories.