Loading ToolBench
Exposes image quality checking as MCP tools for AI agents. Detects image format via magic bytes, measures resolution, estimates JPEG compression quality from quantization tables, and flags extension mismatches.
The server defines 2 tools with clear, descriptive docstrings and actionable parameter schemas. Both tools are read-only image analysis operations with good naming (verb_noun format: 'check_file', 'scan_folder'). Descriptions are detailed (150-300 chars) and explain WHAT the tool does and WHEN to use it. However, critical gaps prevent a higher score: (1) Output schemas are NOT documented, callers cannot see what fields to expect from the JSON responses; (2) no error handling guidance, errors return bare JSON objects without recovery hints; (3) no validation of path parameters against injection attacks; (4) default thresholds (min_width=3000, min_height=3000, min_jpeg_quality_avg=8.0) are reasonable but undocumented in parameter descriptions; (5) the folder scan response structure is ad-hoc, returned as a JSON string without a formal schema specification. The tool definitions themselves are solid (strong naming, good per-param descriptions), but lack the output documentation and error guidance needed for LLM reliability.
Check a single image file for quality issues. Detects real file format via magic bytes, measures resolution, estimates JPEG compression quality from quantization tables, and flags extension mismatches.
Batch-scan a folder of images and return quality report with warnings. Scans all supported image files (JPEG, PNG, WEBP, BMP, TIFF) in a folder. For each file: detects real format via magic bytes, measures resolution, estimates JPEG quality, and flags issues based on configurable thresholds.
Output schemas are completely undocumented. Both tools return complex JSON objects (check_file returns image metadata; scan_folder returns a report with per-file results and warnings), but neither tool description specifies field names, types, or nesting. LLMs cannot know what to extract from responses, forcing guess-work and potential misinterpretation of results.
Error responses lack recovery guidance. When a file is not found or a folder is invalid, the tool returns a bare JSON error object (e.g., {'error': 'File not found: ...'}) with no hint on what the LLM should do next (e.g., 'Try providing an absolute path' or 'Use list_files() to find available images'). This violates the recovery-guide pattern and leaves agents stranded.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
No input validation or sanitization against path traversal attacks. Both tools accept 'path' as a free-form string without validating against '../' sequences, symlink escapes, or other path traversal vectors. A malicious LLM prompt could trick the agent into scanning '/etc' or other sensitive directories. The code checks os.path.isfile() and os.path.isdir() but does not restrict to a sandbox.
Default parameter values are not explained in parameter descriptions. The scan_folder tool has defaults (min_width=3000, min_height=3000, min_jpeg_quality_avg=8.0), which are shown in the function signature, but the description text does not explain what these thresholds mean or why they were chosen. An LLM may not realize these are configurable or may pass values without understanding the consequence.
No pagination or result limiting for folder scans. The scan_folder tool returns all files matching criteria in a single response. If a folder contains 1000 images, the response JSON will be enormous, wasting tokens and potentially hitting context window limits. No per-page pagination or 'limit' parameter is offered.