intervals-icu-mcp

Overview Schema Source Related Servers Discussions Admin

Icu Get Activity Window Stats

icu_get_activity_window_stats

Read-onlyIdempotent

Compute per-window summary statistics for one activity to compare HR, power, and ventilation drift across fixed blocks or custom ranges, optionally filtering by power, without returning raw streams.

Instructions

Compute exact SUMMARY statistics of one activity per time WINDOW (every N minutes, N equal parts, or explicit ranges) on the server, without returning raw streams.

Use for drift questions: "how did HR/power and ventilation/power develop over the ride?", "compare 15-min blocks, ignoring everything below 120 W". Prefer this over icu_get_activity_streams for any averaging; use icu_get_activity_intervals for the activity's own laps.

Each window has icu — computed by Intervals.icu on the whole window (avg/NP watts, HR, decoupling, breath rate, ventilation, tidal volume, DFA a1, plus hr/ve/br per watt) — and, when streams or a power filter is given, filtered — mean/median/min/max computed here on samples passing the filter, plus _per_watt. analysis adds Intervals.icu's whole-ride Pw:HR decoupling and each ratio's drift vs the first window.

Breath rate comes from Tyme Wear (measured), else the HRV app (custom stream on FIT field RespirationRate), else the recording device (head unit/watch, device names it); the last two are HR-derived estimates — breath_rate_source says which and whether it was measured. Aliases: VE -> tidal_volume_min, VT -> tidal_volume, BR -> respiration (or the HRV stream). Missing streams are reported with suggestions.

Input Schema

Name	Required	Description
`lag_s`	No	In `filtered`, pair power at t with the other streams at t+lag_s (HR lags power ~15-30 s)
`parts`	No	Split the activity into this many equal parts
`streams`	No	Extra streams to compute here (mean/median/min/max and per-watt ratio), e.g. ['VE', 'BR', 'TymeVentilation']. Custom names are case-sensitive.
`windows`	No	Explicit windows as [[start_s, end_s], ...] in elapsed seconds. Give one of block_minutes / parts / windows; none = whole activity.
`max_power`	No	Drop samples above this power (surges) from `filtered`
`min_power`	No	Drop samples below this power (coasting/stops) from `filtered`
`activity_id`	Yes	Activity ID
`block_minutes`	No	Split the activity into consecutive blocks of this many minutes
`power_smoothing_s`	No	Apply min/max_power to the trailing N-second mean power instead of raw 1-s power

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv5.9.1Nov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial context: computation happens on the server, no raw streams are returned, output is split into `icu`, `filtered` and `analysis` sections, and missing streams are reported with suggestions. The breath-rate provenance chain (Tyme Wear measured vs HR-derived estimates) and the `breath_rate_source` flag are exactly the kind of behavior an agent cannot infer from structured fields.

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 the core definition and the sibling routing, then output structure, then caveats. The breath-rate paragraph and alias list are dense but each carries information an agent needs to interpret results. Minor cost: the output-section explanation runs long for a tool that ships an output schema.

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?

For a 9-parameter analytical tool with nested window shapes and filtered statistics, the description covers what is computed where (`icu` vs `filtered` vs `analysis`), how windows are chosen, and how missing or aliased streams behave. Nothing an agent needs in order to call it correctly or interpret the response 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 baseline is 3, but the description adds real meaning: the mutual exclusivity of block_minutes / parts / windows and the default of whole-activity when none is given, plus the lag between power and other streams and the stream-name aliases (VE, VT, BR). It does not restate every parameter, but the non-obvious interactions are covered.

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 specific verb and resource: compute summary statistics of one activity per time window, server-side, without returning raw streams. It explicitly differentiates from two siblings (icu_get_activity_streams for raw/averaging, icu_get_activity_intervals for laps), so an agent can route correctly without reading either schema.

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 concrete use cases (drift questions, comparing 15-min blocks while ignoring sub-120 W) and explicit alternatives: prefer this over icu_get_activity_streams for any averaging, use icu_get_activity_intervals for the activity's own laps. When-to-use and when-not-to-use are both present.

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

Deploy Server