Strong foundation with 14 well-structured tools using FastMCP. All tools have descriptions (avg 85 chars, within 10-1024 range). Input schemas present with type definitions and parameter descriptions. Naming follows verb_noun convention (search_food, record_food, list_accounts). Key strengths: pagination support (limit/page params), commit/preview pattern for write safety, account abstraction. Gaps: output schemas not documented in source; error handling returns generic _error() without recovery guidance; no tool annotations (readOnlyHint/destructiveHint); descriptions could be more LLM-optimized (some lack 'when to use' context).

• Document output schemas for all tools. Add a 'Returns' section to each tool docstring specifying field names, types, and meanings. E.g., search_food returns {account: string, query: string, results: [{id, name, calories, ...}]}.
• Enhance error handling with recovery guidance. Modify _error() to return {error: str, recovery_hint: str, available_options: []}. E.g., 'Account not found. Try: list_accounts() to see available accounts.'
• Add tool annotations via FastMCP. Use @mcp.tool(readOnlyHint=True) for search_food, list_accounts, diary_summary. Use destructiveHint=True for record_food, create_custom_recipe, upload_custom_recipe_image.
• Expand descriptions to 100-150 chars with 'when to use' context. E.g., probe_user_meal_endpoints: 'Discover custom meal/recipe form endpoints for an account. Call this before create_custom_recipe to understand available fields and validation rules.'
• Document parameter relationships in descriptions. E.g., record_food: 'Either query (search by name) or food_guid (use known ID). If query, the tool resolves it; if food_guid, it skips resolution. Provide amount + unit or unit_guid to specify quantity.'

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry