garmin-mcp-triathlon

get_cardiac_drift_analysis

Measure aerobic decoupling by computing the percentage change in power:HR ratio between the first and second half of a Garmin activity. Requires power and 3600+ records with HR.

Instructions

Measure cardiac drift (aerobic decoupling) for a specific activity.

Returns the percentage change in the power:HR ratio from the first half of the activity to the second. Where the boundary between "coupled" and "decoupled" sits is a coaching decision, so no label is attached — a common reading is that beyond about 5% the athlete was decoupling, but that number belongs in the coaching layer.

TWO PRECONDITIONS, both checked before you waste a call:

The activity must carry POWER. Drift is a power:HR ratio, so heart rate alone cannot produce it. Cycling needs a power meter. Running usually does not — most modern Garmin watches estimate running power natively and record it on every sample.
At least 3600 records with both power and heart rate, which is 60 minutes at 1-second sampling. Shorter sessions do not qualify, and a device set to smart recording rather than 1-second sampling may not reach it even on a long one.

When either fails the response is an error with a reason naming which, plus records_total, records_with_power and records_usable so the gap is visible. That is a limitation of the recorded data, not a fault in the activity — do not report it as a training finding.

Args: activity_id: Garmin activity ID (numeric or string)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`activity_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 4, 2026

TDQS

A4.2/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 well: it discloses the failure response shape (error with reason plus records_total/records_with_power/records_usable) and warns not to report data limitations as training findings. It omits any explicit statement of read-only safety or auth/permission needs.

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 metric definition, then the two preconditions, then error behavior. The coaching-layer aside about the 5% threshold is slightly tangential but justifies the absence of a label, so it earns its place.

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?

For a single-parameter analysis tool with an output schema present, the description covers the metric meaning, preconditions, and failure diagnostics. Nothing an agent needs to call it correctly is 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 0% for the single activity_id parameter, but the description only restates it as 'Garmin activity ID (numeric or string)', which the schema's anyOf already conveys. It adds marginal meaning over the structured field.

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 resource ('Measure cardiac drift (aerobic decoupling) for a specific activity') and immediately defines the metric as the percentage change in the power:HR ratio between halves. This distinguishes it from sibling analysis tools like get_activity_power_in_timezones or get_power_duration_curve.

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?

Gives two explicit preconditions (activity must carry power; at least 3600 records with both power and HR) and explains when each fails, which is strong when-to-use guidance. It does not name an alternative tool to use instead when drift cannot be computed, so it stops short of a full 5.

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

Deploy Server