Skip to main content
Glama
futureweb

Futureweb Intervals MCP

by futureweb

get_fatigue_resistance

Read-only

Compare fresh versus fatigued power curves at kJ work thresholds to show how much power an athlete loses after hard efforts, for one activity or 42-day curves.

Instructions

Use for fatigue resistance: best power fresh vs after the athlete's work thresholds kJ0 / kJ1 (Intervals.icu fatigued power curves).

Reads the sport settings first. When they hold no kJ thresholds no fatigued values are shown: the tool explains the setting and (suggest_thresholds) proposes thresholds from body mass and recent rides, never saved. Otherwise returns watts per duration fresh and after kJ0 / kJ1 with the change in %, for one activity or for athlete curves (default 42d); a fatigued curve without data is reported as missing, one equal to fresh as identical, without a change. Read-only, 2-5 API calls. Within one long ride: get_long_ride_fatigue_profile. Method: intervals://methods/comparisons (get_guide).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
curvesNoComma-separated athlete curve ids, e.g. "42d,90d,1y,s0"; ignored with activity_id42d
durationsNoComma-separated seconds, e.g. "60,300,1200"60,300,1200
athlete_idNoDefault: the configured athlete
activity_idNoActivity whose curves are compared; omit for the athlete curves
activity_typeNoActivity type of the curves and kJ thresholds, e.g. Ride, VirtualRideRide
output_formatNojson = machine-readable, all fieldstext
suggest_thresholdsNoSuggest kJ0/kJ1 when not both are configured; a suggestion only, nothing is saved

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint, it discloses that sport settings are read first, what happens when no kJ thresholds exist (setting explained, suggest_thresholds proposes but never saves), missing vs identical curve reporting, and an API-call budget of 2-5. Rich behavioral context.

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?

Purpose is front-loaded and every clause is substantive; the dense multi-clause construction is efficient though slightly heavy to parse. Minor room to trim the method-reference tail.

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?

With no output schema, the description carries the return-value burden and does so fully: watts per duration fresh/after kJ0/kJ1 with change %, missing/identical reporting, and per-activity vs athlete-curve scope. An agent has everything needed to call and interpret it.

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 meaning: curves vs activity_id selection (per-activity vs athlete curves, default 42d), and that durations map to watts fresh/after thresholds. It ties parameters to output semantics beyond the schema strings.

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?

Names a specific analysis (best power fresh vs after kJ0/kJ1 work thresholds) and the exact data source (Intervals.icu fatigued power curves). It also explicitly distinguishes itself from the sibling get_long_ride_fatigue_profile (within one long ride).

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?

States when to use it, the alternative condition (get_long_ride_fatigue_profile for within-ride analysis), and points to the method guide via intervals://methods/comparisons (get_guide). Alternatives and boundaries are explicit.

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