Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Futureweb Intervals MCP

OCI · GHCR.IO/FUTUREWEB/INTERVALS-MCP-SERVER · 2 COMPONENTS

Self-hosted Intervals.icu MCP server: training analytics, Garmin data, wellness, workout planning

+4 this week 45 Trust /100

Last scanned (22 hours ago)

Scores higher than 62% of OCI servers

Category Health and Science

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security0
  • No malware scan is available for this kind of package: the supply-chain vendors we use do not cover it. This is a permanent gap in our coverage, not a finding about the package.Unverified
  • Known CVEs could not be checked: this artifact ships no SBOM or dependency manifest, so there is no dependency list to read.Unverified
  • Install-script risk not yet assessed.Unverified
  • Dependency health could not be checked: this artifact ships no SBOM or dependency manifest, so there is no dependency list to read.Unverified
Provenance & Transparency48
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
  • Clear OSI-approved license (GPL-3.0-only).Pass
  • Actively maintained (last published 7 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability74
  • 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
  • AI-judged instruction clarity (good).Pass
  • Context-footprint check failed: tool/resource definitions use about 16210 tokens (~241/item across 67 items; 52 tools + 15 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management27
  • Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 52 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 54 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass

Unverified: 1 category

A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 23 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

  • 21 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

  • 19 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

  • 17 Oct 26 +1
    • Stability: unverified → 0.07 ▲ functional
  • 15 Oct 26 +31
    • Injection markers: unverified → pass ▲ security
    • First check of Judged manipulation: pass security
    • Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window). security
    • Tool coverage: unverified → 100 ▲ functional
    • Schema quality: unverified → 100 ▲ functional
    • MCP protocol: unverified → pass ▲ functional
    • First check of Schema quality: fail functional
    • First check of Destructive annotations: pass functional
    • First check of Schema quality: fail functional
    • First check of Schema quality: good functional
    • First check of Tool coverage: 100 functional
    • Package version: 1.0.0b1 → 1.0.0b2 functional
  • 12 Oct 26 10

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 23 Oct 2026 · Analysed oci/ghcr.io/futureweb/intervals-mcp-server@1.0.0b2

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem oci
Reason No attestation published

Background: How many MCP packages publish verified provenance →

MCP tools · 52 exposed · ~15,538 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
get_training_zones ~186

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.

NameTypeReqDescription
athlete_idstring–Default: the configured athlete
output_formatstring–json = machine-readable, all fields
refreshboolean–Re-fetch the sport settings instead of using the 10-minute cache
sport_typestring–Only the setting that covers this activity type, e.g. "Run"; default all
zone_typestring–Zone kind; all = power, HR and pace

No output schema declared.

No examples provided.

get_weekly_summary ~194

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).

NameTypeReqDescription
athlete_idstring–Default: the configured athlete
end_datestringyesLast day YYYY-MM-DD
start_datestringyesFirst day YYYY-MM-DD

No output schema declared.

No examples provided.

get_wellness_data ~258

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).

NameTypeReqDescription
athlete_idstring–Default: the configured athlete
end_datestring–Last day YYYY-MM-DD; default today
include_all_fieldsboolean–Also list every other field, custom wellness fields with name and units
start_datestring–First day YYYY-MM-DD; default 30 days before the earlier of end_date and today

No output schema declared.

No examples provided.

get_wellness_trends ~383

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).

NameTypeReqDescription
athlete_idstring–Default: the configured athlete
correlationsstring–Comma-separated pairs "a:b" or "a:b:lag_days" (b lag days later), e.g. "hrv:readiness,restingHR:sleepScore:1"
end_datestring–Last day YYYY-MM-DD; default today
metricsstring–Comma-separated, at most 16: native codes (hrv, restingHR, weight, ctl ...), custom field codes, eftp_<Type>
output_formatstring–json = machine-readable, all fields
start_datestring–First day YYYY-MM-DD; default 41 days before end_date (42 days)
windowsstring–Comma-separated rolling windows in days, 2-365

No output schema declared.

No examples provided.

get_workout_library ~75

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.

NameTypeReqDescription
athlete_idstring–Default: the configured athlete
folderstring–Only this folder or plan: name (case-insensitive) or id

No output schema declared.

No examples provided.

list_activity_streams ~167

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).

NameTypeReqDescription
activity_idstringyesActivity id, e.g. i123456789
include_statsboolean–Also download the streams for sample counts and start/end/min/max/mean per stream

No output schema declared.

No examples provided.

preview_workout ~168

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.

NameTypeReqDescription
moving_timeinteger–Expected moving time in seconds, compared with the step sum
output_formatstring–json = machine-readable, all fields
workout_docobjectyesWorkout document with steps, as for add_or_update_event. Format: intervals://workout-syntax
workout_typestring–Sport of the workout, e.g. Ride, GravelRide, Run

No output schema declared.

No examples provided.

validate_workout ~273

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.

NameTypeReqDescription
athlete_idstring–Default: the configured athlete
check_calendarboolean–Look up the events already on start_date
moving_timeinteger–Expected moving time in seconds, compared with the step sum
namestring–Planned event name, for the duplicate check
output_formatstring–json = machine-readable, all fields
start_datestring–Planned day YYYY-MM-DD, for the calendar check
workout_docobjectyesWorkout document with steps, as for add_or_update_event. Format: intervals://workout-syntax
workout_typestringyesSport of the workout, e.g. Ride, GravelRide, Run, Swim

No output schema declared.

No examples provided.

Install

How do I install the Futureweb Intervals MCP server?

Futureweb Intervals MCP runs locally as a container image, launched with docker run --rm -i -e API_KEY -e ATHLETE_ID -e MCP_PERMISSIONS -e MCP_TOOLSET -e ATHLETE_TIMEZONE ghcr.io/futureweb/intervals-mcp-server:1.0.0b2. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation.

oci · ghcr.io/futureweb/intervals-mcp-server

# add to Claude Code
claude mcp add futureweb-intervals-mcp-server -- docker run --rm -i -e API_KEY -e ATHLETE_ID -e MCP_PERMISSIONS -e MCP_TOOLSET -e ATHLETE_TIMEZONE ghcr.io/futureweb/intervals-mcp-server:1.0.0b2

This image reads API_KEY, ATHLETE_ID, MCP_PERMISSIONS, MCP_TOOLSET and ATHLETE_TIMEZONE. Set them in your client's env block for this server; docker run -e passes each one through to the container.

Common questions

What is the Futureweb Intervals MCP server?

Futureweb Intervals MCP is listed in the public MCP registry as io.github.futureweb/intervals-mcp-server. Self-hosted Intervals.icu MCP server: training analytics, Garmin data, wellness, workout planning. This page covers its container image (ghcr.io/futureweb/intervals-mcp-server).

Is the Futureweb Intervals MCP server safe to use?

Futureweb Intervals MCP scores 45 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Futureweb Intervals MCP server expose?

Futureweb Intervals MCP exposes 52 tools: get_gear_list, get_gear_details, get_athlete_profile, get_sport_settings, get_training_zones, and 47 more. Their descriptions and schemas cost roughly 15,538 tokens of context every time the server is loaded.

Is the Futureweb Intervals MCP server still maintained?

Futureweb Intervals MCP is still listed as active in the MCP registry. We last reached this channel on 23 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the Futureweb Intervals MCP server under?

Futureweb Intervals MCP declares the GPL-3.0-only licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.