intervals-icu-mcp

Overview Schema Source Related Servers Discussions Admin

icu_update_sport_settings

Idempotent

Update an athlete's sport thresholds and zones—FTP, FTHR, pace, swim, and explicit HR/power zones—so new lab or field values apply to future training; past activities keep original zones.

Instructions

Update sport settings: FTP, FTHR, pace/swim thresholds, or explicit HR/power zones.

Explicit zones replace the threshold-derived ones (e.g. to match a lab test). Changes apply from now on; past activities keep the zones they were analysed with.

Input Schema

TableJSON Schema

Name	Required	Description
`ftp`	No	Functional Threshold Power in watts (for cycling)
`fthr`	No	Functional Threshold Heart Rate in bpm
`max_hr`	No	Max HR in bpm. Optional with hr_zones (taken from the last bound); if sent, it must equal that bound
`hr_zones`	No	Explicit HR zone upper bounds in bpm, strictly increasing (e.g. lab VT1/VT2). The last bound is the max HR: Intervals.icu sets max_hr to it
`sport_id`	Yes	ID of the sport settings to update
`athlete_id`	No	Athlete ID (for coaches managing multiple athletes)
`indoor_ftp`	No	Indoor Functional Threshold Power in watts (for cycling)
`hr_zone_names`	No	One name per hr_zones bound
`pace_threshold`	No	Threshold pace in min/km (e.g., 4.5 for 4:30/km)
`sweet_spot_max`	No	Sweet spot upper bound, % of FTP
`sweet_spot_min`	No	Sweet spot lower bound, % of FTP
`swim_threshold`	No	Swim threshold in min/100m (e.g., 1.5 for 1:30/100m)
`recalc_hr_zones`	No	Rescale HR zones when fthr changes. Explicit lab zones are rescaled too; pass false to keep them. Zones sent in the same call are kept either way
`power_zone_names`	No	One name per power_zones_percent_ftp bound
`power_zones_percent_ftp`	No	Explicit power zone upper bounds as % of FTP (not watts), strictly increasing, each <= 200; a final 999 makes the top zone open-ended

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv5.4.0Sep 30, 2026

changedInput schema / properties / hr_zones / description

Previous value: -"Explicit HR zone upper bounds in bpm, strictly increasing (e.g. lab VT1/VT2). The last bound becomes max_hr"New value: +"Explicit HR zone upper bounds in bpm, strictly increasing (e.g. lab VT1/VT2). The last bound is the max HR: Intervals.icu sets max_hr to it"

changedInput schema / properties / max_hr / description

Previous value: -"Max HR in bpm; must equal the last hr_zones bound"New value: +"Max HR in bpm. Optional with hr_zones (taken from the last bound); if sent, it must equal that bound"

changedInput schema / properties / power_zones_percent_ftp / description

Previous value: -"Explicit power zone upper bounds as % of FTP (not watts), strictly increasing; 999 as the last value makes the top zone open-ended"New value: +"Explicit power zone upper bounds as % of FTP (not watts), strictly increasing, each <= 200; a final 999 makes the top zone open-ended"

Changed8 schema fields changedv5.2.0Sep 24, 2026

addedInput schema / properties / hr_zone_names

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "One name per hr_zones bound"
+}

addedInput schema / properties / hr_zones

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Explicit HR zone upper bounds in bpm, strictly increasing (e.g. lab VT1/VT2). The last bound becomes max_hr"
+}

addedInput schema / properties / max_hr

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Max HR in bpm; must equal the last hr_zones bound"
+}

addedInput schema / properties / power_zone_names

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "One name per power_zones_percent_ftp bound"
+}

addedInput schema / properties / power_zones_percent_ftp

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Explicit power zone upper bounds as % of FTP (not watts), strictly increasing; 999 as the last value makes the top zone open-ended"
+}

changedInput schema / properties / recalc_hr_zones / description

Previous value: -"Recalculate HR zones from the updated threshold heart rate"New value: +"Rescale HR zones when fthr changes. Explicit lab zones are rescaled too; pass false to keep them. Zones sent in the same call are kept either way"

addedInput schema / properties / sweet_spot_max

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Sweet spot upper bound, % of FTP"
+}

addedInput schema / properties / sweet_spot_min

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Sweet spot lower bound, % of FTP"
+}

Changed1 schema field changedv5.0.1Sep 11, 2026

addedInput schema / properties / athlete_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Athlete ID (for coaches managing multiple athletes)"
+}

Changed2 schema fields changedv4.2.0Jul 11, 2026

addedInput schema / properties / indoor_ftp

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Indoor Functional Threshold Power in watts (for cycling)"
+}

addedInput schema / properties / recalc_hr_zones

Added value: +{
+  "default": true,
+  "description": "Recalculate HR zones from the updated threshold heart rate",
+  "type": "boolean"
+}

First observedv0.1.0May 19, 2026

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish the safety profile (readOnly=false, destructive=false, idempotent=true). The description adds genuinely non-structured behavior: explicit zones override threshold-derived ones, changes are forward-only, and past activities retain their original zone analysis. That temporal scope is the key thing an agent needs before a config mutation, and it is absent from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with no filler; the affected fields are listed first and the forward-only behavior is front-loaded in sentence two. It is appropriately sized for the operation, though it omits the coach/athlete_id context that a 15-parameter tool with multi-athlete support arguably warrants.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and annotations carry the safety profile; the description correctly spends its budget on the destructive-adjacent caveat that past activities are unaffected. All parameters are covered in the schema at 100%. The only real gap is usage routing against sibling settings tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each of the 15 parameters is already richly documented, including the max_hr/hr_zones coupling and the recalc_hr_zones rescaling rule. The description only restates parameter categories and adds the one semantic note about explicit zones superseding derived zones, which is close to baseline credit when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Update) plus the resource (sport settings) and enumerates the domains affected: FTP, FTHR, pace/swim thresholds, HR/power zones. An agent immediately knows this mutates threshold/zone configuration. It never names or contrasts with siblings like icu_get_sport_settings or icu_apply_sport_settings, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (setting thresholds or supplying explicit lab-derived zones) and gives one concrete motivation ("to match a lab test"). However it names no alternative tool and gives no when-not guidance, e.g. that reading current settings requires icu_get_sport_settings or that icu_apply_sport_settings exists as a separate path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server