Loading ToolBench
An MCP server that uses Google Gemini to analyze screenshots and organize files based on extracted order information
Server has 4 tools with basic descriptions and input schemas, but significant quality gaps. All tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization). Input schemas present but minimal, parameters lack type constraints, enums, and detailed format guidance. No output schemas documented. Error handling returns plain strings without recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Naming is verb-based but generic (organize_files, analyze_screenshot). No pagination, no structured output, no per-item error reporting for batch operations.
Analyze screenshot to extract file organization order.
List all files in the specified folder.
Organize files based on the provided order.
Undo the file organization by moving files back and removing numeric prefixes.
No output schemas documented. LLMs cannot infer what fields to expect from tool responses, forcing unstructured parsing and wasting tokens.
Error responses are plain strings without recovery guidance. E.g., 'Error analyzing screenshot: ...' tells the LLM nothing about what to do next or whether to retry.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). organize_files and undo_organization modify state but lack destructiveHint; LLMs cannot determine if operations are safe to retry.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | <=2025-11-25 | v2 |
Parameter descriptions are minimal (10-30 chars). 'Path to screenshot containing organization order' is adequate but others like 'Path to folder to list files from' lack format constraints, examples, or dependency hints.
No input validation constraints. Parameters accept free-form strings with no enum, pattern, or length limits. organize_files accepts arbitrary folder_path without path traversal checks.