Loading ToolBench
Exposes basic browser automation through HTTP and MCP
Scoring was not performed
All tool descriptions are under 100 characters and lack context for agent selection. Descriptions like 'Open a new browser tab' do not explain WHEN to use the tool, what prerequisites exist, or what the agent should expect. LLMs cannot distinguish these tools from similar ones without richer docstrings.
Parameter descriptions are generic and do not explain constraints, formats, or valid ranges. For example, 'headless' parameter lacks guidance on default behavior. 'selector' parameters lack explanation of CSS selector format or fallback behavior if no match found. 'timeout' parameters lack unit or range constraints (milliseconds assumed but not stated).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 22 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Output schemas are completely undocumented. The source code shows no return type specifications for any tool. LLMs cannot plan downstream operations without knowing what fields to expect (e.g., does screenshot_tab return a URL, base64 data, or a resource ID? Does get_tab_info return an array or object?). This violates the pattern:tool requirement.
No error handling guidance visible in tool descriptions. If a CSS selector fails to match, what does the tool return? If a navigation timeout occurs, is it retryable? If evaluate_script throws an exception, does the tool return the error or fail the entire request? LLMs need explicit recovery guidance per pattern:recovery-guide.
Tool descriptions do not state which operations are write (with side effects) vs read-only. While the metadata includes 'Risk' classification, the descriptions themselves do not warn the LLM. For example, 'reload_tab' description does not say 'This will reload the page and may trigger network requests.' Agents rely on descriptions, not metadata, to understand consequences.
Parameter type specifications lack enum constraints where applicable. For example, 'waitUntil' in wait_for_navigation and reload_tab should be an enum (e.g., 'networkidle0', 'networkidle2', 'domcontentloaded', 'load'), not a free-form string. This invites hallucinated values and requires the tool to validate and reject invalid input.
No dependency hints in descriptions. For example, if a tab must be opened before screenshot_tab can work, the description should state this. If fill_field expects the element to be visible, the description should mention wait_for_selector as a prerequisite. This guides multi-step planning and prevents wasted calls.
No idempotency guarantees documented. Agents retry on ambiguous failures, if open_tab is not idempotent and an LLM retries after a timeout, it will create duplicate tabs. Tool descriptions should state idempotency status to guide agent retry logic.
tabId parameter lacks explanation of how to obtain a tab ID. If agents must call get_tab_info first to discover tab IDs, the descriptions for other tools should hint at this. Otherwise, agents might guess at IDs or fail to understand the prerequisite workflow.