Loading ToolBench
A public, authentication-free MCP server that analyzes food images using OpenAI Vision API and returns detailed nutritional information
Single-tool server with a clear naming convention (analyze_food_image, verb_noun form) and an explicit, descriptive tool definition. However, the server exhibits significant gaps in parameter descriptions, output schema documentation, error handling guidance, and lacks tool composition patterns. The tool's input schema is visible and properly typed, but output structure is documented only implicitly through OpenAI's response format, not as an explicit MCP response schema. Error handling returns generic messages without actionable recovery steps. This places the server solidly in the 'Fair' range, functional but falling short of production-grade quality.
Analyzes a food image and returns detailed nutritional information including macros (calories, protein, fat, carbs), micronutrients, and ingredients
Output schema not documented. The MCP response structure is hardcoded to return content[0].type='text' with stringified JSON, but the actual returned data structure (name, description, calories, protein, fat, carbs, fiber, sugar, sodium, servingSize, ingredients) is only documented in the OpenAI prompt, not in the MCP tool definition. LLMs cannot know what fields to expect in the response.
Input parameter lacks detailed constraints and format guidance. The 'imageUrl' description states it accepts 'URL or base64 data URL' but does not specify accepted image formats (jpeg, png, webp?), maximum file size, URL length limits, or data URI encoding constraints. LLMs cannot infer these constraints and will pass invalid inputs.
Error handling provides no recovery guidance. When the tool fails (e.g., OpenAI API error, invalid image, JSON parsing error), the response returns generic error text like 'Error analyzing food: {error.message}' with no actionable next steps. Per pattern:recovery-guide, errors should guide the LLM on what to try next (retry, provide different image, check URL format, etc.).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | 2024-11-05+ | v1 |
Tool description lacks context on when/why to use it. The description states what the tool returns (macros, micronutrients, ingredients) but does not explain WHEN an LLM should call it vs. alternatives, whether it requires internet access, or typical use cases. Per pattern:tool-description, descriptions should answer 'What does it do?' and 'When should I call it instead of similar tools?'
No idempotency guarantees documented. If an LLM retries analyze_food_image with the same imageUrl (e.g., due to transient network error), will it return the same result or potentially different nutritional estimates? This is critical for agent safety per pattern:idempotent-operation.
Tool operates as a single monolithic unit. No complementary tools exist (e.g., get_supported_image_formats, estimate_analysis_cost). Single-tool servers are less flexible for agent composition but acceptable for narrow, focused use cases.