Loading ToolBench
MCP servers for weather, image processing and other tools
This server has 2 image processing tools with visible schemas and descriptions. Both tools have complete JSON Schema input definitions with parameter types and descriptions, which is positive. However, there are significant gaps in output documentation, error handling guidance, and parameter constraint specificity. The descriptions are adequate (150-200 chars) but lack context about when to use each tool vs. alternatives. Critical issue: the source code is truncated mid-function in crop_image (ends at 'ymax = int((ymax / 1000) * img_height)' line), making it impossible to verify error handling, output format, and validation logic. Per the HARD SCORING RULES, tools without visible complete implementations are capped at 50 overall. Both tools are below that due to missing output schema documentation and incomplete source visibility.
Apply a mosaic (pixelation) effect to a rectangular region defined by bounding box coordinates. This is typically used for anonymization, e.g. masking faces, license plates, or other sensitive areas while leaving the rest of the image unchanged.
Crop the image to a specified rectangular region defined by normalized bounding box coordinates (0-1000). This tool is designed to work directly with Vision Language Model outputs which typically provide coordinates in [ymin, xmin, ymax, xmax] format on a 0-1000 scale.
Source code truncated, cannot verify complete implementation, error handling, or output format. crop_image function is cut off mid-implementation.
No output schema documented for either tool. LLMs cannot know what fields to expect in the response, making chaining and result extraction unreliable.
Descriptions lack actionable context about when to use each tool. crop_image and apply_mosaic serve different purposes (cropping vs. anonymization), but descriptions don't explain the distinction or when to prefer one.
Parameter constraints not fully specified. xmin, ymin, xmax, ymax in crop_image are documented as 0-1000 range, but no explicit validation constraints (min/max) are declared in the schema itself.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
Error handling and recovery guidance absent. No documentation of what happens if crop region exceeds boundaries, if block_size is invalid, or how LLMs should recover from failures.
apply_mosaic uses raw pixel coordinates (x0, y0, x1, y1) while crop_image uses normalized 0-1000 coordinates. This inconsistency will confuse LLMs and likely lead to misuse or incorrect parameter passing between tools.
Optional output_path parameters are documented but their default behavior is unclear. Description says a file will be 'created next to the source image,' but no confirmation of where or what filename format is guaranteed.
No parameter validation rules documented. block_size in apply_mosaic is described as 'must be a positive integer' but no minimum/maximum bounds are specified. What happens if block_size=1? block_size=1000?