MCP server for the Almanac fitness and nutrition tracking application, providing tools to query and manage user data including workouts, meals, nutrition phases, body weight trends, and LLM-powered insights.
Almanac MCP demonstrates solid tool design with clear, context-aware descriptions that guide LLM selection. All 4 tools have well-structured input schemas with proper types and descriptions. Tool names follow verb_noun convention (get_*). Descriptions are detailed (100-200 chars) and explain WHEN to use each tool relative to others. However, output schemas are not explicitly documented in the provided source, and error handling guidance is absent. No tool annotations (readOnlyHint, etc.) are visible despite all tools being read-only operations.
Day-by-day macro totals + targets for an explicit date window. Use ONLY for windows OLDER than the last 14 days — the overview already covers the recent 14-day grid. Range is bounded to 90 days. Dates are YYYY-MM-DD.
All of the user's nutrition phases, past and present (newest first). Use for 'how does this phase compare to my last one' questions — the overview only contains the ACTIVE phase. Takes no arguments.
The full data overview (today's context, the 14-day macros grid, the active phase) for a SPECIFIC day. Use when continuing a PAST conversation about that day's numbers, or to re-ground a long conversation. NOT needed for today — today's overview is already embedded in the prompt. Pass `date` (YYYY-MM-DD) for a past day; omit it for today. Returns rendered markdown.
The user's exponentially-weighted body-weight trend series (raw + smoothed). Use ONLY when the question is about weight TRAJECTORY over time — the overview already has the current weight and recent change. Returns an array of { date, raw_kg, trend_kg } points. The trend covers up to ~200 days back.
Output schemas not documented. Tool descriptions mention return types (e.g., 'Returns rendered markdown', 'Returns an array of { date, raw_kg, trend_kg } points') but formal output schema definitions are not visible in source code. LLMs cannot plan downstream operations without knowing response structure.
No tool annotations present. All 4 tools are read-only (Risk: READ_ONLY noted in metadata) but readOnlyHint annotation is not visible in schema definitions. Current MCP spec (2026-07-28) supports tool annotations for safety classification.
No error handling guidance. Tool descriptions do not explain what happens on invalid input (e.g., malformed date, out-of-range days_ago, invalid date window). LLMs have no recovery path if a call fails.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Parameter constraints not fully specified. get_weight_trend accepts from_days_ago (integer, default 90) but no min/max bounds documented. get_macros_range accepts date strings but no validation pattern or error message for malformed dates.
get_phase_history accepts no parameters but description does not explain pagination or result limits. If user has 100+ phases, response could be very large and blow context window.