What can you do with this server?

Summary: garmin-local-mcp is a local-first Garmin MCP server — sync your Garmin Connect data once into a local SQLite warehouse, then run offline queries, correlations, and anomaly analysis over it without touching the API again. * Auth & sync management — auth_status checks stored tokens; sync pulls up to 60 days (default last 30) from Garmin Connect; sync_status reports per-table date coverage, last sync, and pending errors. * Single-day inspection — get_day merges wellness, sleep, HRV, training status, activities, and data-quality flags for one date. * Time-series queries — query_metrics returns columnar series for one or more metrics over a date range, with daily/weekly/monthly aggregation and optional mean/min/max/sd stats. * Correlation analysis — correlate computes Pearson/Spearman between two metrics, supports a fixed lag_days, and with scan_lags=True searches -7..+7 day lags, returning the strongest with a Bonferroni-adjusted p-value and a cautionary note when it may be chance. * Personal baselines — baselines gives mean ± sd bands per metric over a trailing window (default 28 days) to judge what is normal for this user. * Anomaly detection — anomalies finds outlier days (z-score) and sustained 5+ day streaks across core wellness metrics. * Activity browsing — list_activities lists recent activities with type/date/distance filters; get_activity returns the stored summary row for one activity (no GPS or sample streams). * Data-gap auditing — gaps lists missing days per table plus unresolved sync errors, so holes can be re-synced before conclusions are drawn. * Zero-auth offline ingest — import_fit imports a manually exported Garmin wellness FIT bundle folder without credentials, never overwriting API-sourced rows. * Safety properties — only sync and import_fit write anything, and only inside your own data directory; all other tools are read-only over local history, so analysis keeps working when Garmin's API is down. Note: the README documents a 13th tool, circadian (chronotype, sleep need, and validated wake window), but it is not present in the supplied server schema.

Which integrations are available for this server?

Syncs Garmin Connect health data (wellness, sleep, HRV, activities, etc.) into a local SQLite warehouse and provides analysis tools for querying metrics, correlations, baselines, anomalies, and data gaps, with offline resilience and a zero-auth FIT import fallback.

How do I use garmin-local-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@garmin-local-mcp correlate my sleep and training load for the last month" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

garmin-local-mcp

by anup-shesh

Overview Schema Source Related Servers Discussions Admin

Python

Local

Summary: garmin-local-mcp is a local-first Garmin MCP server — sync your Garmin Connect data once into a local SQLite warehouse, then run offline queries, correlations, and anomaly analysis over it without touching the API again.

Auth & sync management — auth_status checks stored tokens; sync pulls up to 60 days (default last 30) from Garmin Connect; sync_status reports per-table date coverage, last sync, and pending errors.
Single-day inspection — get_day merges wellness, sleep, HRV, training status, activities, and data-quality flags for one date.
Time-series queries — query_metrics returns columnar series for one or more metrics over a date range, with daily/weekly/monthly aggregation and optional mean/min/max/sd stats.
Correlation analysis — correlate computes Pearson/Spearman between two metrics, supports a fixed lag_days, and with scan_lags=True searches -7..+7 day lags, returning the strongest with a Bonferroni-adjusted p-value and a cautionary note when it may be chance.
Personal baselines — baselines gives mean ± sd bands per metric over a trailing window (default 28 days) to judge what is normal for this user.
Anomaly detection — anomalies finds outlier days (z-score) and sustained 5+ day streaks across core wellness metrics.
Activity browsing — list_activities lists recent activities with type/date/distance filters; get_activity returns the stored summary row for one activity (no GPS or sample streams).
Data-gap auditing — gaps lists missing days per table plus unresolved sync errors, so holes can be re-synced before conclusions are drawn.
Zero-auth offline ingest — import_fit imports a manually exported Garmin wellness FIT bundle folder without credentials, never overwriting API-sourced rows.
Safety properties — only sync and import_fit write anything, and only inside your own data directory; all other tools are read-only over local history, so analysis keeps working when Garmin's API is down.

Note: the README documents a 13th tool, circadian (chronotype, sleep need, and validated wake window), but it is not present in the supplied server schema.

garmin-local-mcp

Local-first Garmin data warehouse with an analysis-grade MCP server. Sync once, analyze forever, even when the API is down.

garmin-local-mcp answering questions from a local store, including with the network disconnected

Try it without a Garmin account

If you don't own a Garmin, or just want to see what the tools return before handing over credentials, seed a synthetic store:

pip install garmin-local-mcp
garmin-local-mcp --data-dir ~/.garmin-mcp-demo demo
garmin-local-mcp --data-dir ~/.garmin-mcp-demo serve

That generates 180 days across every table, then serves them over MCP. No login, no network, no account.

The data is generated rather than recorded, but it is not random. A latent recovery factor drives HRV up while resting heart rate goes down, training load raises the next day's resting heart rate, a six-day illness window sits in the middle of the range, and a few sleep nights are deliberately missing. Sleep timing carries a planted chronotype (MCTQ MSFsc 03:45, with alarm-pinned work mornings and later, longer free nights), and the sleep score drops with distance from that natural wake time. So the analysis tools have something real to find. Over the full 180 days (exact figures shift a little with the end date, because training days depend on the weekday):

Ask	Returns
`correlate(hrv, resting_hr)`	−0.4 to −0.6, a genuine inverse relationship
`correlate(training_load, resting_hr, scan_lags=True)`	near 0 at lag 0, +0.4 to +0.65 at lag 1 (90 to 100 training days, significant after correcting for the 15 lags scanned): the effect is next-day
`anomalies()`	the illness window, flagged across resting HR, HRV, skin temperature, sleep score and stress at once
`gaps()`	the missing sleep nights
`circadian()`	MSFsc within 10 minutes of the planted 03:45, a circadian wake around 07:45, and evidence `supportive` (the most that two holdout folds allow)

The analysis tools default to the last 30 days, which misses the illness window, so ask about the whole range (demo prints it). On a short window a lag scan has little to work with; correlate says so in its note when the strongest lag is not significant once all 15 lags are accounted for.

sync_status reports demo_store: true on these stores, so an assistant can never present generated numbers as real measurements. The generator is deterministic — --seed reproduces a store exactly, and --days changes the range. demo refuses to overwrite a database it did not generate.

Related MCP server: Garmin MCP

Why another Garmin MCP?

Most Garmin MCP servers are thin live wrappers around Garmin's unofficial API. Every question your AI assistant asks becomes one or more live API calls returning large raw JSON blobs (a single raw sleep response runs around 230 KB), which makes multi-month questions like "how does my sleep correlate with training load?" expensive to ask.

That design is no longer universal. Since Garmin's auth change in March 2026 broke the ecosystem for several weeks, a number of projects have added local storage, and the largest server computes training-load and HRV trends server-side. Data ownership and server-side analysis are both crowded ground now. Three things are not:

Sleep-timing advice that is tested before it is given. circadian estimates your chronotype from your watch's sleep times (the Munich Chronotype Questionnaire's sleep-debt-corrected mid-sleep) and the wake time that fits it, with an 80% interval on each and a check of how much the answer moves under other reasonable settings. Then it asks whether waking near that time actually went with higher Garmin scores on nights the model never saw, beyond what sleep duration and schedule regularity explain, and says plainly when it didn't. Chronotype on its own is not new: other tools, including at least one MCP server, report MCTQ-style chronotype from wearable sleep data. I have not found another that puts uncertainty on the answer or validates it out of sample. See Sleep timing and chronotype.
Ingest that needs no login. A standalone decoder for Garmin's undocumented wellness FIT messages (sleep score, HRV, skin temperature, sleep stages, naps) reads manually exported bundles with no credentials at all. Other servers parse FIT activity files; I have not found another that decodes the wellness export. It is the only ingest path here that keeps working when Garmin auth breaks.
Correlation with lag. Pearson and Spearman between any two metrics with a scan over -7 to +7 day lags, so "training load raises my resting HR the next day" is a question with an answer.

The rest of the design follows from keeping your own copy:

Sync once, analyze forever. Incremental sync into a local warehouse: immutable raw JSON snapshots plus a SQLite database, in a directory you own.
Compact responses. Trends, correlations, baselines and anomaly detection are computed locally and returned as small columnar tables. Typical responses are under 2 KB (circadian, the richest, stays under 3 KB), so nothing floods the model's context.
Offline resilience. An API breakage pauses new syncs only. Every query over already-synced history keeps working, and FIT import keeps filling gaps.
Curated tools. 13 composable tools, not 110.

	garmin-local-mcp	Most other Garmin MCPs
Zero-auth ingest path	Yes (wellness FIT bundle import)	No
Lag-aware correlation (-7 to +7 days)	Yes	No
Chronotype and wake-time advice, validated on unseen nights	Yes (intervals, stability check, rolling holdout)	A few report chronotype; none found that validate it
Response size discipline	Compact columnar tables, typically < 2 KB	Raw payloads; the largest server documents skipping its detail endpoint at 50-500 KB
Works offline after an API breakage	Yes, analysis plus FIT ingest	Varies; some keep a local cache
Local data store you own	Yes (raw JSON + SQLite)	Several now do this too
Tool count	13 curated	18 to 148

Quickstart

Requires Python 3.12+.

pip install garmin-local-mcp

Or run it without installing, via uv:

uvx garmin-local-mcp --help

1. Log in once (MFA supported; tokens persist locally, so future runs never ask for a password):

garmin-local-mcp login

2. Backfill your history. The sync is resumable, safe to interrupt, and throttled to be polite to Garmin's servers. A year of history is roughly 1,800 requests; for long backfills, start it and let it run (overnight works well). If it gets rate limited or interrupted, re-run the same command and it resumes where it left off.

garmin-local-mcp sync --from 2026-01-01

3. Register the MCP server with your client (see Client setup for Claude Desktop, Cursor, and other clients):

claude mcp add --scope user garmin -- garmin-local-mcp serve

4. Ask questions. Examples of what Claude can now answer from your local warehouse in one or two tool calls:

"How does my sleep score correlate with next-day resting HR?"
"What were my anomalous HRV days this quarter?"
"Show weekly training load vs sleep for the last 3 months."

Client setup

The server speaks stdio, so any MCP client works. pip install garmin-local-mcp first (or use the uvx variants below, which need nothing installed beyond uv).

Claude Code

claude mcp add --scope user garmin -- garmin-local-mcp serve

Claude Desktop, one-click: download garmin-local-mcp-x.y.z.mcpb from the latest release, then in Claude Desktop open Settings > Extensions > Advanced settings, click "Install Extension…", and select the file. Requires uv on your PATH; the extension installs and runs the server from PyPI via uvx, so no manual Python setup is needed. If the install dialog warns about a missing Python >=3.12, you can ignore it: uv provisions its own interpreter.

Claude Desktop, manual (Settings, then Developer, then Edit Config; add to claude_desktop_config.json):

{
  "mcpServers": {
    "garmin": {
      "command": "garmin-local-mcp",
      "args": ["serve"]
    }
  }
}

Cursor (~/.cursor/mcp.json, or .cursor/mcp.json in a project):

{
  "mcpServers": {
    "garmin": {
      "command": "garmin-local-mcp",
      "args": ["serve"]
    }
  }
}

Any other stdio client / no local install (requires uv):

{
  "mcpServers": {
    "garmin": {
      "command": "uvx",
      "args": ["garmin-local-mcp", "serve"]
    }
  }
}

Note: login and the initial backfill sync are CLI steps (see Quickstart); the MCP server itself never prompts for credentials.

The 13 tools

Tool	What it does
`auth_status`	Check whether stored Garmin Connect tokens exist (use before sync, or after an auth error).
`sync`	Fetch up to 60 days from Garmin Connect into the local store (default: last 30 days ending yesterday; big backfills belong in the CLI).
`sync_status`	Local data coverage per table, last sync time, and pending sync errors.
`get_day`	One merged view of a single day: wellness, sleep, HRV, training status, performance scores, activities, and data-quality flags.
`query_metrics`	Columnar time series for one or more metrics between two dates, with daily/weekly/monthly aggregation and optional stats.
`correlate`	Pearson/Spearman correlation between two metrics, with day-lag support and an optional scan over lags -7..+7.
`baselines`	Personal mean +/- sd band per metric over a trailing window (default 28 days), to judge what is normal for this user.
`anomalies`	Outlier days (z-score deviations) and sustained streaks (5+ consecutive days on one side of the mean).
`list_activities`	Recent activities newest-first as a compact table, filterable by type, date range, and minimum distance.
`get_activity`	Full stored summary row for one activity (summary fields only, no GPS or sample streams).
`gaps`	Missing days per table plus unresolved sync errors, to find holes worth re-syncing before drawing conclusions.
`import_fit`	Zero-auth offline ingest of a manually exported Garmin wellness FIT bundle.
`circadian`	Chronotype (MCTQ), sleep need and an inferred wake window, each with an 80% interval, plus out-of-sample evidence on whether that window goes with higher Garmin scores. See Sleep timing and chronotype.

Only sync and import_fit write anything, and only inside the data directory. The server never prompts: auth problems come back as structured errors with a hint pointing at the login CLI.

Available metric names include resting_hr, sleep_score, hrv, steps, stress_avg, body_battery_high, skin_temp_dev_c, vo2max, fitness_age, achievable_fitness_age, training_load, endurance_score, hill_score, readiness_score, race_5k_s, the sleep-timing metrics sleep_onset_min, wake_time_min and mid_sleep_min (minutes from midnight of the wake date, so a 23:00 bedtime is −60), and about 35 more; any tool given an unknown name returns the full list.

Performance scores

Garmin's periodic fitness scores land in their own performance table: endurance score, hill score (with its endurance and strength sub-scores), training readiness (score, level, recovery time) and race predictions for 5k, 10k, half and full marathon (all in seconds).

These update on Garmin's own cadence rather than daily, so performance is deliberately excluded from gaps — a day without a new endurance score is normal, not a hole. Race predictions and hill score only move after qualifying running activity, so long stretches of nulls are expected for anyone whose training is mostly hiking, cycling or strength work.

Sleep timing and chronotype

circadian answers "when does my body clock want me to wake up?" from the sleep start and end times already in the store. It returns three separate quantities, each with an 80% interval from a week-block bootstrap:

Chronotype (msf_sc). The Munich Chronotype Questionnaire measure: mid-sleep on free days, corrected for the extra sleep taken to repay workday debt. Labelled early (before 03:30), intermediate or late (after 04:30); the bands are approximate and the number is the main value.
Sleep need. Your mean free-night sleep window, unless you pass sleep_need_min. The range where your Garmin scores level off is reported alongside as a cross-check.
Circadian-compatible wake window. msf_sc + sleep_need / 2. This is an inference, not an MCTQ output. With no catch-up sleep it is simply your average free-day wake time; with catch-up sleep it is that time moved earlier by half the catch-up.

It then checks the inference against what actually happened:

Stability. The estimate is recomputed over 90, 180 and 365 days, mean and median mid-sleep, and three travel-filter widths. stability: low usually means your schedule changed; pass a start after the change.
Evidence. On a rolling holdout (train 120 days, test the next 30), it compares a sleep-duration-only model with one that adds distance from your circadian wake, and controls for schedule regularity with a separate pair of models. The level is consistent, supportive, suggestive or unsupported. These describe how consistently the pattern held on unseen nights. They are not statistical significance, and evidence needs at least 180 days of history.
What it can't show. Readiness and sleep score are Garmin's own composite scores, not physiological measurements. The strongest possible conclusion is that waking near your window was associated with higher Garmin scores on nights the model never saw, beyond what sleep duration and regularity predict. It does not show that wake timing changes physiology.

When the formula and your past scores disagree by more than 30 minutes, the tool keeps both and suggests a 21-night experiment between them rather than averaging them away. Free days default to Saturday and Sunday mornings (free_days changes that), and if you set alarms on free days the chronotype comes out earlier than your body clock. Daylight-saving changes in the range are listed, using the configured timezone or the host's. Shift workers (daytime main sleep) get the rhythm and chronotype but no wake window.

Data layout and ownership

Everything lives in one directory you own (default ~/.garmin-mcp, override with the GARMIN_MCP_DATA_DIR environment variable or --data-dir):

~/.garmin-mcp/
├── config.toml                                  # optional settings
├── tokens/                                      # Garmin Connect session tokens
├── raw/daily/YYYY/YYYY-MM-DD/<endpoint>.json    # immutable raw API snapshots
├── raw/activities/<activity_id>.json            # one snapshot per activity
└── garmin.db                                    # SQLite warehouse

The raw JSON snapshots are the source of truth and are never overwritten. The SQLite database is a derived, rebuildable index: garmin-local-mcp reparse rebuilds it from the raw snapshots entirely offline, which is the universal escape hatch for schema evolution and parser fixes. Your data never leaves your machine.

Data quality note

Garmin watches report a provisional on-device resting heart rate that can diverge sharply from Garmin Connect's finalized value on nights with sparse sampling. A real observed case: the watch reported 69 bpm on-device while Garmin Connect later finalized the same night at 56 bpm.

This project handles that in two ways:

The API sync stores Garmin Connect's finalized value.
The FIT importer cross-checks the provisional on-device value against the overnight heart-rate floor. A resting HR sitting more than 10 bpm above the lowest overnight sample is a rate the watch never actually observed; it gets flagged (rhr_far_above_hr_floor) and withheld, leaving the field for the API to backfill rather than storing a misleading number.

Sparse sleep-stage logging is flagged the same way (sparse_sleep_stage_logging), and flags surface in get_day so the analysis layer knows which numbers to trust.

Offline / fallback runbook

If Garmin breaks the unofficial API again (it has before):

Everything analytical keeps working. All query, correlation, baseline, anomaly, and gap tools run on your already-synced local history. Only new syncs pause.
Keep ingesting without auth. Download a daily FIT bundle from the Garmin Connect website and import it locally (exact steps below). garmin-local-mcp import-fit <folder> decodes the bundle with zero authentication and fills the gap days. FIT-sourced rows never overwrite API-sourced rows (unless you pass --force).
Resume when the community catches up. Watch the python-garminconnect project for a fix, upgrade, and run garmin-local-mcp sync again. Thanks to resumable sync state, it picks up exactly where it stopped.

Downloading a wellness bundle, step by step

Sign in at connect.garmin.com in any browser.
Go directly to https://connect.garmin.com/app/settings/accountInformation (or click your avatar in the top-right corner, then Settings, then Account Information in the left sidebar).
Scroll to the bottom of the page, to the section titled Export Wellness Data ("Download your wellness FIT files from a specific day. This includes data such as steps, sleep, stress, HRV and more.").
Pick a date in the Date field and click Export. Your browser downloads a small zip for that one day, containing roughly 12 to 15 binary .fit files (*_WELLNESS.fit, *_SLEEP_DATA.fit, *_HRV_STATUS.fit, *_SKIN_TEMP.fit, *_METRICS.fit, and similar).

Unzip it into a folder and run:

garmin-local-mcp import-fit "path/to/unzipped/folder"

Repeat for each missing day (one bundle per date). The gaps tool or garmin-local-mcp status tells you which days need filling.

Two things worth knowing:

Overnight sleep belongs to the wake date. To get last night's sleep, export yesterday's date if you slept into this morning, i.e. the date you woke up on.
This per-day export is instant and separate from Garmin's full account export (the "Data Management" link on the same page), which is a bulk archive that can take days to arrive by email and is not what import-fit expects.

Configuration

Optional config.toml in the data directory:

Key	Default	Meaning
`timezone`	system timezone	IANA name (e.g. `America/Denver`) used to compute "yesterday" for sync ranges
`units`	`metric`	`metric` or `statute`
`request_delay_seconds`	`1.0`	Delay between API requests during sync
`baseline_window_days`	`28`	Default trailing window for the `baselines` tool

Environment variables:

Variable	Meaning
`GARMIN_MCP_DATA_DIR`	Override the data directory (default `~/.garmin-mcp`)
`GARMINTOKENS`	Override the token store location (default `<data_dir>/tokens`)
`GARMIN_EMAIL` / `GARMIN_PASSWORD`	Optional, for non-interactive re-login; when set, `garmin-local-mcp login` skips the prompts (MFA may still prompt if your account requires it)

Development

python -m venv .venv
.venv/bin/pip install -e .[dev]     # Windows: .venv\Scripts\pip install -e .[dev]
pytest
ruff check .

The test suite runs fully offline against sanitized JSON fixtures and small FIT samples; CI never touches the live API.

Disclaimer

This project is not affiliated with, endorsed by, or supported by Garmin Ltd. It uses the community python-garminconnect library with your own credentials to access your own data. Garmin's APIs are unofficial and can change or break at any time; when that happens, your synced history remains fully usable and the FIT import path keeps working.

All data stays on your machine. Nothing phones home: no telemetry, no third-party services, no cloud. Treat your data directory like the personal health record it is, and never commit it to a repository.

License

MIT

Available Tools

13 tools

anomaliesA

Outlier days (>= z standard deviations from the range mean) and sustained streaks (5+ consecutive days on one side of it).

Default: last 30 days of the core wellness metrics.

ParametersJSON Schema

Name	Required	Description	Default
`z`	No
`end`	No
`start`	No
`metrics`	No

TDQS

A3.9/5.0

Behavior4/5

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

Discloses behavioral traits: defines outlier and streak thresholds, defaults to last 30 days and core metrics. However, does not describe output format or whether it modifies data. Without annotations, this is relatively transparent but incomplete.

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?

Two short, front-loaded sentences with no redundancy. Every word adds value, defining behavior and default scope efficiently.

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?

Given moderate complexity with 4 parameters and no output schema, the description covers anomaly types and defaults but omits return format, pagination, or error conditions. Sufficient for basic understanding but not fully complete.

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

Parameters3/5

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

Schema coverage is 0%, so description must compensate. It explains z (threshold), start/end (implied by time range), metrics (core vs customized). But does not explicitly describe each parameter's usage or constraints, leaving some ambiguity.

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?

Clearly states the tool detects outlier days and sustained streaks, defining specific criteria (z standard deviations and 5+ consecutive days). Distinguishes itself from siblings like baselines or get_activity by focusing on anomaly detection.

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?

Implies default usage with 'last 30 days of core wellness metrics' but provides no explicit guidance on when to use this tool versus alternatives (e.g., query_metrics, correlate). No when-not or alternative recommendations.

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

auth_statusA

Check whether stored Garmin Connect tokens exist.

Use before sync, or when a sync failed with an auth error.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, but description implies a read-only check. Could be improved by explicitly stating no side effects, but otherwise clear.

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?

Two concise sentences with front-loaded purpose, no unnecessary words.

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 tool with no parameters and no output schema, the description fully covers its function and recommended usage scenarios.

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?

No parameters, so baseline applies. Description adds value by explaining the purpose of the tool, making it useful beyond schema.

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?

Description clearly states it checks existence of Garmin Connect tokens, distinguishing it from sibling tools like sync and sync_status.

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 advises use before sync or after an auth error, providing clear context for when to invoke this tool.

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

baselinesA

Personal mean +/- sd band per metric over a trailing window (default 28 days; default metrics: resting_hr, hrv, sleep_score, skin_temp_dev_c, stress_avg, steps).

Use to judge whether today's value is normal for this user.

ParametersJSON Schema

Name	Required	Description	Default
`metrics`	No
`window_days`	No

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description bears full weight. It explains the computation (mean and sd) and default window/metrics, but omits details like return format, data freshness, or edge cases (e.g., insufficient data).

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 description is concise: two sentences that front-load the core concept and purpose, with no redundant words.

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?

Although the tool is simple, the description lacks details on output format (e.g., structure of the band) and does not cover potential errors or data requirements. Without annotations or output schema, more completeness would be beneficial.

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 0% with no parameter descriptions. The description compensates by listing default values for both parameters and specifying the default metrics list, adding significant meaning beyond the schema.

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 clearly states it computes mean +/- sd band per metric over a trailing window and is used to judge if today's value is normal for the user. It specifies default window and metrics, making the purpose unambiguous and distinct from siblings like 'anomalies'.

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 explicitly says to use it for judging normality and references default parameters. However, it does not mention when not to use this tool or alternatives like 'query_metrics' or 'anomalies'.

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

circadianA

Estimate when this user's body clock wants them to wake up, and test that estimate against their own Garmin history. Read-only: analyses synced sleep times locally and changes nothing.

Use for "am I a morning person?", "what time should I wake up?" or "what bedtime fits me?". For whether a single night or metric was normal, use baselines or get_day; for a relationship between two metrics, correlate.

Returns three separate estimates, each with an 80% interval: chronotype (MCTQ MSFsc, mid-sleep on free days corrected for catch-up sleep), sleep need, and an inferred wake window with bedtime. Also: stability across reasonable settings, and evidence from a rolling holdout on whether waking near the window went with higher Garmin scores beyond sleep duration and regularity (consistent / supportive / suggestive / unsupported; these describe consistency on unseen nights, not statistical significance), plus a plain-language interpretation and notes. Needs 28+ nights with sleep times; evidence needs 180+ days of history. Takes well under a second.

ParametersJSON Schema

Name	Required	Description
`end`	No	Last wake date, YYYY-MM-DD. Default: yesterday.
`start`	No	First wake date, YYYY-MM-DD. Default: 180 days before end.
`detail`	No	Add the wake-time bins, the sensitivity grid, per-fold model errors and bootstrap diagnostics (output up to about 6 KB).
`outcome`	No	Garmin score to test against: readiness_score, sleep_score or body_battery_high. Default: readiness_score, else sleep_score.
`free_days`	No	Weekdays whose mornings are alarm-free, as mon..sun. Default ["sat", "sun"]; use e.g. ["fri", "sat"] for a Friday-Saturday weekend.
`sleep_need_min`	No	Your sleep need in minutes of time in bed, 240 to 720 (e.g. 480 for 8 h). Overrides the estimate from free-night sleep; useful when weekends are spent catching up.

TDQS

A4.6/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: it declares read-only behavior ('analyses synced sleep times locally and changes nothing'), data prerequisites (28+ nights, 180+ days for evidence), runtime (well under a second), and the semantics of the evidence labels (consistency on unseen nights, not statistical significance). This is well beyond what structured fields supply.

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 purpose, then routing, then returns, then requirements. Slightly long and the parenthetical acronym expansions (MCTQ MSFsc) add density, but nearly every sentence carries actionable information.

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?

No output schema and no annotations, yet the description fully describes the return structure (three estimates with 80% intervals, stability, holdout evidence with named confidence tiers, interpretation and notes) plus input requirements and runtime, so an agent has everything needed to call and interpret it.

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

Parameters3/5

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

Schema description coverage is 100%, so all six parameters are already documented in the schema. The description explains the outputs (chronotype, sleep need, wake window) but adds no parameter syntax or default detail beyond what the schema provides. Baseline 3 applies.

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?

States a specific verb and resource (estimate the user's body clock / wake time) and explicitly distinguishes itself from siblings: 'For whether a single night or metric was normal, use baselines or get_day; for a relationship between two metrics, correlate.' An agent can route 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 Guidelines5/5

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

Gives explicit trigger phrases ('am I a morning person?', 'what time should I wake up?') and names the alternative tools for adjacent questions. Clear when-to-use and when-not-to-use guidance.

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

correlateA

Pearson/Spearman correlation between two metrics (default: last 30 days).

Positive lag_days pairs metric_a on day D with metric_b on D+lag; scan_lags=True searches lags -7..+7 for the strongest relationship and returns it with a Bonferroni-adjusted p-value; if that is >= 0.05, note says the lag may be chance and a wider range is needed.

ParametersJSON Schema

Name	Required	Description	Default
`end`	No
`start`	No
`lag_days`	No
`metric_a`	Yes
`metric_b`	Yes
`scan_lags`	No

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description fully discloses the statistical behavior: lag pairing, scan_lags with Bonferroni adjustment, and the chance-lag note. This goes beyond basic semantics and informs the agent about edge cases.

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 description is compact, front-loads the core purpose, and uses precise technical language. Every sentence adds value, with no fluff or repetition.

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?

The tool has 6 parameters and no output schema; the description explains the lag-related behavior but omits details on start/end parameters and the exact return structure. For a statistical tool, an agent would benefit from knowing the result format, which is only partially hinted.

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

Parameters3/5

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

Schema coverage is 0%, so the description must explain all parameters. It clearly covers lag_days and scan_lags, and implies metric_a/metric_b, but start and end are only implied via 'default: last 30 days' without format or override details, leaving a gap.

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 states a specific verb (correlate), resource (two metrics), and method (Pearson/Spearman), clearly distinguishing it from siblings like anomalies or baselines. The default time range adds context without ambiguity.

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?

It mentions the default time range and explains the lag parameters, but does not explicitly say when to prefer this tool over alternatives or provide exclusions. The usage context is implied rather than stated.

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

gapsB

Missing days per table plus unresolved sync errors (default: first synced date through yesterday).

Use to find holes worth re-syncing before drawing conclusions.

ParametersJSON Schema

Name	Required	Description	Default
`end`	No
`start`	No

TDQS

B3.1/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavior. It mentions default date range and that it finds missing days and sync errors, but lacks detail on return format, side effects, or limits.

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?

Two concise sentences: first defines purpose, second provides usage guidance. No wasted words.

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

Completeness2/5

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

Despite conciseness, the description lacks critical details (e.g., return format, how missing days are listed) and offers no compensation for missing schema and output schema.

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

Parameters1/5

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

Schema description coverage is 0% and the description provides no information about the two parameters (start, end), leaving them completely unexplained.

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 clearly states it returns missing days per table and unresolved sync errors, which is specific and distinguishes from sibling tools like sync_status or get_day.

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?

The description gives usage guidance ('Use to find holes worth re-syncing before drawing conclusions'), but does not explicitly state when not to use or list alternatives.

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

get_activityA

Full stored summary row for one activity by id (from list_activities).

Summary fields only - no GPS or sample streams.

ParametersJSON Schema

Name	Required	Description	Default
`activity_id`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses that only summary fields are returned, not GPS or sample streams, which is useful behavioral information. However, it does not cover other traits like idempotency or rate limits.

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 description is extremely concise with two short sentences, front-loading key information (what it does and what it excludes). No filler words, making it efficient for an AI agent.

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?

Given the tool has one parameter, no output schema, and no annotations, the description provides basic purpose and a behavioral caveat (no GPS/samples), but lacks details on the return structure or any other context needed for complete understanding.

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?

The description does not add meaning beyond the schema for the single parameter activity_id. It only mentions 'by id', and with 0% schema description coverage, more detail (e.g., how to obtain the ID, expected range) would be beneficial.

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 clearly states the tool retrieves a full stored summary row for one activity by ID, and distinguishes itself from siblings like list_activities by specifying 'by id' and noting it excludes GPS/sample streams. It is specific and informative.

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?

The description implies the activity ID comes from list_activities, giving usage context, but does not explicitly state when to use this tool versus alternatives or when not to use it. More explicit guidance on prerequisites or exclusions would improve clarity.

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

get_dayA

One merged view of a single day (YYYY-MM-DD): wellness, sleep, HRV, training status, activities, and data-quality flags.

Use for 'how was ' questions.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

Describes data content but does not disclose behavioral traits (e.g., read-only nature, permissions, side effects). With no annotations, more detail would be beneficial.

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?

Two sentences, no wasted words, front-loaded with purpose and followed by usage guidance.

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?

Covers main purpose and data categories, but lacks details on output format or date range constraints. Sufficient for a simple tool.

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 description specifies the date format YYYY-MM-DD, which the schema lacks, adding value. Could be more explicit about required format.

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 clearly states the tool provides a merged view of a single day with wellness, sleep, HRV, activities, and data-quality flags, distinguishing it from siblings like get_activity and list_activities.

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?

Provides explicit usage context ('Use for 'how was <date>' questions') but does not mention alternatives or when not to use.

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

import_fitA

Import one manually exported Garmin wellness FIT bundle (folder of .fit files) - zero-auth offline ingest.

Existing API-sourced rows are never overwritten.

ParametersJSON Schema

Name	Required	Description	Default
`folder`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Without annotations, the description carries full behavioral burden. It discloses that existing API-sourced rows are never overwritten, which is a key safety trait. However, it does not mention error handling, validation, or what happens on success.

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?

Two sentences, front-loaded with the primary action, and each sentence adds value. No redundancy or fluff.

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?

Given one parameter, no output schema, and no annotations, the description covers core purpose and a key behavior. However, it lacks details on error handling, file size limits, and confirmation of success. It's functional but not exhaustive.

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 0%, so description must compensate. It adds meaning by specifying the folder contains .fit files and is a Garmin FIT bundle. However, it does not clarify path format or requirements, but for a single parameter this is adequate.

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 clearly states the verb 'Import' and the resource 'manually exported Garmin wellness FIT bundle (folder of .fit files)'. It distinguishes from siblings like 'sync' by specifying manual export and zero-auth offline ingest.

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 implies when to use: when you have a manually exported Garmin FIT bundle. It doesn't explicitly exclude alternatives, but the context of manual ingest and zero-auth sets it apart from sibling tools like 'sync' and 'sync_status'.

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

list_activitiesA

List recent activities newest-first as a compact table, filterable by type (e.g. 'running'), date range, and minimum distance.

truncated=true means more rows exist beyond the limit.

ParametersJSON Schema

Name	Required	Description	Default
`end`	No
`type`	No
`limit`	No
`start`	No
`min_distance_m`	No

TDQS

A4/5.0

Behavior4/5

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

With no annotations, description provides behavioral context: ordering (newest-first) and truncation signal ('truncated=true'). This adds value beyond the input schema, though it omits details like authentication or rate limits.

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?

Two sentences, front-loaded with main action, no filler. Every sentence adds value: the first states purpose and filters, the second explains the truncated flag.

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?

For a tool with 5 parameters and no output schema, description covers core behavior and filtering but lacks return format details (e.g., columns in the compact table). Still, it provides sufficient context for an AI agent to understand the tool's role.

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

Parameters3/5

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

Schema coverage is 0%, so description must explain parameters. It mentions filterable by type (with example 'running'), date range (implied start/end), and minimum distance, but does not explain the 'limit' parameter (default 20) nor date format. Partial coverage.

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?

Description clearly states 'List recent activities newest-first as a compact table', specifying the verb, resource, order, and format. This distinguishes it from siblings like get_activity (single activity) or query_metrics (metrics).

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?

Description implies usage for listing activities with filters but does not explicitly state when not to use it or mention alternatives. No guidance on when to use get_activity for a single activity or query_metrics for aggregated metrics.

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

query_metricsA

Columnar time series for one or more metrics (e.g. resting_hr, sleep_score, steps) between two dates.

Prefer weekly/monthly aggregate for ranges over ~60 days; stats=True adds mean/min/max/sd per metric.

ParametersJSON Schema

Name	Required	Default
`end`	Yes
`start`	Yes
`stats`	No
`metrics`	Yes
`aggregate`	No	daily

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that stats adds summary statistics and hints at aggregation behavior, but lacks details on output format, pagination, or performance implications.

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?

Two sentences, front-loaded with the core function, and each sentence adds value. No fluff.

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?

Without an output schema, the description partially explains returns ('columnar time series' and stats details). It could be more explicit about the structure, but given the tool's simplicity and sibling differentiation, it is reasonably complete.

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 0%, so the description adds meaning by explaining metrics (with examples), the role of start/end, the aggregate hint, and the stats flag. It does not cover all parameters fully, but provides significant context.

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 clearly states it is for retrieving columnar time series for specified metrics between dates, with examples. This differentiates it from siblings like get_activity or get_day, which are more specific.

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?

Provides a usage guideline: prefer weekly/monthly aggregate for ranges over ~60 days. However, it does not explicitly state when not to use or mention alternatives, but the context is clear enough.

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

syncB

Fetch up to 60 days from Garmin Connect into the local store.

Default: last 30 days ending yesterday. Use for catch-ups; multi-month backfills belong in the CLI.

ParametersJSON Schema

Name	Required	Description	Default
`end`	No
`start`	No
`endpoints`	No

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description must carry behavioral disclosure. It reveals the tool fetches data (presumably writes to local store), sets a 60-day limit, and defaults to last 30 days. However, it does not disclose write behavior (overwrite/merge), authentication requirements, or rate limits, leaving gaps.

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?

Two sentences, no fluff. Action verb upfront, default behavior stated, and usage guidance included. Every sentence adds distinct value.

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

Completeness2/5

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

The description lacks explanation of return format, error handling, and parameter details (especially 'endpoints'). For a tool with 3 undocumented parameters and no output schema, this is incomplete.

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%, so the description must explain parameters. It only implies start/end via default behavior, and 'endpoints' is mentioned but not described. This is insufficient for the 3 parameters.

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 clearly states the tool fetches up to 60 days from Garmin Connect into the local store, with a default of last 30 days. It distinguishes from multi-month backfills via CLI, but sibling tools like list_activities or get_activity are not explicitly differentiated.

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 explicitly guides use for catch-ups and advises against multi-month backfills by directing to the CLI. This provides clear when and when-not context, though alternatives among sibling tools are not named.

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

sync_statusA

Show local data coverage per table, last sync time, and pending sync errors.

Use to see what date ranges are queryable.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes the tool as read-only, showing status information. However, it does not disclose whether authentication is needed, or if the data is purely local or requires network access. The description is adequate but lacks detail on potential side effects or dependencies.

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 description is two sentences with no wasted words. It front-loads the key purpose and provides a concrete usage hint. Every sentence earns its place.

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?

Given zero parameters and no output schema, the description covers the essential information: what is shown (coverage, time, errors) and when to use it. It could be more complete by specifying what tables are included or whether the output includes error details, but it is sufficient for basic understanding.

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?

There are no parameters, and schema coverage is 100% (trivially). The description does not need to add parameter info, and it appropriately focuses on the tool's behavior. Baseline 4 is justified.

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 clearly states the tool shows local data coverage, last sync time, and pending sync errors. It also provides a usage hint about queryable date ranges. This distinguishes it from sibling tools like 'sync' (triggers sync) and 'gaps' (shows missing data), but could be more explicit about the tables covered.

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 explicitly says 'Use to see what date ranges are queryable,' which provides a specific use case. While it doesn't list when not to use it, the context of sibling tools (e.g., sync for triggering, get_activity for specific data) makes the usage relatively clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updatev0.1.9Oct 4, 2026

Changedcircadian6 fields changed

addedInput schema / properties / detail / description

Added value: +"Add the wake-time bins, the sensitivity grid, per-fold model errors and bootstrap diagnostics (output up to about 6 KB)."

addedInput schema / properties / end / description

Added value: +"Last wake date, YYYY-MM-DD. Default: yesterday."

addedInput schema / properties / free_days / description

Added value: +"Weekdays whose mornings are alarm-free, as mon..sun. Default [\"sat\", \"sun\"]; use e.g. [\"fri\", \"sat\"] for a Friday-Saturday weekend."

addedInput schema / properties / outcome / description

Added value: +"Garmin score to test against: readiness_score, sleep_score or body_battery_high. Default: readiness_score, else sleep_score."

addedInput schema / properties / sleep_need_min / description

Added value: +"Your sleep need in minutes of time in bed, 240 to 720 (e.g. 480 for 8 h). Overrides the estimate from free-night sleep; useful when weekends are spent catching up."

addedInput schema / properties / start / description

Added value: +"First wake date, YYYY-MM-DD. Default: 180 days before end."

1 tool updatev0.1.8Oct 4, 2026
- Addedcircadian
12 tool updatesv1.0.0Jul 11, 2026
- First observedanomalies
- First observedauth_status
- First observedbaselines
- First observedcorrelate
- First observedgaps
- First observedget_activity
- First observedget_day
- First observedimport_fit
- First observedlist_activities
- First observedquery_metrics
- First observedsync
- First observedsync_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-10-04 17:30 across 13 tools

Disambiguation5/5

Each tool has a clearly distinct purpose, with explicit cross-references in descriptions guiding correct selection (e.g., circadian points to baselines/get_day for normalcy and correlate for relationships). No two tools overlap enough to cause misselection; even closely related tools like sync_status and gaps are differentiated by their focus (coverage/errors vs missing days/holes).

Naming Consistency3/5

All names use snake_case, which is consistent, but the structural convention varies: some are bare nouns (circadian, baselines, anomalies, gaps), some are verb_noun (get_day, get_activity, query_metrics, list_activities), and others are status or action verbs (auth_status, sync, correlate). This mixed pattern is readable but lacks a predictable verb_noun scheme throughout.

Tool Count5/5

13 tools is well within the ideal 3-15 range and each tool earns its place, covering distinct facets of local Garmin data handling: ingestion, status, retrieval, and analysis. The set is neither bloated nor thin for the domain.

Completeness4/5

The surface covers the essential lifecycle: sync/auth, coverage checks, day-level and activity-level retrieval, time-series queries, and multiple analysis tools (correlation, baselines, anomalies, circadian). Minor gaps exist, such as no explicit tool to discover available metric names for query_metrics, and activity detail is limited to summary rows (no streams), but these are workable limitations rather than dead ends.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

MCP for OuraOAuth
link.smirnov
Multi-tenant hosted MCP server for Oura Ring — 21 read-only tools, OAuth per user.
Health & Wellness Fitness Tracking
2
Withings Health DataOAuth
io.github.akutishevsky
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Health & Wellness Research & Data
243
Coach IcarusOAuth
io.github.simkessy
Adaptive running coach MCP server — training data, plans, and recovery for AI assistants.
Fitness Tracking Health & Wellness
1
Fitness AI ConnectorOAuth
io.github.fmp-projects
Garmin data in Claude & ChatGPT via the Garmin Health API. OAuth sign-in, no password sharing.
Health & Wellness Fitness Tracking
28

Related MCP Servers

Fitness AI MCP
Health & Wellness Fitness Tracking
CSOAI-ORG
A
license
A
quality
B
maintenance
Fitness AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 10 days ago (2026-10-08 03:12 UTC)
5
9 npm
MIT
Garmin MCP
Health & Wellness Fitness Tracking
davidmosiah
A
license
B
quality
A
maintenance
Local-first MCP server that connects AI agents to your Garmin sleep, HRV, Body Battery, stress, training readiness and activities, keeping tokens on your machine.
Updated 10 days ago (2026-10-08 16:04 UTC)
2
42
125 npm
13
MIT
fitness-mcp
Health & Wellness Fitness Tracking
owenrumney
F
license
B
quality
C
maintenance
A personal remote MCP server for fitness data that provides read-only tools to query Garmin Connect activities and Hevy workouts, enabling users to list, retrieve, and analyze exercise records through natural language.
Updated 4 months ago (2026-06-23 07:27 UTC)
13
-
fitMCP
Health & Wellness Fitness Tracking Data Platforms
gzarog
F
license
Not graded
quality
D
maintenance
A multi-platform fitness MCP server that syncs data from Garmin, Strava, Google Fit, and Suunto into a local DuckDB database and provides analytics tools via MCP.
Updated 4 months ago (2026-07-01 08:59 UTC)
1
-