Loading ToolBench
MCP Server for image recognition via OpenRouter API
Single tool (analyze_image) with complete schema and descriptions visible in source code. Tool has a descriptive name starting with verb, clear schema with typed parameters, and basic error handling. However, descriptions are in Russian (limiting accessibility for English-speaking LLM ecosystems), parameters lack crucial constraints (no min/max for array sizes beyond minItems=1), output schema is entirely undocumented (callers don't know what structure OpenRouter returns), and error messages are generic recovery-blocking strings. No pagination despite potentially large vision outputs. No idempotency hints for retry-safety. The server exposes model selection as a parameter when it should use server-side defaults exclusively, increasing secret exposure risk. This is below median quality due to missing output schema documentation and undocumented API response structure.
Анализирует одно или несколько изображений с помощью vision модели через OpenRouter API. Поддерживает анализ скриншотов, фотографий, диаграмм и других изображений. Можно передать несколько изображений для сравнения или анализа разных аспектов.
No output schema documentation. Tool returns TextContent with OpenRouter API response, but the structure (fields, types, format) is completely undocumented. LLMs cannot plan downstream operations or extract specific fields without guessing. [Source: pattern:response-shaper]
Descriptions in Russian severely limit utility in English-dominant LLM ecosystems. Tool description is 'Анализирует одно или несколько изображений...' and parameter descriptions ('Список путей к файлам изображений') are untranslated. English-language LLMs will struggle to understand intent. [Source: pattern:tool-description]
image_paths parameter lacks length constraints beyond minItems=1. No maximum array size specified, allowing LLMs to pass 1000+ images, potentially overwhelming OpenRouter and causing timeout/cost explosions. Should constrain maxItems (e.g., 10-20). [Source: pattern:constrained-input]
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
model parameter exposed as tool input invites accidental secrets leakage. Tool accepts 'model' as an argument, but model names (openai/gpt-4o, etc.) should be server-configured via .env only. Exposing model selection as a parameter means the agent could log/echo model names in traces. [Source: pattern:secret-injection]
Error handling returns unstructured text strings ('Ошибка: ...', 'Ошибка API: ...') with no recovery guidance. LLMs cannot parse these as structured errors to determine retry eligibility, user-fixable vs. fatal classification, or corrective actions. [Source: pattern:recovery-guide]
No idempotency or side-effect declaration. Tool description does not state whether repeated calls with identical images/prompt are safe to retry (idempotent) or will incur multiple API charges (non-idempotent). Agents will not know whether to retry on timeout. [Source: pattern:idempotent-operation]
prompt parameter default is hardcoded in schema. While a sensible default exists ('Проанализируй изображение...'), the description should clarify what happens if prompt is omitted and why this default is applied. Currently unclear to LLM whether prompt is truly optional or just has a fallback. [Source: pattern:tool-description]
File path parameters accept arbitrary strings with no validation against path traversal. Tool accepts 'image_paths' directly in encode_image_to_base64() and opens files without sanitization. A malicious agent could pass '../../../etc/passwd' or similar, reading arbitrary files on the server. [Source: pattern:tool-gateway]