intervals-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| INTERVALS_ICU_API_KEY | Yes | API key for intervals.icu. Grants full read/write access to your account. | |
| INTERVALS_ICU_ATHLETE_ID | No | Athlete ID. Defaults to '0' (the account the key belongs to). Set only when working with another athlete's data. |
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 |
|---|---|
| check_connectionA | Verifies the connection and fetches the athlete's threshold values. Run this before building a workout. FTP, threshold heart rate and zone boundaries come from the account, so intensities are computed against the right numbers instead of a guess. |
| upload_blockA | Puts a block of planned workouts in the intervals.icu calendar. From there the workouts sync to Zwift (Workouts -> Custom -> Intervals.icu) and Garmin. Write the block name, the workout names and the descriptions in ENGLISH, even when talking to the user in another language. The calendar, Zwift and Garmin are English, and these workouts outlive the conversation. After the upload, the server's interpretation of each workout is compared with the duration you stated. That catches DSL mistakes that would otherwise be silent — above all nested repeats, which make the workout shorter than intended without the server complaining. Read the warnings: a workout can upload without errors and still be wrong. Re-run with the same block_name to correct; it creates no duplicates. |
| list_blockA | Shows workouts this server has put in the calendar during a period. Shows only its own workouts. Anything you added by hand, imported, or got from a coach is invisible here — and cannot be deleted by delete_block either. |
| delete_blockA | Removes a block from the calendar. Deletes only workouts this server created under the given block name. Workouts you added yourself, imported, or that belong to another block cannot be hit. |
| export_blockA | Downloads an uploaded block as workout files. The workouts must be in the calendar first — run upload_block before. The files are an alternative to the intervals.icu integration, useful when Zwift runs on a device where the integration is unavailable. .zwo files are used in Zwift by placing them under Documents/Zwift/Workouts// and appear under Workouts -> Custom. |
| review_periodA | Reviews planned versus actual training in a period. Shows this server's planned workouts with their outcome — the paired activity and its server-computed compliance — flags missed workouts, and lists every other activity in the window: spontaneous rides and foreign plans count toward load all the same. Defaults to the last 7 days. The numbers are reported, not interpreted — the judgement about what they mean for the next block is yours. Use get_activity for the per-interval detail of one ride, get_fitness for the CTL/ATL/form trend. |
| get_activityA | Fetches one completed activity with its intervals. The per-rep actuals — watts, heart rate, cadence per detected interval — for checking how a structured workout actually went. Run review_period first to find the activity id. |
| get_fitnessA | Shows the fitness trend: CTL, ATL and form (TSB) per day. Form is computed here as CTL − ATL — intervals.icu exposes no form field. Defaults to the last 28 days. The trend says whether the athlete is peaking or digging a hole; what to do about it is the caller's judgement. |
| get_power_curveA | Shows the athlete's power curve — best average power per duration. The strength profile of a cyclist: best 5 s, 1 min, 5 min, 20 min and longer efforts over the period, in watts and W/kg. Downsampled to the classic durations; the raw curve carries one point per second. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| workout_syntax | The complete syntax for intervals.icu workout descriptions. Read this before writing a workout. It covers how duration, power, heart rate, cadence, ramps and repeats are written — and the one trap that fails silently. |
TDQS
Scored across 9 tools
Each tool has a clearly distinct purpose: connection check, block upload/list/delete/export, fitness trend, power curve, period review, and activity details. The descriptions further clarify any potential overlap, such as upload vs. export or review_period vs. get_activity.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: check_connection, upload_block, list_block, delete_block, get_fitness, get_power_curve, export_block, review_period, get_activity. There are no deviations or mixed conventions.
With 9 tools, the server is well-scoped. Each tool covers a distinct aspect of the workout planning and analysis workflow, and the count is within the ideal 3-15 range.
The tool surface covers the full lifecycle from connection verification and threshold fetching to uploading, listing, deleting, exporting blocks, reviewing period performance, and fetching activity details. A minor gap is the lack of a dedicated tool to retrieve a single workout's planned structure without exporting the entire block, but this is workable.