Loading ToolBench
MCP server for RoxyBrowser automation - manage browser instances and get CDP endpoints
This server has 2 tools with extremely vague descriptions and completely opaque schemas. Tool names ('perform', 'snapshot') lack action clarity. Input and output schemas are not visible in provided source, only inferred to exist. Descriptions are 1-2 sentences with no parameter guidance, no error recovery hints, and no examples of valid input. The tools appear to be thin wrappers around browser automation actions but lack the specificity required for LLM-driven invocation. No per-parameter descriptions visible. No documented return types or structures. This server falls well below production baselines for agent-ready tooling.
Set up a route to mock network requests matching a URL pattern
List all active network routes
Remove network routes matching a pattern (or all routes if no pattern specified)
Tool names lack action verbs. 'perform' and 'snapshot' are vague, LLMs cannot infer intent. 'perform' could mean any action; 'snapshot' omits the subject (snapshot of what?). Should be verb_noun like 'execute_action', 'take_screenshot', or 'capture_page_snapshot'.
Input schemas not visible in provided source code. Cannot verify parameter types, required fields, descriptions, or constraints. Tools appear to be inferred rather than explicitly registered with full schemas.
Descriptions are under 50 characters and provide no actionable context. 'Tool to perform browser automation actions in the loop tools backend' tells an LLM nothing about WHEN to call it, WHAT actions it supports, or HOW to invoke it. No parameter guidance, no error recovery hints, no dependencies documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 12 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
No output schema documentation visible. LLMs cannot plan downstream steps if they don't know what fields to expect from 'perform' or 'snapshot'. Return type and structure must be formally documented.
No error handling guidance. If 'perform' fails, what should the LLM do? Is it retryable? Should it ask the user? No recovery hints, no error classification, no actionable error messages visible in tool definitions.
Tool composition is unclear. 'perform' suggests multiple possible actions but provides no discovery mechanism or branching logic. Should there be separate tools for click, type, navigate, wait? Or should 'perform' expose an action parameter with enum constraints?
No documentation of risk or side effects. 'perform' is marked as WRITE/destructive but the description says nothing about what state changes could occur. Agents need explicit warnings about irreversible operations.