Skip to main content
Glama
Sign In
garmin-mcp

garmin-mcp

by Sinfjell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

find_comparable_intervals

Find recent running reps matching a target distance across your recent activities, filtering out warm-ups, rests, and cool-downs so you can compare interval splits.

Instructions

Find recent work reps of a given distance, across your last running activities.

Answers "what have I been running 1000m reps at lately?" in one call, replacing list-activities → laps-per-activity → filter-by-hand. Every rep returned has been through the same classification as get_activity_intervals, so warm-ups, rests and cool-downs never appear.

target_distance_m is the rep distance to match (e.g. 1000). Reps within tolerance_pct of it are returned (default 10%, so 900-1100 m). activity_limit (default 10) caps how many running activities are opened — each one costs a Garmin call — and they are taken from the most recent activities of any type, so a long stretch without running returns fewer.

Returns a JSON object with "matches" (each rep plus its activity_id, date and name, newest first), "match_count", and "activities_scanned".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "target_distance_m": "<target_distance_m>"
    },
    "name": "find_comparable_intervals"
  }
}

Input Schema

NameRequiredDescriptionDefault
tolerance_pctNo
activity_limitNo
target_distance_mYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the per-activity Garmin call cost, that activity_limit is applied to the most recent activities of any type (so a running gap yields fewer results), that reps pass the same classification as get_activity_intervals so warm-ups and rests are excluded, and that matches are ordered newest first.

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

Conciseness5/5

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

The purpose is front-loaded in the first line, followed by the motivation, then per-parameter notes, then return shape. Every sentence adds information; nothing is padded or restated.

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 three-parameter search tool with no annotations, the description covers inputs, cost, filtering semantics, ordering, and the degenerate no-running case. An output schema exists, so the brief mention of match_count and activities_scanned is sufficient rather than required.

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

Parameters5/5

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

Schema coverage is 0%, so compensation is required and delivered: target_distance_m is described with a concrete example (1000), tolerance_pct is explained with its default and the resulting 900–1100 m band, and activity_limit is explained with its default plus the non-obvious caveat about which activities are scanned.

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 first sentence gives a specific verb (find), resource (work reps of a given distance) and scope (last running activities). It is clearly distinguishable from get_activity_laps and get_activity_intervals, which operate on a single activity rather than searching across many.

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?

The description names the underlying question it answers and explicitly says it replaces the list-activities → laps-per-activity → filter-by-hand workflow, which strongly implies when to prefer it. It does not spell out an explicit "use get_activity_intervals instead when…" exclusion, so it falls just short of a 5.

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

Deploy Server

Other Tools