Loading ToolBench
A multi-server MCP implementation for recipe management using Spring AI, featuring favorite recipes with RAG, fridge inventory tracking, and a client for recipe discovery
This MCP server exhibits critical gaps in definition quality. While the framework uses Spring AI's MCP server infrastructure (spring-ai-starter-mcp-server-webmvc), the actual tool definitions are not visible in the provided source code. The build.gradle files confirm the MCP server dependency, but the FavoriteRecipesService and FridgeService implementations are not shown, only their filenames are referenced. Based on what IS visible: (1) Tool names (fetchFavoriteRecipes, fetchIngredientsAvailableInFridge) are ambiguous and do not follow verb_noun convention, they use camelCase and are not action-oriented despite being read operations. (2) Descriptions are generic and lack the context needed for LLM-driven tool selection. (3) Only one parameter (ingredients array) is documented across both tools; the second tool has an empty input schema, indicating missing parameter documentation. (4) No output schemas are documented, LLMs cannot infer what data structure to expect. (5) No error handling guidance visible. (6) No pagination support evident for list-like operations (favorite recipes could be many).
Fetches the favorite recipes for a list of ingredients
Fetches ingredients that are available in the fridge
Tool definitions not directly visible in source code, only file paths referenced. Actual schema, descriptions, and parameter declarations cannot be verified.
Tool names do not follow verb_noun convention and are not action-oriented. 'fetchFavoriteRecipes' and 'fetchIngredientsAvailableInFridge' use non-standard camelCase instead of snake_case verb_noun (e.g., 'fetch_recipes', 'list_fridge_ingredients'). LLMs rely on tool names for intent inference before reading descriptions.
Tool descriptions are generic and lack context. 'Fetches the favorite recipes for a list of ingredients' does not explain WHEN to use this tool vs alternatives, prerequisites, or expected output structure. Descriptions should be 10 - 1024 characters and optimized for LLM decision-making.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 23 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Parameter 'ingredients' for fetchFavoriteRecipes lacks description. LLMs cannot infer whether to pass ingredient names ('tomato', 'basil') or IDs ('ing_123'). Description must clarify format and constraints.
fetchIngredientsAvailableInFridge has empty input schema (no parameters documented). This tool should document what filters or options are available (e.g., sort order, quantity thresholds). A tool with no parameters suggests incomplete design.
No output schemas documented for either tool. LLMs cannot plan downstream operations without knowing the response structure. What fields does a recipe object contain? What is the format of ingredient lists? This forces LLMs to guess or inspect responses blindly.
No pagination parameters visible for fetchFavoriteRecipes. If this tool returns many recipes, unbounded results will exhaust token limits. Should include limit, offset, and total_count in response.
No error handling guidance visible. If ingredients are not found or fridge is empty, how should the tool respond? Should it return an empty list, an error, or suggestions? LLMs need recovery hints.
No tool composition chain documented. How do these two tools work together in the recipe finder workflow? Is the expected pattern: (1) fetch fridge ingredients, (2) pass to fetch recipes? The relationship should be explicit in descriptions and examples.