Loading ToolBench
MCP server to capture iOS Simulator screenshots
The server exposes a single tool 'get_screenshot' with a complete input schema and description. The naming follows verb_noun conventions (get_screenshot). However, the tool description is minimal (7 words, 50 chars), falling below the 10-word baseline for actionable descriptions. Parameter descriptions exist but are generic and lack formatting constraints. The output schema is not documented, the tool returns a ScreenshotResult type that is not visible in the provided code, making it impossible to verify what fields agents will receive. Error handling appears basic (McpError with error codes) but lacks recovery guidance or user-fixable vs retryable classifications. The tool is straightforward and functional, but lacks the depth needed for reliable agent planning.
Capture a screenshot from iOS Simulator
Tool description is too short (50 chars, 7 words). Should be 10-100 words explaining WHAT the tool does, WHEN to use it, and WHAT it returns. Current: 'Capture a screenshot from iOS Simulator' lacks context for agent selection.
Output schema not documented. ScreenshotResult type is referenced but not visible in provided code. LLMs cannot plan downstream operations without knowing what fields are returned (e.g., file_path, dimensions, success_flag, error_message). This violates pattern:tool baseline 100% of A+ tools document return types.
Parameter descriptions lack format constraints and validation rules. Example: 'output_filename' has no guidance on allowed characters, length limits, or file extension handling. 'max_width' is an integer with no stated min/max bounds, LLMs could pass 0 or 999999. 'device_id' has no explanation of format (UUID? string name?) or how to discover valid device IDs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Error handling is minimal. McpError with ErrorCode.MethodNotFound is raised for unknown tools, but there is no guidance on what errors the tool itself can return (e.g., simulator not running, screenshot capture failed, invalid device). Error responses should tell the LLM what to do next (pattern:recovery-guide).
Tool does not declare what it does when called repeatedly (idempotency). If an agent calls get_screenshot twice with the same parameters, does it overwrite the previous file or generate a new one with a timestamp suffix? Agents retry on ambiguous failures, non-idempotent behavior could produce duplicate files.