Loading ToolBench
Convert table images to Excel files using MCP protocol and Qwen-VL model.
Single tool with poor naming, vague description, incomplete parameter documentation, and minimal error handling. The tool name 'image_to_Excel' violates verb_noun convention (should be 'convert_image_to_excel' or similar). Description is only 28 characters and lacks context for when/why to use it. Parameters have types but descriptions are minimal (7-72 chars). No output schema documented. No error recovery guidance. No input validation hints. Security considerations (file path validation, directory traversal prevention) are undocumented.
Convert table image to Excel file.
Tool name violates verb_noun convention. 'image_to_Excel' is not an action-oriented verb_noun pattern. Should be 'convert_image_to_excel' or 'extract_table_from_image'.
Tool description is 28 characters ('Convert table image to Excel file.'). Rubric requires 10-1024 chars with context for WHAT, WHEN, and WHY. This is too terse to guide LLM tool selection. Should explain: What table formats are supported? What happens on OCR failure? Is the output file path returned?
Parameter 'output_path' description is 'Output directory for the Excel file (optional, defaults to current directory)', 72 chars. Does not explain format constraints (must be absolute? must exist?). Does not mention what happens if directory does not exist (code shows it's created, but LLM cannot know this from description).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
No output schema documented. Tool returns a file path string, but response structure is undocumented. LLM cannot know: Is it an absolute path? A relative path? What if the operation fails, does it return an error object or raise an exception?
No error handling or recovery guidance. Code can raise ValueError, FileNotFoundError, API errors, etc. Error responses return JSON dicts like {"error": "..."}. LLM has no guidance on retryability, user-fixable issues, or next steps. Should document: 'If image format unsupported, call with a PNG or JPG. If API times out, retry with smaller image.' etc.
Security risk: Path traversal vulnerability. 'output_path' parameter is user-controlled and directly used in os.path.join(). No validation against '../' or absolute paths escaping sandbox. File write is marked WRITE risk, but no mention of permission checks or sanitization in tool description.
API key stored in environment variable without documentation. .env loading is present in code (dotenv.load_dotenv), but tool description does not mention 'Requires api-key and api-base environment variables.' LLM has no visibility into dependencies.
Parameter 'image_path' description is minimal: 'Path to the input image file'. Does not specify: Supported formats (PNG, JPG, TIFF, BMP)? Max file size? What happens if file does not exist? Relative vs absolute paths OK?
No idempotency guarantee documented. Function generates timestamped output filenames, so repeated calls with same image produce different files. Agents may retry on transient failures, is this behavior acceptable? Should be explicit in description.