Skip to main content
Glama

Workout detail

workout_detail

Detail for a workout UUID from sessions. Includes source/device, indoor flag, pool length, elevation gain, laps, classified segments, paired pause intervals, a swimming summary and reduced series when accessible in HealthKit. Summaries, events and zones are permanent; only raw series expire after 30 days. The iPhone must sync with a version that collects detail. raw_available and summary_available distinguish coverage. synced_at is the server ingestion time when recorded; older summaries fall back to the R2 object upload time (which may be the storage migration time). not_available means not synced. HR zones estimate active bucket time (excluding pauses) using one unambiguous HR source and six percent-max bands, including zone 0 below 50%. max_hr can override the observed personal workout maximum; observed maximum is an estimate, not a tested physiological maximum. Missing buckets are excluded and coverage is reported. Values[i] covers seconds [(offset+i)*interval_s, (offset+i+1)interval_s) from workout start, clipped at elapsed_s; null is missing. Each series has its own source, do not sum or average duplicate metrics across sources. Averages are weighted by sample overlap; sums are prorated across buckets. Gaps and sampling limit precision, including time in HR zones. Events are normalized before pagination: pause/resume pairs become one pause with pause_kind and end_reason; unmatched resumes are marked, and trailing pauses end at workout end. Segment distance_basis distinguishes metadata from bucket estimates; distance_split labels are distance matches, not guaranteed native types. swimming_summary uses lap intervals minus the union of recorded pauses; gaps outside laps count as inferred rest. It preserves swimming_s, total_rest_s and pace_s_per_100m. wall_gaps exposes every consecutive unique lap transition (after_lap is 1-based, gap_s is next start minus previous end, manual_pause includes boundary/spanning pauses). sets contains HealthKit segments covering complete laps, with segment_kind=set and distance_m=pool_length_mlaps (null without pool length), never series estimates. Continuity joins gaps without manual pauses at or below tolerance: nearest-rank P90 of non-manual gaps from 0 to 15s plus 1s, clamped to 3–12s; fewer than 6 candidates falls back to 10s. wall_tolerance_s overrides this with a fixed 0–300s value. continuity_rule returns method, tolerance_s and candidate count. This is a heuristic, not proof that short gaps were turns. longest_continuous selects maximum distance, fastest duration on ties (tie_count includes the winner); otherwise selects duration, retaining selected_by. It adds laps and pace_s_per_100m. Continuous duration and pace include tolerated wall gaps, while swimming/rest totals retain their existing meaning. Pauses within laps still split them, with distance prorated by active time; laps counts contributing lengths, including partial ones. continuous_stretches lists all stretches >=100m chronologically with offset_s, distance_m, duration_s, pace_s_per_100m and laps. healthkit_set_disagrees flags a set split by this rule when its internal gaps have no manual pause and none exceeds 15s; diagnostic only. Continuity is recalculated from permanent events on every request, including after raw expiry. Distance uses lap/pool length or one distance series, with its basis exposed. Missing or overlapping/legacy point laps make the summary unavailable, not zero. The full summary is repeated on every page, even with metrics: []. Active duration does not measure moving time. Follow next_offset and next_event_offset independently. No GPS route/altitude series or inferred sensor identity is included.

Input Schema

NameRequiredDescriptionDefault
uuidYesWorkout UUID returned by sessions
limitNo
max_hrNoPersonal maximum HR in bpm; otherwise uses observed workout maximum, an estimate
offsetNoSeries bucket offset; use next_offset to continue
metricsNoOptional series names; [] returns metadata and events only
event_offsetNoIndependent event offset; use next_event_offset to continue
wall_tolerance_sNoFixed swimming wall-gap tolerance in seconds (0–300). Default: clamp(P90 of non-manual gaps <=15s + 1s, 3s, 12s); fewer than 6 candidates uses 10s. Manual pauses always break continuity.

Output Schema

NameRequiredDescriptionDefault
detailYes
offsetYes
statusYes
workoutYes
hr_zonesYes
synced_atYes
truncatedYes
next_offsetYes
event_offsetYes
total_eventsYes
raw_availableYes
total_bucketsYes
retention_daysYes
available_metricsYes
next_event_offsetYes
summary_availableYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior1/5

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

The description describes a read-only retrieval of workout detail, but the annotations declare readOnlyHint=false. That is a direct conflict on the tool's side-effect profile, and the description does not reconcile it. Otherwise it is rich, but the contradiction forces a 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with purpose, but the remainder is a dense single paragraph of implementation edge cases (R2 fallback, continuity P90, swimming wall gaps) that is hard to scan. Many details earn their place for interpretation, but the lack of structure and length push it below concise.

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?

Given the tool's complexity (series, events, zones, continuity, pagination) and the presence of an output schema, the description covers availability, expiry, sync prerequisites, zone estimation, event normalization, continuity rules, and pagination independently. Nothing material for correct invocation appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 86% and the schema already documents uuid, max_hr, offset, metrics, event_offset, and wall_tolerance_s in detail. The description adds narrative around wall_tolerance_s and max_hr but largely restates what the schema provides; limit remains undocumented.

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?

The opening sentence names the resource (workout detail) and the identifier source (UUID from sessions), and the body enumerates the exact payload components. An agent can distinguish it from sessions (list) and derived_metrics (aggregates) without opening the schema.

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?

It implies the workflow by saying the UUID comes from sessions and explains pagination via next_offset/next_event_offset, but it never explicitly states when to choose this over derived_metrics or query_daily, nor when not to use it. The metrics: [] note is helpful invocation guidance but not tool-selection guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources