Loading ToolBench
MCP server for AI-powered image recognition and description using OpenAI-compatible vision models.
Single tool 'describe-image' has a clear verb-noun name and basic schema with two parameters. However, descriptions are minimal (tool: 82 chars, params: ~50 chars each), falling short of the 194-char baseline for production tools. Input schema uses Zod but lacks explicit type declarations in the visible registration (imageUrl and prompt are inferred as strings from usage, not formally declared in the schema object shown). No output schema is documented. Error handling returns generic text responses without actionable recovery guidance. Security validation for local paths and URL domains is present in code but not reflected in parameter descriptions. No pagination, no structured output documentation.
Describe an image by URL or local file path with a custom prompt
Tool description is too brief (82 chars). Should explain WHEN to use this tool vs alternatives, what it returns, and any prerequisites. Current description lacks context for LLM selection.
Parameter descriptions are minimal (~50 chars each). 'The image url or local file path to describe' does not explain format constraints (e.g., supported image types, max file size, allowed domains if restricted). LLMs cannot infer these from the name alone.
No output schema documented. Tool returns text content but LLMs need to know the exact structure (e.g., is it always a single text field? Can it fail gracefully with structured error info?). Undocumented outputs force LLMs to guess.
Error handling returns generic text ('Error describing the image: ...') without actionable recovery guidance. Should categorize errors (retryable vs user-fixable) and suggest next steps (e.g., 'Check image URL is accessible' or 'Verify file path is within allowed directories').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Security constraints (allowed image paths, allowed domains, file extensions) are enforced in code but NOT documented in parameter descriptions. LLMs cannot see these constraints and may pass invalid inputs, leading to silent failures or confusing error messages.