Intervals.icu MCP Server

get_athlete_power_curves

Retrieve best power outputs for an athlete across specified durations and date ranges, with activity, indoor/outdoor, and W/kg filtering for performance analysis.

Instructions

Get power curves for an athlete from Intervals.icu.

Returns best power output for selected durations across specified time periods.
Uses FFT power computation. Power values are in watts.

Args:
    activity_type: Activity type (e.g. "Ride", "Run", "VirtualRide"). Default is "Ride".
    durations: Durations in seconds to include. Default is [5, 15, 30, 60, 120, 300, 600, 1200, 3600]
    indoor_outdoor: Filter by location — "indoor" or "outdoor". Omit for no filtering.
    start_date: Start date (YYYY-MM-DD) for custom date range curve. Must be used with end_date.
    end_date: End date (YYYY-MM-DD) for custom date range curve. Must be used with start_date.
    this_season: Include this season's curve (default True)
    last_season: Include last season's curve (default True)
    include_normalised: Include weight-normalised W/kg values (default True)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_athlete_power_curves"
  }
}

Input Schema

Name	Required	Default
`end_date`	No
`durations`	No
`start_date`	No
`last_season`	No
`this_season`	No
`activity_type`	No	Ride
`indoor_outdoor`	No
`include_normalised`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 2, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does add real context: it discloses the computation method ('FFT power computation'), the unit ('watts'), the default duration set, the default season/weight-normalisation behaviour, and the pairing constraint on the date parameters. It stops short of stating data freshness or whether a missing athlete/empty season errors or returns empty.

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?

The leading two sentences deliver purpose and return semantics up front, followed by an efficient arg list where each line adds information. The Args block mirrors the schema property names but does so with added meaning, so it earns its space.

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-value explanation is not needed, and the description covers all inputs including a subtle dependency. The only gap is guidance on selecting this tool versus sibling activity-analysis tools for a read-only, eight-parameter query.

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?

Schema description coverage is 0%, yet the description documents all eight parameters with types, defaults, accepted values, and formats (seconds, YYYY-MM-DD, 'indoor'/'outdoor'), plus the cross-parameter constraint that start_date and end_date must be used together. This fully compensates for the empty schema descriptions.

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 and resource ('Get power curves for an athlete from Intervals.icu') and clarifies the output semantics ('best power output for selected durations across specified time periods', 'in watts'). It does not, however, differentiate itself from related siblings such as get_activity_best_efforts or get_activity_interval_stats.

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?

Usage is implied through the parameter documentation — e.g. omitting indoor_outdoor means 'no filtering', and start_date/end_date must be paired for a custom-range curve. But there is no explicit statement of when to choose this tool over the best-efforts or interval-stats siblings, so selection guidance is left to inference.

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