Loading ToolBench
A powerful, intelligent browser automation tool that performs comprehensive website testing using AI-driven test generation and execution with MCP server integration for advanced research and automation capabilities.
This MCP server has severe definition quality issues across nearly all dimensions. Tools lack proper schema documentation, descriptions are either missing or wildly inappropriate for LLM use, and parameter types are not clearly specified. Tool names mix procedural patterns (ask_for_assistant, handle_action_error) with imperative patterns. Most critically, several tools expose internal Python types (BrowserContext, Page, threading.Event, Exception) as parameters, which violate the principle that tools should accept human-friendly inputs. The 'ask_for_assistant' tool description is a policy statement rather than a tool description. Error handling is minimal. Output schemas are not documented. The server appears designed for internal automation rather than LLM-agent integration.
When executing tasks, prioritize autonomous completion. However, if you encounter a definitive blocker that prevents you from proceeding independently – such as needing credentials you don't possess, requiring subjective human judgment, needing a physical action performed, encountering complex CAPTCHAs, or facing limitations in your capabilities – you must request human assistance.
Execute parallel browser searches based on LLM-provided queries with concurrency and stop signal handling
Handle action errors with detailed context and suggestions for error recovery
Perform comprehensive security testing including SQL injection, XSS, CSRF, and path traversal vulnerability detection
Runs a single BrowserUseAgent task with browser creation and lifecycle management
Upload file to interactive element with file path
Tools expose internal Python types as parameters (BrowserContext, Page, Exception, threading.Event, Any). LLMs cannot construct or provide these. These parameters should be removed or wrapped with human-friendly abstractions (e.g., 'browser_id', 'page_url', 'error_message', 'task_id').
No tool has a documented output schema. LLMs cannot plan downstream calls or extract results without knowing what fields are returned. All 6 tools lack output documentation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Descriptions are missing or inadequate for LLM selection. 'ask_for_assistant' is a policy statement (300+ chars). 'upload_file' is 8 words (under 20-char floor). 'handle_action_error' reads like internal docs. None explain WHEN to call them vs. alternatives or WHAT data is returned.
Tool names use non-standard patterns: 'ask_for_*', 'handle_*', 'run_*' are procedural/generic. Names like 'ask_for_assistant', 'handle_action_error', 'perform_security_testing' suggest internal orchestration rather than user-facing tool selection. LLMs cannot infer action intent from these names.
No parameter constraints or validation guidance. 'task_query' strings are unconstrained. 'index' is an integer with no documented range. 'max_parallel_browsers' lacks a default or max value. Violates mxe:param-validation-rules and pattern:constrained-input.
No error handling or recovery guidance. Tools do not document error conditions, retryability, or what an LLM should do if the tool fails. 'handle_action_error' itself takes an Exception parameter but provides no output structure for how errors should be communicated.
No tool composition or chaining support. Output schemas are undocumented, so downstream tools cannot reference IDs or data from prior calls. Violates pattern:tool-chain.
'ask_for_assistant' tool does not fit the MCP tool model. It describes a fallback policy for when the agent is blocked, not an actionable tool. This should be handled via agent control flow or multi-round-trip requests (MRTR), not a tool.
Security: 'browser' and 'page' parameters are BrowserContext and Page instances managed by Playwright. Exposing these as tool parameters violates separation of concerns and makes it unclear how LLMs should provide them. Should be managed server-side via session/context IDs.