Skip to main content
Glama
Sign In
intervals-icu-mcp

intervals-icu-mcp

by hhopke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Icu Get Power Curves

icu_get_power_curves
Read-onlyIdempotent

Fetches best sustained power and W/kg across durations from 5 seconds to 6 hours for a chosen training window, enabling FTP estimation, peak-power tracking, and durability analysis.

Instructions

Fetch the power-vs-duration curve — best (highest) sustained watts and W/kg across durations from 5s up to 6h, aggregated over the chosen window.

Use for FTP estimation, peak-power tracking, durability, strengths/weaknesses across duration profiles. Includes fitted power models (CP, W', Pmax, FTP), the VO2max estimate and MAP when Intervals.icu provides them. Pick ONE window: days_back, time_period, start_date/end_date, season, or periods (to compare several, e.g. ['s0', 's1', 'all']). Default is the last 90 days. For time-in-zone distribution within a single activity, use icu_get_power_histogram instead.

Input Schema

NameRequiredDescriptionDefault
seasonNoSeason curve ID from icu_get_seasons: 's0' = current, 's1' = previous
periodsNoCompare up to 5 periods in one call; each is week/month/year/all, '<N>d', a season ID ('s1'), or 'YYYY-MM-DD..YYYY-MM-DD'. Returns one entry per period.
end_dateNoRange end (YYYY-MM-DD), inclusive
days_backNoNumber of days to analyze (optional)
athlete_idNoAthlete ID (for coaches managing multiple athletes)
full_curveNoAlso return all points the API returns (secs + watts), not just key durations
sport_typeNoSport type (e.g., Ride, Run, Swim, VirtualRide)Ride
start_dateNoRange start (YYYY-MM-DD); use with end_date (defaults to today)
time_periodNoTime period shorthand: 'week', 'month', 'year', 'all' (optional)

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv5.8.0
    • addedInput schema / properties / end_date
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Range end (YYYY-MM-DD), inclusive"
+}
    • addedInput schema / properties / full_curve
      Added value: +{
+  "default": false,
+  "description": "Also return all points the API returns (secs + watts), not just key durations",
+  "type": "boolean"
+}
    • addedInput schema / properties / periods
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Compare up to 5 periods in one call; each is week/month/year/all, '<N>d', a season ID ('s1'), or 'YYYY-MM-DD..YYYY-MM-DD'. Returns one entry per period."
+}
    • addedInput schema / properties / season
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Season curve ID from icu_get_seasons: 's0' = current, 's1' = previous"
+}
    • addedInput schema / properties / start_date
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Range start (YYYY-MM-DD); use with end_date (defaults to today)"
+}
  2. Changed1 schema field changedv5.0.1
    • addedInput schema / properties / athlete_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Athlete ID (for coaches managing multiple athletes)"
+}
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description's job is added context, which it delivers: the mutual-exclusivity rule for window parameters, the 90-day default, and the fact that fitted models (CP, W', Pmax, FTP), VO2max and MAP are included when available. It does not mention result size, rate limits, or what happens if multiple windows are supplied.

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?

Front-loaded with what the tool returns, then usage, then window selection, then the sibling exclusion — a sensible order with no filler. The middle sentences run a bit long, but every clause carries meaning.

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

Completeness5/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 spelled out, and the description still summarizes the payload shape (sustained watts/W/kg plus fitted models and VO2max/MAP). For a nine-parameter, all-optional read tool, nothing an agent needs in order to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the either/or relationship among days_back, time_period, start_date/end_date, season and periods, and by showing a multi-period example (['s0', 's1', 'all']). It does not mention sport_type or full_curve, but those are well documented in the schema.

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

Purpose5/5

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

States a concrete verb and resource plus scope: 'power-vs-duration curve — best (highest) sustained watts and W/kg across durations from 5s up to 6h, aggregated over the chosen window.' It also distinguishes itself from the nearest lookalike by naming icu_get_power_histogram as the tool for in-activity distribution.

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

Usage Guidelines5/5

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

Gives explicit use cases (FTP estimation, peak-power tracking, durability, strengths/weaknesses) and an explicit exclusion routing to icu_get_power_histogram. It also states the selection rule among window parameters — 'Pick ONE window' — and that the default is the last 90 days.

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

Deploy Server

Other Tools