Strong naming conventions (all tools start with action verbs: fitness_get, fitness_search, fitness_log, fitness_delete, fitness_modify). Descriptions are present and substantive (avg ~150 chars), explaining WHAT each tool does and WHEN to use it. Input schemas are well-defined with types and descriptions for all parameters. However, output schemas are not explicitly documented in the code, responses are inferred from implementation. Parameter descriptions are clear but could be more prescriptive about constraints (e.g., meal enum values, date format validation). Error handling is mentioned in descriptions (e.g., fitness_delete_food lists candidates on ambiguity) but recovery guidance is sparse. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels documented in the spec.

• Add explicit output schema documentation for each tool. Document the structure of returned dicts (e.g., fitness_get_day returns {nutrition_summary: {...}, diary_entries: [...], note: string, feel_note: {...}}).
• Implement tool annotations in FastMCP schema: add readOnlyHint=true to all fitness_get_* and fitness_search_food; add destructiveHint=true to fitness_delete_food; add idempotentHint=true to fitness_log_weight (same date overwrites).
• Convert 'meal' parameter to enum constraint in schema: enum=['breakfast', 'lunch', 'dinner', 'snacks']. Update fitness_log_food, fitness_delete_food, fitness_modify_food.
• Enhance error responses with recovery guidance. When fitness_delete_food matches multiple entries, return error with candidate list AND suggest narrowing query. When date parsing fails, return 'Invalid date format: expected YYYY-MM-DD, got {value}'.
• Add numeric bounds to parameter descriptions: quantity (0.1 - 999), weight (10 - 500), limit (1 - 100), days (1 - 365). Document date format as ISO 8601 string with validation example.