A remote MCP server for personal nutrition tracking. Log meals, track macros, and review nutrition history through Claude.
Scoring was not performed
Output schemas not documented. Code shows meal formatting (formatMeal function) but no formal declaration of what fields are returned, data types, or structure. LLMs cannot plan downstream chains or extract required IDs without explicit documentation.
Error handling guidance completely absent. No tool descriptions explain what happens on failure (invalid date format, meal not found, unauthorized access). LLMs receive no direction on recovery or next steps.
Minimal parameter descriptions for optional nutritional fields. Parameters like 'protein_g', 'carbs_g', 'fat_g' say only '[field name] in grams' with no guidance on valid ranges, whether negatives are allowed, precision/rounding expectations, or when these are required vs. optional.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 29 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 68 | - | v1 |
Delete_account confirmation not enforced at schema level. The 'confirm' boolean parameter exists but description does not emphasize irreversibility or guide the agent to ask the user before calling. Pattern:confirmation-request guidance is not clearly applied.
No pagination or result-limiting guidance in list/range queries. get_meals_by_date and get_nutrition_summary may return unbounded results. No documentation of whether results are capped, whether pagination is supported, or how to handle large date ranges.
Tool descriptions lack differentiation guidance. get_meals_today and get_meals_by_date are similar, descriptions don't explain WHEN to use each (e.g., prefer get_meals_today for 'today', use get_meals_by_date for historical queries). This forces LLM reasoning overhead.