A FastAPI-based diet and cooking assistant with meal logging, nutrition estimation, YouTube recipe discovery, and Apple Health integration. Provides tools for recipe search, nutrition lookup, meal log drafting, and meal confirmation via Telegram.
This server demonstrates reasonable structure with 7 tools, each with descriptions and visible parameter schemas. However, there are significant gaps in output documentation, error handling guidance, and parameter constraint specification. Tool names follow verb_noun convention well (prepare_meal_log, commit_meal_log, search_*). Descriptions are present but inconsistent in quality, some are detailed and prescriptive (prepare_meal_log), others are minimal (commit_meal_log). Parameter descriptions exist but lack crucial constraints (enums, ranges, formats). No evidence of output schemas or error recovery guidance in the code provided. The tools show good separation of concerns (READ_ONLY operations vs WRITE operations clearly marked) but lack idempotency documentation and confirmation patterns for destructive operations.
Commit a prepared meal log draft into Apple Health flow. Only call this after explicit user confirmation.
Search Open Food Facts database for packaged food products with nutrition labels. Useful for branded and packaged foods with barcode data. Returns nutrition per serving based on product labels.
Prepare a canonical meal log draft from a final nutrition estimate that the agent has already chosen. Use this only after the agent has used nutrition lookup tools and selected one final kcal/protein/carbs/fat estimate. Do not call this tool with placeholder sources, all-zero macros, or unknown final values. If you do not yet have a usable final estimate, ask a clarification question or explicitly choose an approximate estimate first. This tool does not perform nutrition lookup.
Search the configured YouTube recipe playlist for meal ideas, recipe inspiration, and meal-prep videos. Use this when the user wants suggestions for what to cook or eat, recipe references, or a weekly prep plan. Return playlist videos only, not general web or nutrition estimates.
Search recipe-style dishes and composed meals from Spoonacular with nutrition summaries. Best for plated dishes, home-style meals, and named recipes such as spaghetti bolognese or chicken curry. For tool calls, the query must be an English dish or recipe name.
commit_meal_log description is too brief (58 chars) and lacks prerequisites/dependencies. Does not explain what 'draft_id' represents, what format the user confirmation should take, or what success looks like. Critical for an irreversible operation.
No documented output schemas for any tool. Code shows dict[str, Any] returns but no specification of field names, types, or structure. LLMs cannot plan downstream operations without knowing what fields to extract.
Search tools (spoonacular, usda, tavily, openfoodfacts, youtube) lack explicit pagination result limits in descriptions. Code shows 'max_results' parameters but no statement of what happens if results exceed limit, whether pagination is supported, or if truncation is silent.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Search nutrition information using Tavily web search. Useful for restaurant menu items, branded products, and real-world meal contexts. Returns relevant nutrition data from web sources.
Search USDA FoodData Central foods and return key nutrient values. Best for generic ingredients, simple foods, and common staples such as rice, eggs, chicken breast, or yogurt. Do not use this as the primary lookup path for named restaurant menu items or exact branded prepared meals such as Subway sandwiches or Big Mac. For tool calls, the query must be an English common food or ingredient name.
Parameter constraints not formalized as enums. E.g., 'diet' and 'intolerances' in spoonacular_search_recipe accept free-form strings. No enum of valid diet types (vegan, vegetarian, paleo, etc.) or intolerances. LLMs will hallucinate invalid values.
No error handling guidance in tool descriptions. prepare_meal_log and commit_meal_log do not document failure modes: what if draft_id is invalid? What if user_id is not found? What should the agent do next?
commit_meal_log has a required boolean 'confirmed' parameter but no explanation of when the agent should call with true vs false, or if this is a confirmation-pattern tool that should block execution until user confirms. Ambiguous semantics.
Numeric parameters lack bounds. E.g., 'number' in spoonacular_search_recipe has default 5 and max 20, but code shows max: 20 in schema, description should state '1-20' range. Same for page_size in usda_search_foods (default 5, max 25) and max_results elsewhere.
prepare_meal_log accepts 'timezone_name' with default 'America/New_York' but no validation or list of accepted timezones shown. If invalid timezone is passed, will it error or silently use default? Not documented.
Optional parameters lack guidance on when to omit vs include. E.g., 'nutrition_confidence' in prepare_meal_log is optional, but no description of what confidence range (0-1? 0-100?) is expected or what happens if omitted.
prepare_meal_log description warns 'do not call with placeholder sources' but no actionable list of valid nutrition_source values. How should the LLM distinguish a placeholder from a valid source?