Skip to main content
Glama
cambroussard9

trail-factors

basic_metrics

Retrieve a run's core metrics: average heart rate, paces, sliding-window best efforts, run/walk/stand time, and running cadence. Use them as baselines to compare drift and efficiency.

Instructions

§6.0 the run's own description: average HR, three paces, windowed bests, run/walk/stand time, and cadence.

Args:
    run: run_id, activity_id or Garmin file id. Empty means the latest run.

THESE ARE ANCHORS, NOT SIGNALS. For a run/walk athlete holding an HR cap,
average HR barely moves from run to run because HR is held nearly flat
across grade — quote it as the level that drift and efficiency are
deviations FROM, not as a finding.

Paces are never pooled: `overall` is Garmin's own basis (distance over
timer time), `running` and `walking` come from the rwd_* splits and are
separate quantities. A class below the minimum time is `gated` with its
time stated, not silently absent.

The bests are SLIDING WINDOWS, never an instantaneous maximum, and they are
NOT comparable across sampling regimes. Read each window's
`walk_time_fraction` and `flagged_record_fraction` before quoting it: a
maximum selects for positive measurement error in a way a mean does not.

Cadence is steps per minute. It is running-only and non-zero-only, so it
does NOT equal Garmin's own averageRunningCadence, which includes standing.

Input Schema

NameRequiredDescriptionDefault
runNo
last_nNo
clusterNo
end_dateNo
run_typeNo
directionNo
segment_idNo
start_dateNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: paces are never pooled, classes below a minimum time are `gated` with their time stated, bests are sliding windows not instantaneous maxima, and cadence excludes standing. However, it says nothing about read-only vs mutating nature, failure modes, or how the many date/filter parameters change the scope of results.

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 what is returned, which is good, but the body drifts into essayistic reasoning ('a maximum selects for positive measurement error in a way a mean does not') and carries a stray '§6.0 the run's own description' artifact. Much of the caution text is valuable; some of it is prose that costs tokens without changing agent behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description spends most of its length explaining return values it did not need to, while leaving 7 of 8 input parameters undefined. For a tool whose filtering behavior is driven by those parameters, the definition is asymmetric: rich on interpretation, thin on how to actually scope a call.

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

Parameters2/5

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

Schema description coverage is 0% across 8 parameters, so the description must compensate — but it only documents `run` (run_id, activity_id or Garmin file id; empty means latest). The other seven (`last_n`, `cluster`, `start_date`, `end_date`, `run_type`, `direction`, `segment_id`) are left entirely unexplained, so their semantics remain invisible.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the concrete contents returned for a single run (average HR, three pace bases, windowed bests, run/walk/stand time, cadence), which is far more specific than a restatement of the name. It does not explicitly contrast itself with siblings like session_series or efficiency_factor, leaving the agent to infer that this is the per-run summary anchor.

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?

There is one piece of real routing guidance — that average HR is a baseline to be quoted as the level drift and efficiency deviate from, not a finding. That implies this tool is a starting point before the analytic siblings, but no alternative is ever named and no when-not-to-use condition is given.

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