<p align="center"><img src="https://raw.githubusercontent.com/futureweb/intervals-mcp-server/main/docs/assets/icon-futureweb-128.png" alt="Futureweb Intervals MCP icon" width="128" height="128"></p>

Futureweb Intervals MCP

Advanced Intervals.icu MCP server for ChatGPT, Claude and every MCP client: Garmin-enriched metrics, every custom field and stream, recovery insights and endurance performance analysis.

<!-- MCP Registry ownership proof for the PyPI package; keep on its own line. --> <!-- mcp-name: io.github.futureweb/intervals-mcp-server -->

A Model Context Protocol server that lets AI assistants read and analyse your Intervals.icu training data the way a coach would: activities with every custom field and stream, intervals, wellness against personal baselines, thresholds and zones, planned-versus-executed workouts, climbs, dual power meters, best efforts, efficiency and fatigue resistance, nutrition and weight, training summaries and the calendar. It runs where you run it, talks only to the Intervals.icu API and exposes nothing that writes unless you enable it.

Continuation of mvilanova/intervals-mcp-server. The original project is no longer actively developed (last commit on 2 August 2026, 29 pull requests left open). This community-maintained fork carries it on: the useful open pull requests were reviewed and merged with their authors credited, the bugs fixed, and the server rebuilt around coaching analysis, Garmin data and safe remote access. Not affiliated with Intervals.icu or Garmin.

Companion project: the Garmin Intervals Bridge puts back the metrics Garmin strips from the files it sends to Intervals.icu (stamina, training effect, recovery time, VO₂max, running dynamics, sleep and HRV details …). This MCP is built to read all of it, but works just as well without the bridge.

Contents

• Highlights
• Works with the Garmin Intervals Bridge
• Tools
• Quick start
• Route-aware outdoor workouts
• Connect an AI client
• Sharing the server with friends
• Configuration
• Permissions and security
• Project status and roadmap
• Documentation
• Development
• Credits and license

Highlights

• Every custom item, resolved dynamically. Custom activity fields, interval fields, streams and wellness fields are read from your own definitions and reported with name, code, value and units. Nothing device-specific is hard-coded; null, NaN, zero and absent stay distinct, fields that do not belong to the sport are kept apart, and device loads are never mixed with the Intervals.icu load.
• Streams at full resolution. Any stream as summary, CSV or JSON, sliced by index or time, downsampled and paged, plus per-interval statistics of any stream (for example the stamina drop of each interval).
• Coaching analysis instead of raw dumps. One-call activity report, planned versus executed per step (also for deleted events and rides extended beyond the plan), climbs and descents, second power meter check, best efforts, similar intervals, repeated workouts over time, power-to-heart-rate efficiency, fatigue resistance, training load (acute:chronic ratio, monotony, strain), three-zone intensity distribution with polarization index, aerobic durability, load projection over the plan, recovery snapshot with 42-day baselines, wellness trends and correlations, nutrition and weight trends, weekly and monthly summaries. Statistics with their sample sizes; the interpretation stays with the coach.
• Token-efficient. detail_level (compact, standard, full) and output_format="json" on the heavy tools, a compact tool catalogue (about 23k tokens for read and write, an optional core set of about 10k), 13 ready-made coaching prompts and method guides as MCP resources and through get_guide.
• Safe remote access. Built-in OAuth 2.1 server with "Continue with Intervals.icu" sign-in, a consent page with per-connection permissions, client metadata documents with private_key_jwt (ChatGPT), PKCE and RFC 9207. Streamable HTTP (/mcp) and SSE from one process.
• Safe, verifiable writes. Workouts are validated before they are written, dry_run shows the exact request, a second identical event on the same day is refused, and every write reads back what Intervals.icu stored and parsed.
• Route-aware outdoor workouts. Steps that end on the lap button (until_lap_press) let you start the next interval where the road suits it, e.g. at the foot of a climb, while the work steps stay timed. Confirmed on a Garmin Edge 1040 on the bike (see below).
• Read-only by default. Tools are grouped into permission classes (read, write, destructive, admin) enforced on the server; only read is active unless you enable more.
• Tested. More than 1,100 tests on synthetic data, ruff, mypy, CodeQL, pinned GitHub Actions, build and Docker smoke tests on every pull request.

Works with the Garmin Intervals Bridge

Garmin device ──► Garmin Connect ──► official sync ──► Intervals.icu activity (filtered FIT)
                        │                                     ▲
                        └── Garmin Intervals Bridge ──────────┘  restores custom fields, streams, wellness
                                                              │
                                              Futureweb Intervals MCP (this project)
                                                              │
                                                 ChatGPT / Claude / any MCP client

The Garmin Intervals Bridge writes the metrics Garmin filters out into the custom activity fields, custom streams and wellness fields you defined in Intervals.icu. The MCP reads those definitions at run time, so every restored value shows up in the tools automatically:

| Restored by the bridge | Where the MCP shows it | | --- | --- | | Training effect, EPOC, Garmin training load, recovery time, VO₂max, performance condition, stamina start/end, sweat loss, temperatures | get_activity_details, get_activity_report, get_training_summary, get_training_load (device loads apart from the Intervals.icu load), get_fueling_analysis (sweat loss per hour), get_activity_data_audit (which fields still hold a zero placeholder or no value) | | Stamina and potential stamina, second power meter, grade-adjusted speed, gear selection, running dynamics streams | get_activity_streams, get_activity_intervals, analyze_workout_execution, analyze_climbs, compare_power_streams | | Night SpO₂, respiration, sleeping HR, HRV details, Body Battery, sleep stages and stress, readiness, nutrition | get_wellness_data, get_recovery_snapshot, get_wellness_trends, get_nutrition_summary |

The MCP never contacts Garmin; the bridge is optional and other devices or sync tools that fill custom items get the same treatment. Worked examples and notes on reading the device metrics correctly: docs/GARMIN_BRIDGE.md.

Tools

67 tools; 52 of them only read. Write tools are marked ✎ (write), ✖ (destructive) or ⚙ (admin) and are hidden unless their class is enabled. Most tools accept output_format="json" and detail_level (compact first). Tools never take an API key: credentials come only from the server environment.

The catalogue is kept small for the AI client: short descriptions that say when to use a tool, a description and (where the values are fixed) an enum for every parameter, and text results without a duplicate structured copy. Method details and the workout format live in MCP resources (intervals://methods/<topic>, intervals://workout-syntax) and in get_guide(topic) for clients that only call tools. tools/list is about 22.7k tokens at MCP_PERMISSIONS=read,write (was 42.0k; cl100k); see Tool sets for a smaller set.

Activity analysis

| Tool | What it does | | --- | --- | | get_activity_report | Complete analysis in one call: overview with fueling (carbs used/ingested per hour, sweat loss, energy), weather (temperature, feels-like, wind, head/tailwind share) and W′ balance (max depletion, time below 75/50/25 % of W′), plan vs execution or intervals, second power meter check, climbs, data-quality notes (source, upload and analysis times, recording stops, zero placeholders); include_route_history compares earlier activities on the same Intervals.icu route (time, power, W/kg, HR, weather, stamina); detail_level compact (core numbers, one context line and key findings, about 2-2.5k characters), standard or full | | get_activity_data_audit | Provenance and data quality of one activity: source and file (Garmin sync, Garmin export or bridge upload, Strava stub), upload and analysis times, filtered duplicates, recording stops and gaps, FIT laps vs intervals and manual edits, device and sensor identity, streams usual for the sport but missing, per-stream coverage, custom fields with value / zero placeholder / none and what the Garmin Intervals Bridge could fill; without an activity, the per-sport data coverage of a period | | analyze_workout_execution | Planned vs executed per step (duration, target adherence, time in range, HR response, fade, Pw:HR drift with the Intervals.icu decoupling sign, stamina). A step may span any number of laps; with device auto-laps step boundaries inside laps are placed at the intensity change (lap presses are kept), steps without a lap of their own are found between their neighbours, and a caveat with alignment_confidence says how far per-step results can be trusted. Open-ended targets (top zone) are lower bounds, distance steps are compared on distance. Steps are capped at their planned duration, longer intervals are split for the analysis, and ridin