Loading ToolBench
AI-powered computer use through secure E2B cloud sandboxes via Model Context Protocol
This server has moderate definition quality with clear naming conventions and mostly valid schemas, but suffers from incomplete and generic descriptions, missing parameter documentation, and no documented output schemas. The tools follow a verb_noun naming pattern (create_sandbox, execute_computer_action, get_screenshot), which is good. However, parameter descriptions are sparse or missing entirely, output structures are not formally documented, and error handling guidance is absent. The schema definitions for individual actions are present but nested deeply, making them hard for LLMs to understand. No tool annotation hints (readOnlyHint, destructiveHint) are present despite clear risk levels.
Clean up and destroy a sandbox instance
Create a new E2B desktop sandbox instance
Execute a computer action on the sandbox
Take a screenshot of the sandbox desktop
Get the VNC stream URL for a sandbox
List all active sandbox instances
Tool descriptions are extremely generic (5-15 words). Examples: 'Create a new E2B desktop sandbox instance', 'Execute a computer action on the sandbox', 'Take a screenshot of the sandbox desktop'. These lack context on WHEN to use each tool, what makes them distinct, prerequisites, and what the output structure is. LLMs cannot reliably select tools based on generic descriptions.
Parameter descriptions are missing for most parameters. The 'resolution' parameter in create_sandbox has a description ('[width, height]'), but many others like 'timeout', 'action' type, coordinate fields (x, y), and text/keys fields lack proper descriptions explaining their format, constraints, or dependencies. LLMs cannot infer that 'x' and 'y' are pixel coordinates or that certain coordinates are required for specific action types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
No output schemas are documented. Tools return success/failure and optional data (screenshot, message, timestamp), but there is no formal schema definition visible in the tool registration. LLMs cannot predict what fields will be returned, making it impossible to plan downstream tool calls or error recovery.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. The risk levels are provided in the server metadata (READ_ONLY, WRITE, DESTRUCTIVE), but these are not passed to the tool definition itself. cleanup_sandbox is DESTRUCTIVE but carries no annotation warning the LLM it should be cautious. get_screenshot is READ_ONLY but the tool definition doesn't declare this.
Error handling provides no recovery guidance. The ActionResult interface includes a 'success' boolean and 'message' field, but there are no structured error categories, retryability hints, or suggestions for what to do next. Example: when 'Sandbox not found' is returned, the error says 'Please create a sandbox first', which is helpful but inconsistently applied.
Parameter dependencies are undocumented. The 'action' object in execute_computer_action has conditional required fields (e.g., 'click' requires x,y; 'type' requires text; 'keypress' requires keys). The schema marks only 'type' as required, but the descriptions of x, y, text, keys do not explain which actions they apply to or that they are conditionally required.
No pagination or result limiting documented for list_sandboxes. If many sandboxes are active, the response could be arbitrarily large, filling the context window. The tool schema has no limit or offset parameters, and no description of what happens when there are many results.
Timeout parameter in create_sandbox is undocumented. No description of units (milliseconds?), valid range, or what happens if timeout is reached. LLMs will guess about format and risk invalid values.