This server has critical definition gaps across all 9 tools. Most tools lack parameter descriptions entirely (analyze_last_7_days, analyze_last_21_days, analyze_3_months, get_upcoming_races, get_planned_week, get_planned_month all have empty properties {}). The three tools with parameters (get_specific_workout, schedule_intervals_workout, clear_intervals_day) have minimal descriptions. Tool descriptions are present but generic (10-80 chars), lacking WHEN to use guidance or prerequisites. No output schemas documented. No error handling guidance. No parameter validation rules stated. The server exposes destructive operations (clear_intervals_day) without confirmation patterns or permission gates.

• Add input schemas with typed properties and descriptions to all six parameterless tools. Example: analyze_last_7_days should document what filters (if any) it accepts, or explicitly state it takes no parameters with 'additionalProperties: false'.
• Document output schemas for all tools. Specify the structure of returned data (e.g., array of workout objects with fields: id, date, duration, intensity, tss). This enables LLMs to chain tools and extract values.
• Add a 'confirm_delete' parameter to clear_intervals_day (boolean, default false) or implement a separate 'preview_intervals_day' tool that shows what would be deleted before committing.
• Expand parameter descriptions to include format rules, constraints, and examples. E.g., 'date (YYYY-MM-DD format, must be within next 365 days, e.g. 2025-01-15)' and 'workoutText (Intervals.icu workout format: e.g. "2x10min@Z4 + 5min recovery").'
• Add error handling guidance to tool descriptions. E.g., 'If Strava API is unreachable, returns cached data from last 24h. If Intervals.icu auth fails, prompts user to refresh API key.' This helps LLMs understand failure modes and recovery paths.