Loading ToolBench
picident-mcp headless MCP server for image identification and vision tasks across multiple providers (Mimo, OpenAI-compatible, Anthropic, Ollama, Gemini)
The server defines 3 tools with reasonable naming (verb_noun prefix: vision, list_models, providers) and most parameters have type definitions and descriptions. However, output schemas are not explicitly documented in the source, parameter constraints are minimal (no enums, ranges, or validation hints), and error handling lacks recovery guidance. Description quality is uneven: 'Identify and describe images' is clear but generic; parameter descriptions exist but some are sparse. No tool annotations (readonly/destructive/idempotent hints). The schema for the 'vision' tool's images array is detailed (data URIs, file paths, URLs), but lacks format/length constraints. No evidence of per-parameter validation or constraint documentation. Tool composition is reasonable, each tool is single-purpose, but dependencies between vision provider selection and model availability are not documented.
List available models from configured vision providers
List all configured vision providers and their metadata
Identify and describe images using configured vision providers
Output schemas not documented. The source shows input schemas for the 3 tools, but no return type definitions are visible. LLMs cannot plan follow-up steps without knowing what fields to expect (e.g., does vision() return structured annotations or free-text description? Does list_models() return name, version, capabilities?).
Parameter constraints underdocumented. The 'vision' tool accepts 'images' as array of data URIs/file paths/remote URLs, no format constraints, size limits, or count bounds documented. The 'prompt' parameter has no length limit hint. The 'max_tokens' parameter lacks min/max bounds. LLMs will pass unconstrained values (e.g., 1000-token prompt, unbounded array).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 3 tools are marked with generic 'risk: READ_ONLY' in docs, but no formal idempotent or readonly annotations are visible in the schema. Modern MCP spec supports tool annotations via capabilities to guide agent behavior.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Error handling lacks recovery guidance. No evidence of structured error responses, categorization (retryable vs user-fixable vs fatal), or actionable next steps. If the vision provider API fails or a model is not found, the LLM has no guidance on what to retry or which alternative provider to try.
Inter-parameter dependencies undocumented. The 'vision' tool accepts optional 'provider' and 'model' overrides. If a model does not exist in the selected provider, this creates a silent failure risk. The description does not state: 'If provider is omitted, the default from config is used. If model is omitted, the provider's default model is used. Invalid provider/model pairs will raise an error; call list_models(provider=X) first if unsure.'