intervals-icu-mcp

Overview Schema Source Related Servers Discussions Admin

Icu Get Activity Streams

icu_get_activity_streams

Read-onlyIdempotent

Retrieve raw per-sample activity streams—power, heart rate, cadence, speed, GPS, altitude, temperature, grade—for visualization or custom analysis, with optional stream filters and point thinning.

Instructions

Fetch RAW per-sample time-series of one activity — second-by-second arrays for power, HR, cadence, speed, altitude, GPS, temperature, grade, etc.

Heavy payload. Use only when you need the underlying signal for visualization or custom analysis. Most "how was my ride?" questions are better answered by get_activity_details (summary metrics) or get_activity_intervals (per-lap breakdown).

Stream-type filter accepts any of: watts, heartrate, cadence, velocity_smooth, altitude, distance, time, latlng, temp, moving, grade_smooth, raw_heartrate, fixed_heartrate.

latlng comes back as [lat, lng] pairs (null where the sample has no GPS fix).

left_right_balance (dual-sided power meters) is the RIGHT pedal's share of power in percent (FIT convention), not the left's: a stream averaging 48 means L 52% / R 48%. The response adds a stream_notes entry saying so whenever the stream is returned.

heartrate is CORRECTED data: Intervals.icu replaces readings above the athlete's configured max HR with an interpolated line at import, so it can never exceed that setting. raw_heartrate is the uncorrected trace and is the only way to see a genuine new max that was clipped away — the platform never raises the setting on its own. Request it explicitly; it is not in the default set.

Input Schema

Name	Required	Description
`streams`	No	List of stream types (e.g., ['watts', 'heartrate', 'cadence']). If not specified, the activity's default streams are fetched — which does NOT include raw_heartrate or fixed_heartrate; ask for those by name.
`max_points`	No	Thin every returned stream to at most this many samples by keeping every Nth one (the same N for all streams, so indices stay aligned). Omit for full resolution. ~500 is plenty to trace a route or see the shape of a ride. Samples are not always 1 s apart, so include 'time' to know when each kept sample was recorded.
`activity_id`	Yes	Activity ID to fetch streams for

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv5.4.0Sep 30, 2026

addedInput schema / properties / max_points

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Thin every returned stream to at most this many samples by keeping every Nth one (the same N for all streams, so indices stay aligned). Omit for full resolution. ~500 is plenty to trace a route or see the shape of a ride. Samples are not always 1 s apart, so include 'time' to know when each kept sample was recorded."
+}

Changed1 schema field changedv5.0.1Sep 11, 2026

changedInput schema / properties / streams / description

Previous value: -"List of stream types (e.g., ['watts', 'heartrate', 'cadence']). If not specified, all streams are fetched."New value: +"List of stream types (e.g., ['watts', 'heartrate', 'cadence']). If not specified, the activity's default streams are fetched — which does NOT include raw_heartrate or fixed_heartrate; ask for those by name."

First observedv0.1.0May 19, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the read-only annotations, the description discloses important behavior: heavy payload size, raw versus corrected heart-rate data, latlng null handling, left/right balance FIT convention, and a stream_notes caveat returned with the response. These details materially affect how an agent should interpret and request the data.

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

Conciseness5/5

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

The description is long but appropriately so for a complex raw-data tool. It is front-loaded with the core purpose, then follows with usage guidance, the accepted stream list, and targeted caveats; every paragraph adds actionable information.

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?

Given the output schema and annotations, the description supplies everything an agent needs to decide whether to call the tool, choose streams, and interpret special cases. The main behavioral risks around payload size, default streams, and corrected heartrate are all covered.

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

Parameters5/5

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

Although schema coverage is already 100%, the description adds substantial semantic value: it lists accepted stream types, explains that default streams exclude raw_heartrate and fixed_heartrate, documents latlng as [lat, lng] pairs with nulls, and clarifies the right-pedal convention for left_right_balance. It also warns about corrected heartrate versus raw_heartrate, which is essential for correct parameter selection.

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?

The description uses a specific verb and resource: fetch raw per-sample time-series for one activity, with second-by-second arrays for power, HR, cadence, and related signals. It explicitly distinguishes this from sibling tools by naming get_activity_details for summary metrics and get_activity_intervals for per-lap breakdown.

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?

It states when to use the tool (visualization or custom analysis of the underlying signal) and when not to use it (most ride-summary questions should use get_activity_details or get_activity_intervals). It also warns that the payload is heavy and gives practical guidance about default versus explicitly requested streams.

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

Deploy Server