Loading ToolBench
MCP Server with Recipe Generation and Food Analysis
Server has 7 tools with complete input schemas and descriptions present. However, descriptions are often generic and lack specificity about when/why to use each tool. Several tools share overlapping responsibilities without clear differentiation. Tool naming includes compound operations ('analyze_and_suggest_recipe') that violate single-responsibility patterns. Output schemas are not documented in the visible code. Error handling is minimal, no recovery guidance or categorization. Resource management (image storage) is implemented but not exposed via structured tool parameters.
Combined tool that analyzes a food image and suggests recipes based on recognized ingredients.
Analyze food image from a file path to recognize food items and get nutrition information.
Analyze food image from a URL or data URL to recognize food items and get nutrition information.
Analyze food image from the resources/images folder to recognize food items and get nutrition information.
Generate a recipe based on available ingredients and preferences.
List all images currently stored in the resources/images folder.
Tool 'analyze_and_suggest_recipe' violates single-responsibility principle, combines image analysis AND recipe suggestion. Should be split into separate tools.
Three tools (analyze_food_image, analyze_food_image_url, analyze_saved_image) perform nearly identical operations (food image analysis) with different input mechanisms. Names do not make the distinction obvious; LLMs will conflate them.
Descriptions are generic and lack actionable context. E.g., 'Suggest substitutions for a specific ingredient' does not explain WHEN to use it (allergy? cost? availability?), prerequisites, or output structure. LLMs cannot infer selection criteria from these descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Suggest substitutions for a specific ingredient.
Output schemas are not documented in source code. Neither tool descriptions nor code comments specify what fields are returned, their types, or their meaning. Agents cannot plan downstream tool calls without knowing output structure.
No error handling guidance. Error responses from LogMeal API and requests library are likely raw HTTP errors or stack traces. Agents receive no instruction on what to do next (retry? ask user? fatal?).
Parameter descriptions lack format constraints. E.g., 'image_path' has no mention of supported formats (.jpg/.png), size limits, or path requirements. LLMs will pass arbitrary values.
Default parameter values not documented. E.g., cuisine and dietary_preference both have '(default: ...)' noted in descriptions, but no indication of whether these are optional or required in the schema.
Tools that fetch external data (URLs, LogMeal API) have no timeout specification or rate-limit guidance documented. A hung API call blocks agent execution indefinitely.