Futureweb Intervals MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| API_KEY | Yes | Intervals.icu API key (Settings → Developer Settings). Required. | |
| MCP_AUTH | No | none, or oauth to enable the built-in OAuth 2.1 server. Default: none. | |
| ATHLETE_ID | Yes | Athlete ID, e.g. i123456 or 123456. Required. | |
| MCP_TENANCY | No | single (default) or multi: in multi, every connection uses its own Intervals.icu credential. | |
| MCP_TOOLSET | No | full (every tool of the enabled classes) or core (curated set of 23 tools). Default: full. | |
| OAUTH_LOGIN | No | Sign-in method(s): intervals, password, apikey. Default: intervals with an app, else password if set, else apikey. | |
| FASTMCP_HOST | No | Bind address of the HTTP transports. Default: 127.0.0.1. | |
| FASTMCP_PORT | No | Bind port of the HTTP transports. Default: 8000. | |
| MCP_TRANSPORT | No | stdio, sse, http or http+sse (/mcp and /sse in one process). Default: stdio. | |
| MCP_PUBLIC_URL | No | Public base URL, required with MCP_AUTH=oauth. | |
| OAUTH_USERNAME | No | Password sign-in username. Default: athlete. | |
| MCP_PERMISSIONS | No | Enabled tool classes, e.g. read, write or all. Default: read. | |
| OAUTH_TOKEN_KEY | No | Multi-user mode (required): key that encrypts the stored Intervals.icu tokens. | |
| ATHLETE_TIMEZONE | No | Time zone for "today" and default date ranges, e.g. Europe/Vienna; server uses the server clock. Unset: the timezone of the Intervals.icu athlete profile. | |
| FASTMCP_SSE_PATH | No | SSE endpoint path. Default: /sse. | |
| OAUTH_STATE_FILE | No | Registered clients and refresh token digests. Default: ./oauth_state.json. | |
| OAUTH_TOTP_SECRET | No | Authenticator code as second factor for password and API-key sign-in. | |
| OAUTH_PASSWORD_HASH | No | Password sign-in hash. | |
| FASTMCP_MESSAGE_PATH | No | SSE message endpoint path. Default: /messages/. | |
| OAUTH_OWNER_ACCOUNTS | No | Your own other Intervals.icu accounts; the only other athletes the single-user mode accepts on the allowlist. | |
| OAUTH_TOKEN_KEY_FILE | No | Multi-user mode (required): file holding the key that encrypts the stored Intervals.icu tokens. | |
| FASTMCP_ALLOWED_HOSTS | No | Public Host headers accepted behind a reverse proxy (DNS rebinding protection); defaults to the host of MCP_PUBLIC_URL. Required for a public endpoint without OAuth. | |
| CUSTOM_UNITS_OVERRIDES | No | Display units per custom item code, e.g. Stamina=%,RecoveryTime=h. | |
| INTERVALS_API_BASE_URL | No | API base URL. Default: https://intervals.icu/api/v1. | |
| OAUTH_ALLOWED_ATHLETES | No | Athletes allowed to sign in. Default: ATHLETE_ID. | |
| FASTMCP_ALLOWED_ORIGINS | No | Allowed origins behind a reverse proxy; defaults to the host of MCP_PUBLIC_URL. | |
| INTERVALS_OAUTH_CLIENT_ID | No | Intervals.icu OAuth app client id for "Continue with Intervals.icu". | |
| CUSTOM_AGGREGATE_OVERRIDES | No | Aggregation per custom field code in summaries (sum, device_load_sum, trend, mean, none), e.g. TrainingLoad=device_load_sum. | |
| INTERVALS_OAUTH_CLIENT_SECRET | No | Intervals.icu OAuth app client secret for "Continue with Intervals.icu". |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_gear_listA | Use to find gear ids and get an overview of the athlete's bikes, shoes and components (read-only). One row per item: id, type, name, default-for, activity count, distance in km and retired flag. Details of one item (components, reminders, filters): get_gear_details; activities on a gear: get_activities(gear_id=...). |
| get_gear_detailsA | Use for the details of one gear item (bike, shoes, component; read-only). Distance, time and activity count, purchase and retirement dates, notes, the bike a component belongs to, the activity type filters that assign activities automatically, maintenance reminders with their usage, and for a bike its components (frame, power meter, chain, tyres ...) with their own mileage. Which power meter recorded an activity is not derived from gear: get_activity_details shows the power meter and serial from the device file. Activities on this gear: get_activities(gear_id=...). |
| get_athlete_profileA | Use for who the athlete is: name, sex, date of birth, location, time zone, units, weight, height, resting HR, bikes and shoes, training plan and coach (read-only). Also one line per sport setting (FTP, indoor FTP, LTHR, max HR, threshold pace). Only coaching-relevant fields: account internals such as e-mail, API keys or OAuth scopes are never returned. The profile's time zone defines "today" for all tools. Details: get_sport_settings, get_training_zones, get_gear_list. |
| get_sport_settingsA | Use for the current thresholds and settings per sport (a group of activity types such as Ride, GravelRide/MountainBikeRide or Run/TrailRun; read-only). Per sport setting: FTP and indoor FTP, W', Pmax, the latest Intervals.icu eFTP estimate, LTHR and max HR, threshold pace with pace units, load models, default outdoor/indoor gear, warm-up/cool-down times and the power, HR and pace zones with absolute ranges. The thresholds in force for a past activity are in get_activity_details (snapshot stored with the activity). Zones only: get_training_zones; change thresholds: update_sport_settings. |
| get_training_zonesA | Use for the power, heart rate and pace zones of each sport setting (read-only). Power zones in % of FTP with watts from the current FTP and the sweet spot range, HR zones in bpm, pace zones in % of threshold speed with the pace from the threshold pace; each zone has its name, bounds and absolute range. Current settings only. Thresholds and other settings: get_sport_settings. |
| get_custom_itemsA | Use to list the athlete's custom items (charts, custom activity, interval and wellness fields, streams, zones ...) with id, name, type and description (read-only). Also refreshes the cached definitions the other tools use to label custom fields. Full definition of one item: get_custom_item_by_id. |
| get_custom_item_by_idA | Use for the full definition of one custom item: name, type, description, visibility, index and its content configuration as JSON (code, value type, units, options, aggregate ...; read-only). Ids: get_custom_items. |
| get_activitiesA | Use to find activities and their ids in a date range (default the last 30 days up to today, 10 per page), e.g. all rides on one bike over a season. Returns one summary block per activity (Intervals.icu load, power, HR, feel/RPE, gear), one line each with detail_level=compact, or JSON records with units and local/UTC start. Filters: sport types, gear, power meter name. Any filter, sort, offset, compact or json gives a paged listing with the total and the next offset. Unnamed activities are hidden unless include_unnamed; nothing outside the date range is listed. Read-only. One activity in depth: get_activity_report. Method: intervals://methods/activity-data (get_guide). |
| get_activity_detailsA | Use when one activity's full summary, thresholds or device custom fields are needed beyond get_activity_report. Returns the summary (time, distance, Intervals.icu load, power, HR, cadence, feel/RPE, FTP and thresholds used, device and power meter), fueling, weather, W′ balance and source, plus every custom activity field with a value (device metrics such as training effect, recovery time, stamina, sweat loss), read from the athlete's own definitions with name, code, value and units; 'no value' = null/NaN on Intervals.icu. full adds time in zones, running dynamics and other raw fields. Read-only. Method: intervals://methods/activity-data (get_guide). |
| get_activity_intervalsA | Use for per-interval numbers of one activity (laps or detected efforts): power, HR, cadence, speed, intensity, custom interval fields and groups. Cadence follows the sport: steps per minute on foot (2 x the stored per-leg value), rpm otherwise. stream_types adds start/end/min/max/mean/delta of any stream per interval from the recorded samples, e.g. stamina drop or a second power meter (list_activity_streams shows what exists). include_planned_types shows the planned step matched to each interval and the time beyond the plan; the Intervals.icu type is kept. Without intervals use analyze_climbs. Read-only; 2 API calls, +1 for streams, +1 for a paired event. Methods: intervals://methods/activity-data, intervals://methods/execution (get_guide). |
| get_activity_streamsA | Use for the raw time-series samples of one activity (power, HR, cadence, altitude or any custom stream such as Stamina) when summaries are not enough. Default output is a per-stream summary (units, statistics, first/last values); full gives a CSV table, json one object with arrays (empty/null = no value). Default streams: time, watts, heartrate, cadence, altitude, distance, velocity_smooth; "all" = every stream. full/json return at most max_points samples (default 2000) and say where to continue; slice by index or time, downsample keeps every n-th sample. time = seconds since start, pauses appear as jumps. Read-only. Discover streams with list_activity_streams. Method: intervals://methods/activity-data (get_guide). |
| list_activity_streamsA | Use before get_activity_streams or get_activity_intervals(stream_types=...) to see which data streams one activity has. Lists the standard streams and the athlete's custom streams present on the activity (e.g. stamina, potential stamina, performance condition, grade adjusted speed, gear selection, battery) with type code, display name, units and description, plus the power fields of the file. include_stats downloads the streams and adds per-stream sample counts and start/end/min/max/mean. Read-only. Method: intervals://methods/activity-data (get_guide). |
| get_activity_messagesA | Use to read the notes and comments on one activity: author, time, type and text of each message (read-only). |
| get_eventsA | Use to see the athlete's calendar: planned workouts, races, notes and other events of a date range (default today to 30 days ahead). Each event shows its category (Workout, Race A/B/C, Note ...), sport (Ride, Run ...), planned time and load, and the paired activity once it has been done. Full workout steps: get_event_by_id. Plan phases and weekly targets: get_training_plan. |
| get_event_by_idA | Use to read one calendar event completely, e.g. to read back a workout right after writing it. Returns category and sport, planned time and load, the paired activity and the full workout document (steps, planned time in zones). |
| get_training_planA | Use for the season view: the assigned training plan, plan phases, weekly targets, races with priority and events that set the fitness model (read-only). Reads the training plan assigned to the athlete and the calendar entries of the annual plan: PLAN (phases/blocks), TARGET (weekly load, time or distance targets), RACE_A/B/C, SEASON_START, and set eFTP / set fitness and fatigue / fitness days. Default range: 30 days back to 180 days ahead. Single workouts: get_events. |
| get_athlete_power_curvesA | Use for an athlete's best power per duration over whole periods: season bests, progress between seasons or date ranges. Returns watts and W/kg per duration for this season, last season and/or a custom range, each with the activity that set it. Defaults: Ride, 5 s to 60 min, both seasons; durations that are not curve points are left out. Read-only, one API call. One activity: get_best_efforts; HR and pace: get_hr_curves, get_pace_curves. Method: intervals://methods/comparisons (get_guide). |
| get_hr_curvesA | Use for the highest average heart rate an athlete sustained per duration over one or more periods (e.g. comparing periods; with get_pace_curves the same pace at a lower HR). Returns bpm per duration for each curve (default the last 90 days) with the activity that set it; durations without data are listed as not available. Read-only, one API call. Power: get_athlete_power_curves. Method: intervals://methods/comparisons (get_guide). |
| get_pace_curvesA | Use for an athlete's best times per distance over one or more periods: PBs, comparing periods, progress in running or swimming. Returns the best time and pace (min/km; min/100 m for Swim and OpenWaterSwim) per distance for each curve (default the last 90 days) with the activity that set it; optionally gradient-adjusted pace. Distances not on the curve are listed as not available. Read-only, one API call. HR side: get_hr_curves. Method: intervals://methods/comparisons (get_guide). |
| get_best_effortsA | Use for the peak efforts of one activity: best average power, HR or speed over durations (s) or distances (m), e.g. peak 5 s to 20 min power or the fastest km of a run (velocity_smooth with distances). Returns per effort the average (W, bpm or m/s with pace) and its position as elapsed h:mm:ss and sample indices (usable as start_index / end_index); windows spanning a recording pause are flagged. Default durations 5 s to 60 min; longer than the activity = not available. Read-only; one API call per duration or distance plus 1-2. Several activities: compare_best_efforts; period bests: get_athlete_power_curves. Method: intervals://methods/comparisons (get_guide). |
| compare_best_effortsA | Use to compare peak efforts (e.g. 1 / 5 / 20 min power) of several activities side by side: development over a block, races, or whether a new bike or power meter reads differently. Returns a matrix of activities (date, sport, gear, FTP at the time) by duration with the best average of the stream, and the best activity per duration. Activities come from activity_ids or a date range (default the last 90 days), filtered by sport and gear; newest first, limit 10 (max 25), at most 10 durations. Power meters of different bikes are not calibrated against each other; no verdict. Read-only; one API call per activity and duration (up to 250) plus the list and gear calls. One activity in detail: get_best_efforts. Method: intervals://methods/comparisons (get_guide). |
| find_similar_intervalsA | Use to find earlier activities with intervals of a given length and intensity (% of FTP), or like the main set of a reference activity, ranked by comparability. Pass min/max_secs and min/max_intensity, or reference_activity_id (window from its main set: length ±25 %, intensity ±8 points of FTP; explicit values win; only the 365 days before it unless start_date is given). Returns per activity date, sport, interval summary, load, FTP at the time, gear, power meter, compliance and a comparability score 0-100 with reasons. Sport defaults to one family (other families are counted, "all" keeps every sport); watts of different power meters are not comparable, use % of FTP. Read-only; one API call (+2 with a reference, +1 gear catalog). Details: get_activity_intervals; same workout over time: compare_workouts. Method: intervals://methods/comparisons (get_guide). |
| get_activity_histogramA | Use for the time distribution of one activity independent of zone definitions: how polarised a ride was, time above FTP, the pace spread of a run. Returns the seconds and % of recorded time in each power (W), heart rate (bpm), pace or grade-adjusted pace bucket, as computed by Intervals.icu; pace and GAP buckets are speeds in m/s shown with the pace range. bucket_size applies to power and hr only. Read-only, one API call. Method: intervals://methods/comparisons (get_guide). |
| compare_workoutsA | Use to compare repeated executions of the same workout over time (e.g. every 3 x 10 min threshold session) on truly comparable work intervals. Activities by name search (query), activity_ids or a date range (default the last 90 days); limit 8 (max 12). WORK intervals are split into main set (similar length and intensity), surges, other and excluded; the main set gets time-weighted power, NP, HR, max HR, cadence, W/bpm. Only activities matching the reference pattern (reference_activity_id, else the newest; length ±25 %, intensity ±8 points of FTP) are compared; trends first -> last with n (< 3 not reliable). RPE is whole-activity only; gear and power meter differences are flagged; no verdict. Read-only; one API call per activity plus 1-3 (one more per id with activity_ids). Method: intervals://methods/comparisons (get_guide). |
| get_power_hr_efficiencyA | Use to track power-to-heart-rate efficiency (W per bpm at the same power) over weeks. Puts every WORK interval of at least min_interval_secs with power and HR into the power band of its average power; returns per activity and band the count and time-weighted W, HR and W/bpm, and per band the oldest vs the newest group of activities (each counts once; at least 3 per group, else not reliable) compared with the day-to-day SD. Default the last 90 days of rides, limit 30 (max 60); trends per gear when several power meters are involved; filters for gear, indoor/outdoor and interval start time. Heat, fatigue, cadence and sensors move the ratio: statistics only, no fitness verdict. Read-only; one API call per activity plus 2. Method: intervals://methods/comparisons (get_guide). |
| get_fatigue_resistanceA | Use for fatigue resistance: best power fresh vs after the athlete's work thresholds kJ0 / kJ1 (Intervals.icu fatigued power curves). Reads the sport settings first. When they hold no kJ thresholds no fatigued values are shown: the tool explains the setting and (suggest_thresholds) proposes thresholds from body mass and recent rides, never saved. Otherwise returns watts per duration fresh and after kJ0 / kJ1 with the change in %, for one activity or for athlete curves (default 42d); a fatigued curve without data is reported as missing, one equal to fresh as identical, without a change. Read-only, 2-5 API calls. Within one long ride: get_long_ride_fatigue_profile. Method: intervals://methods/comparisons (get_guide). |
| compare_power_streamsA | Use to compare two power meters recorded on the same ride (watts vs secondary_power by default), on one ride or across several rides. One ride (activity_id): offset in W and % (secondary - primary), per power band, in stable 30/60 s windows, drift over the ride quarters, lag, best efforts of each stream and the samples excluded as coasting, missing or outliers. Several rides (no activity_id, or activity_ids): the rides that carry the second stream (default 180 days to end_date, newest first, limit 10, max 20), each compared on its own and summarised per bike and power meter with median, between-ride SD and range. No calibration and no correction factor; sensors are named only from the file's device data. Read-only. Method: intervals://methods/power-meters (get_guide). |
| analyze_workout_executionA | Use to check how a planned workout was executed, or without a plan to evaluate each detected interval of one activity. The plan comes from planned_workout_doc, event_id or the event paired with the activity. Planned steps (repeats expanded) are aligned with the intervals by order, duration or distance and target intensity, never by names; laps that split one effort are merged. Per step: planned vs actual moving time, target (W, bpm or pace) vs actual, time in target, HR response, cadence, fade, Pw:HR drift (work steps of 10 min or more) and custom stream changes, with deviation notes and an alignment confidence. Time past a step's plan and training after the plan are reported apart. Unpaired: up to three candidate events, nothing is paired. Read-only. Method: intervals://methods/execution (get_guide). |
| analyze_climbsA | Use for activities without useful intervals (tours, mountain hikes, trail runs) to split the recording into climbs, descents, sections in between and pauses. Per segment: time and sample indices, moving time, distance, gain/loss, average and steepest grade, VAM, speed, power, NP, HR, cadence and start/end/min/max/mean/delta of every custom stream. Defaults follow the sport (foot vs bike); implausible grades are flagged and each segment gets a grade confidence. Slow scrambling counts as moving, real pauses as pause. Climb gains are not the activity's total elevation gain. Text lists up to max_segments segments. Read-only, 2 API calls (activity, all streams). Method: intervals://methods/climbs (get_guide). |
| get_training_loadA | Use for acute and chronic training load in detail: acute (default 7 d) and chronic (28 d) Intervals.icu load, acute:chronic ratio (coupled daily means), Foster monotony and strain, deload-like weeks, per sport family with the primary sport, ISO weeks, and CTL/ATL/form/ramp at the end date (read-only). Rest days count as 0; sessions without a load are counted, not added. Device loads (custom fields such as a Garmin training load) are listed apart on their own scale, never added. With the default end date and nothing recorded today yet, the windows end yesterday. Reference ranges (ACWR 0.8-1.3, monotony > 2.0) are shown with sources as context; small samples are flagged; no verdict. Overview: get_coach_context; planned load: get_load_projection. Method: intervals://methods/load (get_guide). |
| get_load_projectionA | Use for future fitness: CTL, ATL and form projected over the planned workouts in the calendar, or a what-if scenario (sessions or weekly templates not in the calendar) against the calendar plan (read-only, nothing is written). Starts from Intervals.icu's CTL/ATL at the end of yesterday plus today's completed load; planned workouts without a load are reported, not guessed. Returns end values, lowest form, highest ramp, ISO weeks with plan statistics, race days, Intervals.icu's own projection, a model check and weeks outside commonly cited ranges (ramp 5-8 CTL/week, monotony > 2.0, no rest day). With target_date, target_form or a scenario: the target day (default the next RACE_A) at the start of the day; target_form adds a search for the load of the last taper_days that reaches it. Arithmetic, not a forecast; no verdict. Method and scenario format: intervals://methods/load (get_guide). |
| get_activity_data_auditA | Use to check where an activity's data came from and what is missing, or without activity_id how complete the data of a period is. One activity: source (sync, upload, Strava stub), upload and analysis times, filtered duplicates, recording stops, FIT laps vs intervals and edits, sensors, streams vs those usual for the sport with coverage, custom fields with value / zero placeholder / none, fields the Garmin Intervals Bridge could fill. Period (default 28 days to end_date): per sport how many activities have power, HR, GPS, weather, custom streams and fields. Facts and counts, no verdict; read-only, 1-3 API requests. Method: intervals://methods/activity-data (get_guide). |
| get_activity_reportA | Use first for any question about one activity: overview, plan vs execution, power meter check, climbs and data quality in one call (read-only, 3-4 API requests). The overview has thresholds, device, sport-assigned custom fields, fueling, weather and W′ balance. With a paired event or planned_workout_doc the plan-vs-execution analysis follows (as analyze_workout_execution), otherwise the intervals; a second-power-meter check only with enough valid paired samples; climbs without intervals or above 500 m gain; then data-quality notes. compact = core numbers and up to 5 key findings. Full detail: get_activity_details, analyze_workout_execution, compare_power_streams, analyze_climbs, get_activity_data_audit. Methods: intervals://methods/activity-data, intervals://methods/execution (get_guide). |
| get_fueling_analysisA | Use for carbohydrate, fluid and sodium intake of one activity (activity_id) or of the long sessions of a period (default the last 90 days, sessions of at least min_minutes; read-only). Carbs used (Intervals.icu estimate) and ingested (logged total) in g and g/h, the ingested share of used, kcal and kJ, and fluid intake, sodium and sweat loss per hour where custom fields exist (found by units and name). One activity also gets the intake per hour from a custom intake stream, if there is one. Period: statistics per sport family, by duration and by intensity, Spearman correlations from 8 sessions, with sample sizes. Not logged is never 0; used minus ingested is no 1:1 energy deficit; no targets. Method: intervals://methods/fueling (get_guide). |
| get_recovery_snapshotA | Use for the recovery and readiness context of one day in one call (default today; read-only, numbers only, no readiness verdict). For the day and days_back days before: native wellness values, CTL/ATL/form/ramp rate, subjective scores, custom wellness fields with a value (e.g. Body Battery from a sync bridge), missing values and the record's update time; recorded SICK/INJURED entries; personal baselines of baseline_metrics (7-day and 42-day mean, median, SD, latest value vs baseline with z-score; small samples flagged); the activities of those days with loads and device fields; the planned events of the day. Today is flagged preliminary and a line (JSON today_completeness) names the usual fields not yet in today's record, grouped by when they usually arrive: not yet available, not normal. Trends: get_wellness_trends. Method: intervals://methods/wellness (get_guide). |
| get_wellness_trendsA | Use for multi-day wellness trends against the athlete's own baseline (default the 42 days ending today; read-only, statistics only). Per metric with units: the daily values of the last 14 days with trailing means, period statistics, a personal baseline (the 42 days ending at end_date), the latest value vs that baseline (difference, %, z-score), rolling means, the last 7 days vs the 7 before and outliers (|z| >= 2.5). Missing days are never filled in; for physiological metrics a stored 0 counts as missing. Small samples are flagged (baseline under 14 values, correlation under 30 paired days). Weight adds a 7/14/28-day slope in kg per week. Optional correlations (Pearson, Spearman, with lag) are associations, not causes. One day in context: get_recovery_snapshot. Method: intervals://methods/wellness (get_guide). |
| get_nutrition_summaryA | Use for food intake, calorie balance and weight trend over a period (default the 28 days ending today; read-only). Per day: logged kcal, carbohydrates, protein and fat, the device's total and active burn and balance (custom wellness fields, codes configurable) and weight. Per window (default 7/14/28 days): intake totals and means over logged days only, days without logged intake, burn mean, balance total and mean on logged days, weight change and slope in kg per week. A day without logged intake is never 0 kcal; the device burn is an estimate; a calorie balance does not measure fat change. Optionally the Intervals.icu training load per day. Method: intervals://methods/wellness (get_guide). |
| get_training_summaryA | Use for training totals of a period grouped by ISO week, month, sport (activity type), gear or in total, including custom activity fields (read-only). Per group and in total: sessions, moving/elapsed time, distance, elevation, Intervals.icu load with the power/HR/pace load sums, time-weighted intensity, CTL/ATL/form/ramp at the end of the group's week or month, time in power (sweet spot apart) and HR zones, sport and gear splits, feel and RPE, sessions of 3 h or more, the longest session, trainer sessions. Numeric custom fields are aggregated by units and meaning: additive values summed, device loads summed apart from the Intervals.icu load, estimates as latest value and change, per-activity values as mean/median/range. Missing values are skipped, never counted as 0. Per-week view in one call: get_weekly_summary. Method: intervals://methods/summary (get_guide). |
| get_intensity_distributionA | Use for the training intensity distribution of a period (default the last 4 weeks, read-only): Intervals.icu's time in zones of each activity mapped to the three-zone model (Z1 below the first threshold, Z2 between, Z3 above the second). Returns Z1/Z2/Z3 shares and hours, the polarization index (Treff et al. 2019), the class (Base, Polarized, Pyramidal, Threshold, HIT) and hard sessions and days for the period, per sport family and per ISO week, and the drift between the two halves. The mapping depends on the zone basis and the zone count of the athlete's model. Activities without zone data are never counted as easy; the coverage is reported. Statistics only, no verdict. Overview: get_coach_context. Method: intervals://methods/intensity (get_guide). |
| get_durabilityA | Use for aerobic durability: Intervals.icu's aerobic decoupling (power:HR, or pace:HR for runs without power; drift between the halves in %) of steady long cycling and running sessions and the efficiency factor trend (read-only, default the last 6 weeks). Sessions pass a quality filter (min_minutes moving, few stops, HR, rides with power, variability index up to max_vi, temperature up to max_temp_c, optionally indoor or outdoor only); excluded ones are counted per reason. Per sport family: median, range, quartiles, sessions above drift_threshold_pct (5 % commonly cited) and the last recent_days against the window. Fewer than 8 qualifying sessions are flagged as a small sample; mixed indoor/outdoor, bikes/shoes or power meters are noted. Statistics only, no verdict. Per interval and bike: get_power_hr_efficiency. Method: intervals://methods/durability (get_guide). |
| get_long_ride_fatigue_profileA | Use to see how long rides change at matched power as work accumulates: HR, W/bpm, cadence and Garmin stamina in steady segments of a power band (default 75-85 % FTP) before vs after work thresholds. Phases by work (default 750 / 1,500 kJ, or kJ/kg) are compared with the phase before the first threshold. Threshold crossings and climbs carry the prior work (kJ, kJ/kg, kJ and time above FTP, efforts above FTP). Rides from activity_ids or the long rides of a period (default 180 days, reaching the highest threshold; limit 6, max 12). Across rides: median and range of the changes with n, small samples flagged. Statistics only, no verdict. Read-only; one stream call per ride plus 1-4 (one more per id with activity_ids). Fresh vs fatigued power curves: get_fatigue_resistance. Method: intervals://methods/fatigue (get_guide). |
| get_submax_test_trendsA | Use to follow the submaximal fatigue tests Intervals.icu detects (#SFT) over the weeks: which are valid benchmarks and how HR responds. Lists the tests of the period (default 180 days; limit 30, max 60) with target, average, CV, end HR, efficiency factor and HR recovery (HRRc; not measured is never 0). Valid: on target, steady, not ignored and (check_context) not inside a longer work interval, not continued, not after hard riding; excluded tests carry the reason. Valid tests are trended per sport family and test type (power and pace never pooled) and ISO week: n, change, slope, SD. Statistics only, no verdict. Read-only; 2 API calls plus 2 per power test with check_context. Method: intervals://methods/fatigue (get_guide). |
| get_coach_contextA | Use first for a weekly or general training review: load, intensity, recovery, durability and plan for one end date in one compact call (read-only, about 2-3k characters). Combines 7/28-day Intervals.icu load with acute:chronic ratio, monotony, strain and CTL/ATL/form; the three-zone intensity of 7 and 28 days; recovery markers (HRV, resting HR, sleep) against personal baselines with a z-score; durability; recorded SICK/INJURED entries; top sessions; and, when the end date is today, planned workouts of the next 7 days and the next race. For today it names wellness fields not yet recorded (not yet available, not normal). A method line states windows and rules; small samples are flagged; missing values are never 0; no verdict. Details: get_training_load, get_intensity_distribution, get_durability, get_recovery_snapshot, get_load_projection. Method: intervals://methods/load (get_guide). |
| preview_workoutA | Use to show the athlete how a drafted workout will look before writing it: renders the workout document as Intervals.icu workout text with its totals (no API call, nothing written). Expands repeats, sums planned duration and distance, counts steps with targets and open-ended steps, and shows the text add_or_update_event would send. Full check list: validate_workout. |
| validate_workoutA | Use before every workout write (add_or_update_event, add_events_bulk, create_library_workout) to check a drafted workout document; read-only, nothing is written. Checks durations or distances per step, repeat blocks, target units per sport and plausible values, ramps and ranges, warm-up and cool-down, the step sum against moving_time and the sport; with start_date it lists the events already on that day and flags a same-name event as a possible duplicate. Format: intervals://workout-syntax (get_guide). Show the result to the athlete before writing. |
| get_server_statusA | Use to check the connection when tools are missing or fail: server version, enabled permission classes and tool set, registered and hidden tools, whether Intervals.icu answers, and the athlete's custom field and stream counts. The API key is never shown. |
| get_guideA | Use when the short tool descriptions are not enough: read the workout syntax before writing a workout, or how an analysis works (method, windows, filters, caveats). Returns the same Markdown as the resources intervals://guide, intervals://workout-syntax and intervals://methods/. Static text, no athlete data. |
| get_weekly_summaryA | Use for a quick per-week overview from Intervals.icu's athlete summary (read-only, one API call). Per ISO week (from Monday): sessions, moving time, distance and training load, a split per sport category, time in HR zones (non-zero zones only) and CTL/ATL/form/ramp at the end of the week (the latest day with data for the current week). Sessions without HR (e.g. strength) are counted. Rows of other (followed or coached) athletes are ignored. Grouping by month, sport or gear, separate power/HR/pace loads and custom fields: get_training_summary. Method: intervals://methods/summary (get_guide). |
| get_plan_complianceA | Use to compare planned workouts with the activities done in a date range (read-only, two API calls). Planned workouts (calendar WORKOUT events) are linked to activities by the event's paired_activity_id or the activity's paired_event_id; each pair shows planned vs actual duration and load with the deviation in %. An activity counts for one event only. Unlinked past workouts are missed, those of today or later upcoming (athlete's local date). Activities without a planned workout are unplanned; those linked to a workout outside the range are listed apart. Completion = completed / (completed + missed). NOTE events with training availability, allowed sports or a maximum training time are listed too. Method: intervals://methods/summary (get_guide). |
| get_workout_libraryA | Use to list the athlete's workout library: folders and plans with their workouts and ids (read-only). One workout in detail: get_library_workout. |
| get_library_workoutA | Use to read one library workout (steps, planned time, load, targets), e.g. to reuse it with add_or_update_event or validate_workout. Ids: get_workout_library. |
| get_wellness_dataA | Use for the raw daily wellness records of a date range (default the last 30 days; read-only). Per day as stored: CTL/ATL and eFTP per sport, vitals (weight, resting HR, HRV, SpO2 ...), sleep, subjective scores, nutrition, steps and comments; include_all_fields adds every other field, custom wellness fields labelled with name and units. When the range includes today, a line names the usual fields not yet in today's record, grouped by when they usually arrive: not yet available, not normal. Long ranges are paged by day: a note gives the start_date to continue with. Baselines and trends: get_recovery_snapshot, get_wellness_trends, get_nutrition_summary. Method: intervals://methods/wellness (get_guide). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| recovery_check | Daily recovery check from the wellness snapshot, baselines, recent load and the plan of the day. |
| workout_deep_dive | Full analysis of one activity: plan vs execution, intervals, device metrics, climbs, power meters. |
| weekly_training_review | Review the past training week(s): load, compliance, intensity distribution, recovery. |
| training_load_review | Training load, intensity distribution, durability and the planned load (statistics with sample sizes). |
| performance_progression | Long-term progression: curves, eFTP, best efforts, efficiency and fatigue resistance. |
| long_ride_climbing_analysis | Long ride, tour or mountain hike: climbs, descents, pauses, pacing, stamina, fuelling. |
| nutrition_weight_trend | Nutrition, calorie balance and weight over the last weeks in the context of training load. |
| power_meter_comparison | Compare two power meters recorded on the same activity. |
| workout_planning_validation | Plan and validate structured workouts before they are written to the calendar. |
| race_week | Race-week check: taper and form on race day, remaining sessions, fueling plan from history, weather, logistics. |
| fueling_review | Fueling review of one activity or of the long sessions of the last weeks (carbs, fluid, sodium per hour). |
| plan_health_check | Check the planned weeks: load ramp, monotony, rest days, form, races and plan consistency (what-if, nothing written). |
| coach_handoff | Compact summary for handing the athlete over to another coach or a new session. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| custom_items_resource | The athlete's custom item definitions (codes, names, units, types) as compact JSON. |
| guide_usage | Which tool for which question, recommended call order and conventions. |
| guide_workout_syntax | Structured workout format (workout_doc steps, targets, units, repeats) for the write and validate tools. |
| guide_activity_data | Method guide: activity data (how the analysis works, windows, filters, caveats). |
| guide_execution | Method guide: execution (how the analysis works, windows, filters, caveats). |
| guide_climbs | Method guide: climbs (how the analysis works, windows, filters, caveats). |
| guide_power_meters | Method guide: power meters (how the analysis works, windows, filters, caveats). |
| guide_load | Method guide: load (how the analysis works, windows, filters, caveats). |
| guide_intensity | Method guide: intensity (how the analysis works, windows, filters, caveats). |
| guide_durability | Method guide: durability (how the analysis works, windows, filters, caveats). |
| guide_summary | Method guide: summary (how the analysis works, windows, filters, caveats). |
| guide_comparisons | Method guide: comparisons (how the analysis works, windows, filters, caveats). |
| guide_fatigue | Method guide: fatigue (how the analysis works, windows, filters, caveats). |
| guide_wellness | Method guide: wellness (how the analysis works, windows, filters, caveats). |
| guide_fueling | Method guide: fueling (how the analysis works, windows, filters, caveats). |
TDQS
Scored across 52 tools
There is genuine conceptual overlap among the analysis tools (get_training_summary vs get_weekly_summary, get_training_load vs get_coach_context vs get_load_projection, and the get_wellness_data/get_recovery_snapshot/get_wellness_trends/get_nutrition_summary cluster), and the many activity tools (get_activities, get_activity_report, get_activity_details, get_activity_intervals, get_activity_streams) could be confused at a glance. However, the descriptions are unusually disciplined: they repeatedly state precedence ('Use first for any question about one activity') and name the sibling tool to use instead, so an agent can usually pick correctly. Boundaries are mostly clear, with a handful of overlapping summary/wellness tools as the weak spot.
Names follow a strict verb_noun snake_case convention throughout: get_*, list_*, compare_*, analyze_*, validate_*, preview_*, find_*. Verb choice is meaningful (get for single reads, list for enumerations, compare for cross-entity analysis) and no camelCase or ad-hoc styles appear.
52 tools is very heavy for the surface, and several clusters look consolidatable (weekly vs general training summary; four separate wellness/nutrition readers; multiple overlapping 'review' entry points). The domain is genuinely broad, but the count sits well past the point where an agent can hold the whole set in mind, which the server itself acknowledges by declaring get_activity_report and get_coach_context as 'use first' funnel tools.
The read/analysis surface is extremely thorough (activities, streams, intervals, wellness, nutrition, load, curves, plan, library), so most questions can be answered. But it is a dead-end for mutations: no create/update/delete tools are present, and descriptions reference missing tools (add_or_update_event, add_events_bulk, create_library_workout, update_sport_settings), so a user cannot actually write a workout or change thresholds despite the guidance promising it. That is a notable lifecycle gap rather than a full CRUD surface.