garmin-mcp-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_athlete_profileA | Get athlete profile: thresholds, HR/pace zones, FTP, weight, sport settings. Call this first in a coaching session. Zone boundaries are needed to interpret every other number, and to write workouts with correct targets. |
| list_activitiesA | List completed activities with training load, HR and elevation. Args:
oldest: Start date YYYY-MM-DD. Defaults to |
| get_activityA | Get one activity in detail, optionally with detected intervals/laps. Use for post-session analysis: how each interval actually went, HR drift, and where elevation was gained. Activity ids look like "i55751783". |
| get_activity_streamsA | Get time-series streams for an activity, downsampled to ~200 points each. Args: activity_id: e.g. "i55751783". types: Stream names. Defaults to heartrate, altitude, velocity_smooth, distance, cadence, grade_smooth. Others: watts, temp, latlng, time, moving, fixed_watts. Returns min/max/mean plus a downsampled series per stream. Full per-second data is deliberately not returned: a long trail run is >10k samples per stream and the shape is what matters for coaching, not every sample. |
| get_wellnessA | Get daily wellness: HRV, resting HR, sleep, weight, CTL/ATL, soreness. This is the autoregulation input. Check it before prescribing a hard session, and compare HRV and resting HR against the athlete's own recent baseline rather than population norms. |
| list_planned_workoutsA | List calendar events: planned workouts, notes and races. Use before writing a new week so existing plan entries are not duplicated.
Every event id returned here can be passed to |
| create_planned_workoutA | Create a structured planned workout on the Intervals.icu calendar. Intervals.icu syncs planned workouts to a connected Garmin Connect account, so this is the path for getting a session onto the watch. See the README caveat: confirm the first workout actually reaches Garmin before relying on this in a training block. Args: start_date: Local date YYYY-MM-DD. Time is forced to 00:00:00, which the API requires for calendar events. name: Short session title, e.g. "3x8min Schwelle". description: Workout in Intervals.icu syntax (see below). activity_type: "Run", "Ride", "Hike", "WeightTraining", "Swim". moving_time: Total duration in seconds. Optional; Intervals.icu derives it from the parsed description. target: "HR", "PACE" or "POWER". Use "HR" for trail and hiking work where pace is meaningless on steep terrain. training_load: Optional manual load override. external_id: Stable id of your own. Reusing it with the same date makes the call idempotent, so a re-planned week updates instead of duplicating. Workout syntax — one step per line, prefixed "- ": A bare "Nx" line on its own starts a repeated block; the following steps until the next blank line are repeated. Durations use m/s/h. Targets can be zones ("Z2"), ranges of threshold ("75-82%"), or free text for steps with no measurable target. Blank lines separate blocks. |
| delete_planned_workoutB | Delete a calendar event by its numeric id (from list_planned_workouts). |
| check_connectionA | Verify the API key works and report rate limit headroom. |
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 9 tools
Each tool targets a distinct resource and action: connection health, athlete profile, completed activities (list/detail/streams), daily wellness, and planned workouts (list/create/delete). The list/get/stream progression for activities is clear, and completed vs. planned activities are explicitly separated.
All tool names follow a consistent verb_noun snake_case pattern: get_* for singular resources, list_* for collections, create_/delete_* for mutations, and check_connection for the operational check. There is no mixing of naming conventions or vague verbs.
Nine tools is well within the ideal 3-15 range and each serves a distinct step in the coaching workflow: connection check, profile setup, activity review, wellness monitoring, and workout planning. No tool feels redundant or like padding.
The surface covers a full coaching loop: read athlete profile, review completed activities with detail and streams, check wellness/autoregulation, and manage planned workouts through list/create/delete. The idempotent create via external_id effectively covers updates, and delete is explicitly wired to list output.