garmin-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GARMIN_EMAIL | No | Optional Garmin email, for machines where you can't log in interactively | |
| GARMIN_PASSWORD | No | Optional Garmin password, for machines where you can't log in interactively | |
| GARMIN_TOKEN_DIR | No | Where the Garmin session is saved. The default is ~/.garmin-mcp/tokens | ~/.garmin-mcp/tokens |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Live access to the user's Garmin Connect account.
Reporting data:
A missing field means that device doesn't track it. Never report it as zero or guess a value.
Report totals as returned by the tools rather than adding numbers up yourself.
Be specific: "4 runs, 35 km, longest 12 km on Saturday" beats "you ran a lot".
Every read calls Garmin live and Garmin rate-limits aggressively. Ask for the days you need.
Building workouts:
Workouts are written to the user's real Garmin account and can reach their watch.
For a zone-based request such as "Zone 2 run", call garmin_hr_zones and convert to bpm yourself instead of asking the user for numbers.
Write repeats out as a flat list: 5x1km is 5 interval+recovery pairs.
When the user refines a workout you just built, use garmin_workout_update. A new one leaves a duplicate on their watch.
A workout whose
sourceis another service, such as TrainingPeaks, is managed there. Your changes may be overwritten by its next sync, so tell the user that before editing one.garmin_workout_delete can't be undone. Name the workout and get a clear yes first.
If a write fails, say so plainly rather than retrying. These are undocumented Garmin endpoints.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| garmin_activitiesA | Recorded activities for the last N days, newest first, with totals: sport, distance, duration, pace, heart rate, cadence, elevation, power, training effect and load. |
| garmin_readinessA | Training readiness, recovery time, HRV against the user's baseline, training status and load (acute, chronic, ratio), VO2max, plus current endurance and hill scores. Use for "am I recovered?" or "should I go hard today?". Makes about 3 Garmin requests per day. |
| garmin_sleepC | Per night: sleep score, duration against Garmin's sleep need, deep/REM/light/awake minutes, overnight heart rate, HRV, stress, respiration and restless moments. |
| garmin_body_metricsA | Per day: body battery, steps vs. goal, distance, calories, floors, stress, heart rate range, intensity minutes, respiration, SpO2 and any weigh-in; plus current fitness age. Makes about 3 Garmin requests per day. |
| garmin_race_predictionsA | Garmin's predicted 5K, 10K, half marathon and marathon times, plus current VO2max. |
| garmin_hr_zonesA | The user's own heart-rate zones in bpm, from their Garmin settings. Call this before garmin_workout_create whenever a workout is described by zone. |
| garmin_upcoming_workoutsA | Workouts on the user's Garmin calendar for the next N days, including today. Returns each one's schedule_id (for garmin_workout_unschedule) and workout_id. |
| garmin_workouts_listA | Saved workouts in the user's Garmin library with their workout_id. Use it to find a workout to change, and to check one doesn't already exist before creating it. |
| garmin_workout_getA | One saved workout with all of its steps, in the format garmin_workout_update accepts. Repeat groups come back written out as individual steps. |
| garmin_workout_createA | Create a structured workout in Garmin Connect, ready to sync to the user's watch. Give scheduled_date to also put it on their calendar. Write repeats out as a flat list: 5x1km is 5 interval+recovery pairs. To change an existing workout, use garmin_workout_update. |
| garmin_workout_updateA | Replace a workout in place, keeping its id and calendar dates. Garmin replaces the whole workout, so pass the COMPLETE step list; read it with garmin_workout_get first if needed. |
| garmin_workout_scheduleA | Put a saved workout on the user's Garmin calendar for a date. |
| garmin_workout_unscheduleA | Remove a workout from the calendar. The workout stays in the user's library. |
| garmin_workout_deleteA | Permanently delete a workout from Garmin Connect, including from the calendar. This can't be undone: name the workout and get the user's explicit go-ahead first. Only use an id from garmin_workouts_list. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Each tool targets a distinct resource and action: library CRUD (list/get/create/update/delete), calendar operations (schedule/unschedule/upcoming), and separate read endpoints for activities, sleep, readiness, body metrics, race predictions and HR zones. The descriptions explicitly disambiguate the potentially confusable pairs (garmin_workouts_list vs garmin_upcoming_workouts, garmin_workout_delete vs garmin_workout_unschedule). No two tools appear to do the same thing.
There is a clear, mostly consistent convention: a garmin_ prefix, bare noun phrases for read endpoints (garmin_sleep, garmin_activities, garmin_body_metrics) and garmin_workout_<verb> for mutations. The main wrinkle is the odd one-out garmin_workouts_list versus the singular garmin_workout_get/create/update, which breaks the pluralization pattern within the workout family.
Fourteen tools sit comfortably in the well-scoped range, and every tool covers a distinct slice of the Garmin domain (workout lifecycle, calendar, and training/recovery reads). Nothing feels padded or redundant.
The workout lifecycle is fully covered — create, get, list, update, delete, schedule and unschedule — so there are no dead ends for the core workflow. Minor gaps remain: there is no single-activity detail tool (laps/splits/streams) and no way to duplicate a workout or manage courses/routes, but agents can work around these.