Loading ToolBench
MCP server that gives AI coding assistants eyes to see visual output from local development environments
Single tool 'screenshot' has a well-structured schema with 6 parameters, all typed and described. Description is clear (97 chars) and explains the core function. However, output schema is not documented, LLMs cannot predict what fields the response contains. Error handling returns JSON with 'error' and 'message' fields but lacks recovery guidance (e.g., 'try a different URL' or 'check network'). Parameter descriptions are adequate but could be more prescriptive about constraints (e.g., viewport format examples, waitFor enum values are documented but not in description text). No tool annotations (readOnlyHint, idempotentHint) despite being read-only. Naming is clear and verb-based ('screenshot'). Composition is single-purpose, which is correct.
Captures screenshots of web pages with automatic image optimization for LLM compatibility
Output schema not documented. LLMs cannot predict response structure (fields, types, nested objects). Tool returns base64 image data but this is not declared in any schema.
Error responses lack recovery guidance. Returns 'Screenshot capture failed: <message>' but does not suggest next steps (e.g., 'verify URL is accessible', 'try a different viewport', 'check network connectivity').
Tool is read-only but lacks readOnlyHint annotation. Agents cannot infer from the tool definition alone that this is safe to call repeatedly without side effects.
Parameter 'viewport' description mentions format examples ('1280x720', '1280x720@2x') but does not state the regex pattern or validation rules. LLMs may pass invalid formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Parameter 'waitForSelector' is optional but its interaction with 'waitFor' is undocumented. If waitFor='none', does waitForSelector get ignored? Ambiguous dependencies invite misuse.