Skip to main content
Glama
durely

durely insights

by durely
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Sync Garmin data

garmin_sync
Idempotent

Downloads Garmin Connect data into the local cache in the background to refresh the newest activities or extend history back to an earlier date; track progress with a status call.

Instructions

Start downloading Garmin data into the local cache. Runs in the background and returns immediately; follow progress with garmin_sync_status.

You rarely need this: other tools sync automatically on first use and when the cache is over an hour old. Use it to:

  • fetch the latest data right now (e.g. "I just finished a run"),

  • extend history further back (from="2019-01-01"),

  • re-download everything (mode="full"), e.g. after editing many activities in Garmin Connect.

Domains (default: all except fit_files): activities, daily_summaries, sleep, hrv, weight, body_battery, hrv_readings, heart_rate, spo2. "fit_files" downloads the original FIT file of every activity (one request each, ~2 activities/s). That's optional: FIT files are otherwise fetched on demand by garmin_get_activity_laps and garmin_get_activity_streams.

Input Schema

NameRequiredDescriptionDefault
fromNoExtend history back to this date (yyyy-MM-dd). History starts at your first activity by default; an earlier date fetches older wellness data. A later date has no effect: history is never narrowed.
modeNoauto: new data plus any history still missing. full: forget what's cached and re-download.auto
domainsNoOnly sync these domains. Defaults to all except "fit_files".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the fire-and-forget async behavior, the cache-side effect of mode='full' ('forget what's cached'), and the throughput cost of fit_files (~2 activities/s, one request per activity). Annotations only carry the safety profile (readOnly=false, idempotent=true); the description supplies the operational semantics they cannot express.

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 async/cache contract, then uses a tight bullet list for the when-to-use cases and a short paragraph for domains. Slightly long, but every sentence (including the fit_files cost note) carries information an agent needs.

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?

With no output schema, the description correctly explains the return contract (returns immediately, no result payload) and routes the agent to garmin_sync_status for results. Combined with 100% param coverage and annotations, nothing material is missing for correct invocation.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real value by giving scenario-anchored examples ('from="2019-01-01"', 'mode="full" after editing many activities') and by spelling out the default domain set. It stops short of listing every domain's effect, which the schema enum already covers.

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?

Specific verb + resource + destination: 'Start downloading Garmin data into the local cache.' It also states the asynchronous contract up front ('Runs in the background and returns immediately'), which distinguishes it from every read-only getter sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'You rarely need this' because other tools sync automatically, then enumerates the three concrete cases where it is needed (fresh data, extending history, full re-download). It also names garmin_sync_status as the progress-tracking alternative.

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