Skip to main content
Glama
futureweb

Futureweb Intervals MCP

by futureweb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_power_hr_efficiency

Read-only

Track power-to-heart-rate efficiency over weeks by banding work intervals by average power and comparing oldest vs newest groups. Read-only.

Instructions

Use to track power-to-heart-rate efficiency (W per bpm at the same power) over weeks.

Puts every WORK interval of at least min_interval_secs with power and HR into the power band of its average power; returns per activity and band the count and time-weighted W, HR and W/bpm, and per band the oldest vs the newest group of activities (each counts once; at least 3 per group, else not reliable) compared with the day-to-day SD. Default the last 90 days of rides, limit 30 (max 60); trends per gear when several power meters are involved; filters for gear, indoor/outdoor and interval start time. Heat, fatigue, cadence and sensors move the ratio: statistics only, no fitness verdict. Read-only; one API call per activity plus 2. Method: intervals://methods/comparisons (get_guide).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum activities, newest first; capped to 1-60
gear_idNoOnly activities on this gear id (get_gear_list)
end_dateNoLast day YYYY-MM-DD; default today
athlete_idNoDefault: the configured athlete
start_dateNoFirst day YYYY-MM-DD; default 90 days before end_date
environmentNoOnly indoor (trainer, virtual) or outdoor sessions; omit for both
power_bandsNoComma-separated non-overlapping bands in W as "low-high"; low <= W < high150-200,200-250,250-300
sport_typesNoComma-separated activity types, e.g. "Ride,VirtualRide"Ride,GravelRide,VirtualRide
output_formatNojson = machine-readable, all fieldstext
max_start_minutesNoOnly intervals starting at most this many minutes into the activity
min_interval_secsNoShortest WORK interval counted, in seconds
min_start_minutesNoOnly intervals starting at least this many minutes into the activity
min_activities_per_groupNoIndependent activities needed in the oldest and in the newest group for a trend, >= 1

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations it discloses cost ('one API call per activity plus 2'), a reliability guard ('at least 3 per group, else not reliable'), and an explicit limitation ('statistics only, no fitness verdict'). These are exactly the traits an agent needs that annotations cannot provide.

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, then behavior, defaults, and a method pointer follow in a logical order with no filler sentences. The middle paragraph is dense and stacks many clauses, which slightly costs readability but every clause carries information.

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?

For a 13-parameter analytical tool with no output schema, it describes the returned shape well (per activity and band counts plus time-weighted W, HR, W/bpm, and group comparisons) and states the API cost and reliability threshold. It leaves the exact output field layout to the text/json format flags, which is a minor gap.

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 nonetheless adds interpretive context: the band-assignment rule ('puts every WORK interval ... into the power band of its average power'), the trend-group semantics for min_activities_per_group, and the default window/limit, tying the 13 parameters together conceptually.

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 computed resource: 'track power-to-heart-rate efficiency (W per bpm at the same power) over weeks'. This distinguishes it from curve siblings (get_hr_curves, get_athlete_power_curves) and stream comparisons, which do not compute a per-band W/bpm efficiency ratio.

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

Usage Guidelines4/5

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

Opens with 'Use to track ... over weeks' and gives concrete operating conditions (last 90 days of rides, band grouping, gear trends). It points to get_guide and intervals://methods/comparisons for methodology but never names a sibling tool it should be preferred over, so a discriminating agent still has to infer the boundary.

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