Loading ToolBench
MCP server for personalized nutrition coaching with meal planning, calorie calculation, grocery lists, and recipe generation
The server provides 5 tools with mostly complete JSON Schema input definitions and reasonable descriptions. However, there are significant gaps in parameter descriptions, schema completeness, and error handling guidance. Tool naming follows verb_noun convention adequately. Most parameters lack inline descriptions beyond the schema type, forcing LLMs to infer context. Output schemas are not documented at all. Error handling is minimal, tools do not guide recovery or indicate whether failures are retryable. The descriptions, while present, are functional but not optimized for LLM decision-making (many are under the 50-200 char baseline for production tools). No tool annotations (readOnlyHint, destructiveHint) are present. This is a typical mid-tier community server with solid structural foundations but weak in the details that make tools reliable for agentic systems.
Calculate TDEE (Total Daily Energy Expenditure) and macro targets based on personal stats and goals
Get detailed explanation and rationale for nutrition recommendations and meal plans
Generate detailed step-by-step cooking instructions and tips for a specific meal
Generate a consolidated, categorized grocery shopping list from a meal plan
Generate a personalized meal plan based on calorie and macro targets with dietary restrictions
Output schemas completely undocumented across all 5 tools. LLMs cannot predict what fields to extract or plan chained calls without knowing return structure.
Parameter descriptions are generic and underdescriptive. Most lack context on valid formats, constraints, or why the parameter matters. E.g., 'Daily protein target in grams' does not explain range expectations, rationale, or error handling.
Loose object parameters lack schema definitions. 'meal_plan' (in grocery_list) and 'meal' (in generate_recipe) are typed as 'object' with no nested schema, forcing LLMs to infer structure from prior tool outputs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 12 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are marked risk:READ_ONLY in metadata but this is not reflected in the MCP tool definition for agent safety reasoning.
No error handling guidance. Tools do not indicate what happens on invalid input (e.g., age=5 or weight_kg=25 violates constraints), whether failures are retryable, or what the LLM should do next.
Tool naming inconsistency and verbosity. 'meal_plan' and 'grocery_list' lack leading verbs. 'explain_plan' is vague (does not name the entity being explained). Baseline is verb_noun: get_*, create_*, search_*.
Enum constraints not enforced in schema. 'diet_tags' lists examples as description text instead of JSON Schema enum array. 'budget' parameter in grocery_list uses string type without enum constraint.
Tool descriptions are terse and generic. 'meal_plan' (47 chars), 'explain_plan' (88 chars), 'generate_recipe' (106 chars) lack context on when to call, prerequisites, or what makes this tool different from alternatives. Baseline is 50-200 chars with explicit WHAT/WHEN/PREREQ guidance.