Standalone MCP server for image recognition via LLM vision API — OCR, image analysis, structured extraction, image comparison
Four tools with clear action verbs and detailed descriptions (avg 180 chars). All parameters have type definitions and descriptions. Schemas are well-structured with enums and constraints. Error handling returns actionable messages. Main gaps: no output schema documentation, no pagination support for list-like operations, and missing idempotency guidance for stateful operations.
Analyze or compare image(s). Pass single image or array for multi-image. Auto-selects best provider. Supports custom prompt for any vision task.
Extract structured data (JSON) from image. Describe desired JSON schema in prompt. Auto-detects best provider. Useful for forms, tables, receipts, screenshots → JSON.
OCR: extract all text from image, preserving layout and line breaks. Handles documents, screenshots, receipts, signs, handwriting, multi-language (auto-detected: Thai, Chinese, English, Japanese, Korean, Arabic, etc.). Use for any 'read the text' task. Returns only extracted text, no commentary.
Check which LLM providers are configured and enabled. Returns provider names, models, capabilities, and health status.
No documented output schemas for any tool. LLMs cannot predict response structure or plan downstream calls. analyze_image, extract_text, extract_structured all return unstructured text without field definitions.
ping tool lacks input schema definition. Tool registration shows empty input {} but no explicit Zod schema visible in source. Cannot verify parameter validation.
No idempotency guidance. Tools that call external LLM APIs may have side effects (token consumption, rate limits). Descriptions should clarify retry safety and whether repeated calls with identical inputs produce identical results.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | <=2025-11-25 | v2 |
Provider fallback logic is complex but undocumented in tool descriptions. Users/LLMs cannot predict which provider will be used or how failures are handled. No mention of fallback behavior in analyze_image or extract_* descriptions.
Error responses use generic 'Error: {msg}' format. Should categorize as retryable vs user-fixable and provide recovery guidance (e.g., 'Provider timeout, try again or use provider=openai explicitly').