Loading ToolBench
FastMCP server exposing LightOCR to Claude Desktop / Claude Code / any MCP client. Provides OCR tools for PDFs and images using LightOnOCR model served by llama.cpp.
LightOCR defines 4 tools with clear, detailed descriptions (avg 180 chars) and complete input schemas. Naming is verb-forward (ocr_*, get_*, check_*). However, output schemas are not documented in the visible code, and error handling lacks recovery guidance. Parameters are well-described but lack explicit type constraints (enums, ranges). The server is well-structured for its domain but falls short of production-grade polish.
Probe the llama-server /health + /v1/models endpoints. Returns a dict with health status, model id (if available), and any error details. Useful for agents to verify the OCR backend is running and ready before attempting a document.
OCR exactly one page of a PDF (cheap, targeted re-reads). When an agent needs to re-examine a single page of a document already OCR'd by ocr_document, this tool avoids re-processing the whole file: it renders only the requested page, sends it to the model, and returns cleaned text. Useful for follow-up questions or corrections.
OCR a PDF or image file into clean markdown. Routes by file extension (.pdf -> PDF pipeline; png/jpg/jpeg/webp/tif/tiff -> image pipeline) and honours the text-layer fast path for PDFs, so born-digital pages skip the model entirely. Short documents (page count <= inline_threshold_pages) are returned inline. Longer ones are written to a file -- to LIGHTOCR_OUTPUT_DIR if set, else an out/ directory beside the input -- as <stem>.md (never overwriting: an existing name gets a -2, -3, ... suffix), and only a preview is returned, to keep an agent's context window small.
OCR a base64-encoded image passed directly (no filesystem path). For clients that hold image bytes rather than paths (e.g. Claude Desktop with a pasted screenshot), this tool accepts the raw base64 of a PNG/JPEG/WebP/TIFF and returns cleaned OCR text. The image is normalised (resized if needed) and sent through a single OCR request; text is cleaned identically to ocr_document.
Output schemas not documented. Tools return structured data (DocResult, dict with stats/warnings, health status) but no schema is visible in code or docstrings. LLMs cannot plan downstream calls or extract fields reliably.
Error handling lacks recovery guidance. ToolError exceptions are raised with messages, but no guidance on retryability, next steps, or alternatives. E.g., 'Input file not found' should suggest checking the path or listing available files.
Parameter constraints not formalized. 'inline_threshold_pages' accepts any integer but should have min/max bounds (e.g., 1 - 100). 'media_type' is free-form string instead of enum (image/png, image/jpeg, image/webp, image/tiff).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
No pagination or result-limiting guidance. ocr_document returns full markdown inline for short docs (≤5 pages) but no explicit cap on output size. Long documents are written to file with a 1500-char preview, but this behavior is not documented in the tool description.
check_health tool name is generic. 'check_health' does not clearly indicate it probes the OCR backend (llama-server). Better name: 'check_ocr_backend_health' or 'probe_llama_server'.