Loading ToolBench
Generative image describer MCP server + CLI — an AI says what it sees (Florence-2)
plain-sight demonstrates solid tool design with clear, domain-specific naming (describe_image, describe_batch, read_text) and comprehensive parameter documentation. All 5 tools have descriptions (194 - 400 chars, within baseline 34 - 392 range). Input schemas are fully visible with proper types and descriptions. However, output schemas are not documented, responses are inferred from code comments rather than explicit schema declarations. Error handling is good (actionable messages, recovery guidance) but lacks per-item failure reporting for batch operations. Tool composition is clean (single responsibility), but describe_batch's complex parameter set (prefix, suffix, manifest_path, overwrite) introduces cognitive load.
Blocks until every image completes -- roughly 1-2 s per image plus ~10-20 s if the model is not yet loaded. Chunk large sets. Existing sidecars are skipped unless overwrite=true, so a retry is cheap. Caption a batch of images, writing .txt sidecars -- the dataset lane. The training-data contract: EXACT basename pairing (img_0042.png -> img_0042.txt, no counter suffix) and BARE prefix+caption+suffix concatenation (no delimiter injected).
Describe an image in prose — an AI says what it sees. Uses Florence-2 (MIT-licensed, runs locally) with deterministic decoding: the same image at the same tier reproduces the same description. Descriptions are generative and can hallucinate detail — for verifying a specific claim about the image, prefer ai-eyes-mcp's image_verify.
Extract visible text from an image using Florence-2 OCR. Florence-2 OCR provides no signal that an image contains no text; a short result may be invented rather than extracted. Use this for reading text off pixels, not for verifying the absence of text.
Describe bundled reference images and sanity-check output. Loads the model and runs describe_image on a small set of test images included in the package. Verifies that the engine is working and producing reasonable output. Useful for diagnosing setup issues.
Output schemas not documented. Tool descriptions mention return structure (e.g., 'returns the resolved model ID, revision, device, dtype') but no formal schema is visible in code. LLMs cannot plan downstream operations without knowing response field names and types.
describe_batch lacks per-item error reporting. If 1 of 100 images fails, the tool returns a blanket error instead of success/failure per image. Agents cannot retry selectively or report partial progress.
describe_batch parameter complexity. Eight parameters (image_paths, detail, prefix, suffix, write_sidecars, out_dir, overwrite, max_new_tokens, manifest_path) with interdependencies (manifest_path collides with sidecars, overwrite changes behavior) are underdocumented. Mutual exclusivity and conditional logic not stated.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Health check — report engine status without loading the model. Returns the resolved model ID, revision, device, dtype, and whether the model is currently loaded in memory. Does not trigger a load.
No dry-run or confirmation for destructive operations. describe_batch with overwrite=true and write_sidecars=true modifies the filesystem irreversibly. No confirmation step or dry-run mode to prevent accidental data loss.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint declared. Agents cannot infer which tools are safe to retry or which modify state without reading descriptions.