Skip to main content
Glama
Sign In
garmin-mcp

garmin-mcp

by Sinfjell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_running_threshold

Fetch lactate threshold pace, LTHR, and HR zones from Garmin to prescribe threshold or interval sessions; verify the measurement date to avoid stale thresholds.

Instructions

Get the running threshold anchor: lactate threshold pace, LTHR, and HR zones.

This is the number a threshold or interval session should be prescribed from — never an activity's average pace. Returns a JSON object with:

  • "lactate_threshold": threshold heart rate (LTHR, bpm) and threshold pace ("M:SS/km" plus decimal min/km and raw m/s), with the date Garmin last measured it. Check that date: a threshold from months ago is stale.

  • "heart_rate_zones": the five zones with explicit floor_bpm and ceiling_bpm, plus max and resting HR and the method Garmin used.

Each section is fetched independently, so one dead endpoint leaves the other intact. For VO2 max and race predictions use get_performance_metrics.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_running_threshold"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/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 reasonably well: it discloses that each section is fetched independently so one dead endpoint leaves the other intact, and warns that the measurement date may be stale and should be checked. It does not state auth requirements, rate limits, or whether a missing measurement returns null versus an error, which keeps it short of a 5.

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?

The key framing sentence is front-loaded before the return-value breakdown, and the bulleted structure maps cleanly to the two returned sections. It runs slightly long for a zero-argument read, and the trailing sibling-routing sentence sits apart from the usage framing at the top where it would be more useful.

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

Completeness4/5

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

An output schema exists, so the description needn't enumerate return fields, yet its explanation adds interpretive value the schema cannot — notably the instruction to sanity-check the measurement date. Completeness is only slightly short because the relationship to get_threshold_history and failure modes for missing data are unaddressed.

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

Parameters4/5

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description adds nothing to compensate for because there is nothing to compensate for.

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 description names a specific resource and its exact contents (lactate threshold pace, LTHR, HR zones) and immediately scopes it against near-neighbours: it is the anchor for prescribing sessions, not an activity's average pace, and VO2 max / race predictions live in get_performance_metrics. An agent can distinguish this from get_activity_hr_zones and get_performance_metrics without opening any schema.

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?

It gives a clear positive case (prescribe threshold or interval sessions from this value) and an explicit negative case (never an activity's average pace), plus a named alternative for a related need. The one gap is that the closest sibling, get_threshold_history, is never mentioned or contrasted, leaving the agent to infer whether it wants the current anchor or the history.

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