Garmin MCP Server

Local-first Garmin data warehouse: sync once to SQLite, analyze trends and correlations offline.

Local serverstdioPython

What is the Garmin MCP server?

Most database access work still happens through a UI a human drives. Garmin MCP server moves it into the conversation instead. Local-first Garmin data warehouse: sync once to SQLite, analyze trends and correlations offline.

The short version

Every existing Garmin MCP server follows the same design: a thin live wrapper around Garmin's rate-limited, unofficial API. Each question your AI assistant asks becomes one or more live API calls that return huge raw JSON blobs (a single raw sleep response runs around 230 KB). Multi-month questions like "how does my sleep correlate with training load?" are impractical, and when Garmin changes its auth (as it did in March 2026, breaking the whole ecosystem), those servers go completely dark, even for data they already fetched yesterday.

  • Sync once, analyze forever. — Incremental sync into a local warehouse:
  • Server-side analysis, compact responses. — Trends, correlations, personal
  • Offline resilience. — An API breakage pauses new syncs only. Every query
  • A zero-auth fallback. — A standalone decoder for Garmin's undocumented
  • Curated tools. — 12 composable tools, not 110

The tools it exposes

The server publishes 12 tools. What each one is for:

  • 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, 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

Getting it running

The server ships on PyPI as garmin-local-mcp, so your MCP client can launch it on demand — there is no separate build step. Add the server block to your client's configuration, restart it, and the tools register themselves.

How it compares

This sits in the database access group, where several servers overlap in what they claim to do but differ sharply once you actually set them up. Garmin's toolset — auth_status, sync, sync_status and 9 more — is a fair guide to whether it matches your workflow. It is maintained by anup-shesh; worth a glance at recent repository activity before you build anything load-bearing on it.

We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.

Things to watch

  • It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
  • With 12 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch Garmin.
  • Keep per-call confirmation enabled while you learn its behaviour; it is the cheapest safeguard you have.

Available tools

ToolWhat it does
auth_statusCheck whether stored Garmin Connect tokens exist (use before sync, or after an auth error).
syncFetch up to 60 days from Garmin Connect into the local store (default: last 30 days ending yesterday; big backfills belong in the CLI).
sync_statusLocal data coverage per table, last sync time, and pending sync errors.
get_dayOne merged view of a single day: wellness, sleep, HRV, training status, activities, and data-quality flags.
query_metricsColumnar time series for one or more metrics between two dates, with daily/weekly/monthly aggregation and optional stats.
correlatePearson/Spearman correlation between two metrics, with day-lag support and an optional scan over lags -7..+7.
baselinesPersonal mean +/- sd band per metric over a trailing window (default 28 days), to judge what is normal for this user.
anomaliesOutlier days (z-score deviations) and sustained streaks (5+ consecutive days on one side of the mean).
list_activitiesRecent activities newest-first as a compact table, filterable by type, date range, and minimum distance.
get_activityFull stored summary row for one activity (summary fields only, no GPS or sample streams).
gapsMissing days per table plus unresolved sync errors, to find holes worth re-syncing before drawing conclusions.
import_fitZero-auth offline ingest of a manually exported Garmin wellness FIT bundle.

How to install the Garmin MCP server

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

Add to claude_desktop_config.json, then restart Claude Desktop.

Example prompts to try

  • Use Garmin to auth status.
  • Use Garmin to sync.
  • Use Garmin to sync status.

Frequently asked questions

It connects Garmin to MCP-compatible AI assistants such as Claude and Cursor, exposing 12 tools (auth_status, sync, sync_status, and more) that the assistant can call on your behalf. Instead of copying data back and forth by hand, the assistant works with Garmin directly.