Loading ToolBench
MCP server providing nutrition information lookup via USDA FoodData Central API. Allows searching for food items and retrieving detailed nutritional data including macronutrients, calories, and fiber content.
The server defines 3 tools with complete input schemas and descriptions. Naming follows verb_noun convention (search_*, get_*). Descriptions are present but vary in quality, search_food_items includes helpful context ('ALWAYS use this first'), while descriptions for get_nutrition_by_id and search_nutrition are concise but lack guidance on error recovery or when to use each tool vs. the others. Parameters have types and descriptions, but several critical gaps exist: (1) no output schema documentation for any tool; (2) no error handling guidance (what if USDA API returns invalid IDs, or food_portions is empty?); (3) no pagination support despite search returning 'multiple options'; (4) tool descriptions could better distinguish when to use search_nutrition vs search_food_items (both search, but one is 'quick', ambiguous for LLM); (5) no indication that amount parsing handles ambiguous inputs like '1 medium' gracefully or what happens on failure.
Get detailed nutrition information for a specific food item using its ID from search results
ALWAYS use this first to search for food items by name. Returns multiple options to choose from since ingredient names vary widely (e.g., 'firm tofu' vs 'soft tofu')
Quick nutrition lookup using best match. Use search_food_items first for better accuracy when ingredient names might be ambiguous
No output schema documented for any tool. LLMs cannot predict what fields to extract or how to chain results to downstream calls. E.g., does search_food_items return fdcId, and can get_nutrition_by_id always consume it?
Tool purpose ambiguity: search_food_items and search_nutrition both search, but descriptions don't explain when to use which. 'Quick nutrition lookup using best match' (search_nutrition) vs 'ALWAYS use this first' (search_food_items) is contradictory, an LLM may pick the wrong one or make extra calls.
No error recovery guidance. Tool descriptions do not explain what happens on invalid fdcId, missing food_portions, or API failures. E.g., 'If food not found, try search_food_items with a partial name' would guide retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
No pagination metadata. search_food_items accepts limit (max 20) but does not indicate if more results exist or how to fetch the next page. Responses should include total_count or next_cursor.
Parameter 'amount' lacks validation constraints in description. What formats are valid? '100g', '1 cup', '1 medium' are examples, but are '50 kg' or '-5g' rejected? What is the default behavior if parsing fails?
Tool descriptions include example values ('tofu', 'chicken', 'apple'). LLMs tend to reuse examples literally in unrelated contexts. Use parameter enums or formal constraints instead.