Skip to main content
Glama
nrvim

garmin-givemydata

by nrvim

garmin_race_predictions

Predict race finish times for 5K, 10K, half marathon, and marathon from Garmin data, and track daily trends to see if fitness is improving or declining.

Instructions

Predicted race finish times (5K, 10K, half marathon, marathon).

Shows daily predictions with human-readable times and trend direction. A rising prediction time means declining fitness; falling means improving.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.13

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It usefully discloses an interpretive trait: rising prediction times mean declining fitness and falling means improving, which prevents an agent from misreading the trend. However, it says nothing about auth, rate limits, or how the 'days' window affects results, leaving meaningful gaps for an unannotated tool.

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?

Three short, front-loaded lines with no wasted words; the resource is stated first and the trend interpretation follows. Structure is efficient though the line breaks are slightly fragmented.

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, so return-value explanation is unnecessary and the description reasonably focuses on purpose and trend interpretation. But with no annotations and an undocumented parameter, the definition leaves the agent without when-to-use or parameter context.

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% for the single 'days' parameter, so the description must compensate, but it never mentions the parameter. The phrase 'daily predictions' hints at a time series but does not explain that 'days' controls the lookback window or its default of 30.

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 states a specific resource (predicted race finish times) and enumerates the distances covered (5K, 10K, half marathon, marathon), which is concrete and distinct from most siblings. It does not explicitly differentiate from adjacent tools like garmin_records, garmin_vo2max, or garmin_trends, but the resource is specific enough that an agent can identify it.

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?

Usage is implied by the purpose (retrieve fitness-based race time predictions), but there is no explicit when-to-use guidance, no prerequisites, and no named alternatives. An agent can infer intent but gets no routing help.

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