A multi-interface (REST and MCP) server for automatic license plate recognition
Omni-LPR is a specialized license plate recognition server with 5 tools. All tools have clear action-verb names (recognize_, detect_, list_) and reasonable descriptions (80-150 chars each). Input schemas are present with proper enum constraints for model selection. However, there are significant gaps: (1) No output schemas documented, the server does not declare what fields will be returned from recognition results; (2) Parameter descriptions are minimal and do not explain formats, error cases, or what constitutes a valid image; (3) No error handling patterns, no guidance on what happens when an image is invalid, unreadable, or contains no plate; (4) No acknowledgment of dependencies between tools (e.g., when to use recognize_plate vs. detect_and_recognize_plate); (5) Tools 1-4 show high redundancy (recognize_plate and recognize_plate_from_path do nearly the same thing, as do detect variants) but lack composition guidance. The schema presence (enums for models) saves this from a lower score, but missing output documentation and error recovery patterns are material gaps for LLM reliability.
Detects and recognizes license plates in a provided base64-encoded image. Performs both detection and OCR on the image.
Detects and recognizes license plates in an image at a given path or remote URL. Performs both detection and OCR on the image from the specified location.
Lists all available detector and OCR models that can be used with the other tools.
Recognizes license plates from a provided base64-encoded image without detection. Requires a base64 string of an image containing a license plate.
Recognizes license plates from an image at a given path or remote URL without detection. Accepts local file paths or HTTP/HTTPS URLs.
No output schemas documented for any tool. Callers (LLMs) cannot predict what fields recognize_plate returns (plate_text? confidence? bounding_box? raw_text?). This forces LLMs to guess at response structure and unable to chain tool outputs reliably.
Tools 1 & 2 (recognize_*) and tools 3 & 4 (detect_and_recognize_*) are nearly identical except for input modality (base64 vs. path/URL). High redundancy with no composition guidance. LLMs may select the wrong variant. Recommend consolidating to single tools accepting flexible input types or documenting clear decision criteria.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Tool names 'detect_and_recognize_plate' and 'detect_and_recognize_plate_from_path' contain 'and', indicating multiple responsibilities. Per pattern guidance, tools should do exactly one thing. These should be split into separate 'detect_plate' and 'recognize_plate' tools, or documented with clear usage guidance on when to use detect_and_recognize vs. recognize_plate only.
Parameter descriptions are terse and lack actionable constraints. E.g., 'Base64-encoded image data containing a license plate' does not specify file size limits, image dimensions, supported formats (JPEG/PNG/GIF/WebP?), or what happens if the image is invalid or contains no license plate.
No error handling guidance. What happens when: (1) image is unreadable, (2) no license plate is detected, (3) OCR confidence is low, (4) remote URL is unreachable (for _from_path tools)? LLM cannot anticipate failures or plan recovery.
Enum model choices are extensive (6 YOLO detector variants) but lack documentation on when to choose which. What is the tradeoff between yolo-v9-s-608 and yolo-v9-t-256? Speed vs. accuracy? Supported plate types? This forces LLM guessing or requires external documentation lookup.