Skip to main content
Glama
futureweb

Futureweb Intervals MCP

by futureweb

get_activity_report

Read-only

Retrieve a report for one activity covering overview, plan vs execution, power meter check, climbs, and data quality in one call.

Instructions

Use first for any question about one activity: overview, plan vs execution, power meter check, climbs and data quality in one call (read-only, 3-4 API requests).

The overview has thresholds, device, sport-assigned custom fields, fueling, weather and W′ balance. With a paired event or planned_workout_doc the plan-vs-execution analysis follows (as analyze_workout_execution), otherwise the intervals; a second-power-meter check only with enough valid paired samples; climbs without intervals or above 500 m gain; then data-quality notes. compact = core numbers and up to 5 key findings. Full detail: get_activity_details, analyze_workout_execution, compare_power_streams, analyze_climbs, get_activity_data_audit. Methods: intervals://methods/activity-data, intervals://methods/execution (get_guide).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
activity_idYesActivity id, e.g. i123456789
detail_levelNocompact = core numbers, up to 5 key findings, data-quality flags; standard = full analysis, at most 30 interval lines; full = everything, all custom fields and streamsstandard
output_formatNojson = machine-readable, all fieldstext
include_climbsNoForce (true) or suppress (false) the climbs; default only without intervals or above 500 m gain
pause_tolerance_sNoRecording pause per step before it is flagged, seconds; default 60
start_tolerance_sNoPlan timeline shift before a step is flagged, seconds; default 120
planned_workout_docNoWorkout document {"steps": [...]} to compare against, e.g. when the event was deleted
include_route_historyNoAdd earlier activities on the same Intervals.icu route (2 extra requests)
duration_tolerance_pctNoStep duration tolerance in % before a step is split or flagged short; default 10

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces the safety profile while adding genuine behavior: 3-4 API requests, conditional branching based on activity data, and the compact/full output distinction. It stops short of noting rate limits or exact response shape, but adds substantial context beyond the annotations.

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-loads the routing directive and every subsequent sentence carries decision-relevant detail with no filler. It is dense and slightly run-on, but each clause earns its place by describing a branch or alternative.

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?

Despite no output schema, the description enumerates what the overview and report contain (thresholds, device, custom fields, fueling, weather, W′ balance, data-quality notes) and how output varies with detail_level. For a 9-param composite tool with nested objects, this is complete enough to call correctly.

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 schema carries most parameter meaning (baseline 3). The description goes further by explaining when parameters matter in practice, e.g. that planned_workout_doc is for cases like a deleted event, and it ties include_climbs to the without-intervals/500 m default.

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+resource (a full activity report for one activity) and its scope: overview, plan vs execution, power-meter check, climbs and data quality in a single call. It distinguishes itself from verbose siblings by naming exactly which of them it subsumes and then routing to them for full detail.

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?

Explicitly says 'use first for any question about one activity', states the conditions that trigger each sub-analysis (paired event or planned_workout_doc for plan-vs-execution; without intervals or above 500 m gain for climbs; enough valid paired samples for the second power meter), and names five alternatives for full detail.

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