Which integrations are available for this server?

Provides tools for fetching daily wellbeing snapshots (sleep, Body Battery, HRV, stress, Training Readiness, training status) from Garmin Connect, evaluating workloads against recovery signals, and summarizing sleep/recovery context.

How do I use Garmin MCP Server?

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 MCP Server check my Garmin wellbeing snapshot for today" 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 MCP Server

Q: What can you do with this server?

The Garmin MCP Server exposes Garmin Connect wellness and recovery metrics to AI assistants, enabling health-aware workload planning. Key capabilities include: * Daily Wellbeing Snapshot: Get a concise overview of sleep, Body Battery, HRV, stress, Training Readiness, and a workload recommendation for a given date. * Workload Guard: Evaluate a proposed workload (with optional ticket/task count) against current recovery signals and receive a safety assessment with a suggested safer daily scope when metrics are poor. * Sleep Summary: Fetch focused sleep metrics including score, duration, overnight HRV, sleep stress, Body Battery change, and resting heart rate for a specific date. * Training Load Trends: View 7-day vs. 28-day trends for key recovery metrics like sleep, HRV, stress, Training Readiness, and Body Battery. * Personal Baselines: Compute personal baseline ranges for recovery metrics over a historical window. * Change Alerts: Detect meaningful daily changes such as sleep drops, HRV dips, stress spikes, or readiness declines. * Token-Based Auth: Cache Garmin session tokens locally to avoid repeated logins. All tools default to today's date if none is provided (use YYYY-MM-DD format), and integrate with any MCP-compatible assistant such as Claude Desktop.

by Tavaresiqueira

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Garmin MCP Server

Garmin MCP Server exposes Garmin Connect wellness and recovery metrics to MCP-compatible AI assistants. It helps agents incorporate sleep, recovery, and training context when planning work.

Capabilities

Fetch daily wellbeing snapshots from Garmin Connect
Summarize sleep, Body Battery, HRV, stress, Training Readiness, and training status
Analyze short-term versus long-term recovery trends
Compute personal baseline ranges over historical windows
Highlight meaningful changes versus yesterday and baseline
Recommend an appropriate workload level from current recovery signals
Provide a guardrail tool for assistants before accepting heavy workloads
Cache Garmin session tokens locally to avoid repeated logins

Related MCP server: health-mcp

MCP Tools

Tool	Description
`garmin_training_load_trend`	Returns 7-day versus 28-day trends for sleep, HRV, stress, training readiness, and Body Battery at wake.
`garmin_baseline_profile`	Computes personal baseline ranges for recovery metrics over a historical window.
`garmin_change_alerts`	Highlights meaningful daily changes such as sleep drops, HRV dips, stress spikes, and readiness declines.
`garmin_wellbeing_snapshot`	Returns a concise daily snapshot with recovery metrics and workload recommendation.
`garmin_workload_guard`	Evaluates a proposed workload against current Garmin recovery signals.
`garmin_sleep_summary`	Returns focused sleep and recovery context for a given date.

MCP Resource

Resource	Description
`garmin://wellbeing/today`	Today's wellbeing snapshot as JSON.

MCP Prompt

Prompt	Description
`garmin_workload_guardrails`	Instructions for using Garmin context during workload planning.

Installation

npm install
npm run build

Authentication

The recommended local setup is an interactive one-time login. This writes Garmin session tokens to disk so the MCP server can run later without storing your Garmin password.

Run:

npm run login

The login command:

Prompts for your Garmin email.
Prompts for your Garmin password without echoing it to the terminal.
Authenticates with Garmin Connect.
Creates the token cache directory if it does not exist.
Writes reusable Garmin session tokens to .garmin-tokens by default.

Your password is used only for the login request. It is not written to disk.

After a successful login you should see output similar to:

Garmin MCP login
This creates a reusable local token cache. Your password is not written to disk.

Garmin email: you@example.com
Garmin password:

Login successful for Your Name.
Token cache written to C:\path\to\garmin-mcp-server\.garmin-tokens.
You can now use the Garmin MCP server without storing your Garmin password.

The MCP server loads tokens from GARMIN_TOKEN_DIR. If the variable is not set, it uses ./.garmin-tokens relative to the directory where the server process starts.

For MCP clients, prefer passing an absolute GARMIN_TOKEN_DIR in the client configuration. This avoids issues when the client starts the server from a different working directory.

Environment Variables

Create a local environment file only if you want to customize settings:

Copy-Item .env.example .env

Example .env:

GARMIN_TOKEN_DIR=.garmin-tokens
GARMIN_IS_CN=false

Supported variables:

Variable	Purpose
`GARMIN_TOKEN_DIR`	Directory used to read/write Garmin session tokens. Defaults to `.garmin-tokens`.
`GARMIN_IS_CN`	Set to `true`, `1`, `yes`, or `y` for Garmin China accounts. Defaults to Garmin global (`garmin.com`).
`GARMIN_EMAIL`	Optional email used by `npm run login` or non-interactive server startup.
`GARMIN_PASSWORD`	Optional password used by `npm run login` or non-interactive server startup. Prefer token login locally.
`GARMINCONNECT_EMAIL`	Compatibility alias for `GARMIN_EMAIL`.
`GARMINCONNECT_PASSWORD`	Compatibility alias for `GARMIN_PASSWORD`.
`GARMINCONNECT_BASE64_PASSWORD`	Compatibility password option. The value is decoded from base64 before login.
`GARMINCONNECT_IS_CN`	Compatibility alias for `GARMIN_IS_CN`.

For local development, use npm run login instead of keeping GARMIN_PASSWORD in .env. Credentials in environment variables are mainly useful for non-interactive or temporary automation.

Verify the Server Locally

After logging in and building, run:

npm run typecheck
npm run build
npm run start

npm run start launches the MCP server over stdio. It will wait for an MCP client to speak the protocol, so it may appear idle in a normal terminal. That is expected.

Claude Desktop Configuration

Add the server to your Claude Desktop MCP configuration:

{
  "mcpServers": {
    "garmin": {
      "command": "node",
      "args": ["C:\\path\\to\\garmin-mcp-server\\dist\\index.js"],
      "env": {
        "GARMIN_TOKEN_DIR": "C:\\path\\to\\garmin-mcp-server\\.garmin-tokens"
      }
    }
  }
}

Replace C:\\path\\to\\garmin-mcp-server with the absolute path where you cloned the project.

You can also place GARMIN_EMAIL and GARMIN_PASSWORD in the env block instead of using token login, but token login is preferred for local machines because it does not require storing the Garmin password in the MCP client config.

After editing the MCP client configuration, restart the client so it reloads the server definition.

Codex Configuration Example

If your MCP client uses a TOML-style server config, the same setup looks like this:

[mcp_servers.garmin]
command = "node"
args = ["C:\\path\\to\\garmin-mcp-server\\dist\\index.js"]

[mcp_servers.garmin.env]
GARMIN_TOKEN_DIR = "C:\\path\\to\\garmin-mcp-server\\.garmin-tokens"

Restart Codex after updating the config. Once loaded, the Garmin tools should be available as MCP tools:

garmin_training_load_trend
garmin_baseline_profile
garmin_change_alerts
garmin_wellbeing_snapshot
garmin_workload_guard
garmin_sleep_summary

Troubleshooting

If login fails:

Confirm the email and password work in Garmin Connect in a browser.
If your account uses Garmin China, set GARMIN_IS_CN=true.
Delete the token cache and run npm run login again if tokens become stale.

If the MCP client cannot fetch Garmin data:

Confirm npm run build has been run and dist\\index.js exists.
Use an absolute GARMIN_TOKEN_DIR in the MCP client config.
Confirm the MCP client was restarted after config changes.
Run npm run login again if Garmin has invalidated the session.

If TypeScript build fails:

npm install
npm run typecheck
npm run build

Recommended Agent Guidance

Use Garmin context as part of planning, especially when I propose a heavy workload, late-day push, risky refactor, production change, or many tickets in one day.

Before agreeing to heavy work, call garmin_workload_guard or garmin_wellbeing_snapshot.

If sleep, Body Battery, HRV, stress, or Training Readiness are poor, push back concretely: reduce ticket count, split the work, defer risky items, and create a stopping point.

Do not moralize or diagnose health. Treat the metrics as planning context, not medical advice.

If Garmin data is unavailable, say that plainly and fall back to normal workload planning.

Development

npm run dev
npm run login
npm run typecheck
npm run build

Security

Do not commit .env or token cache directories.
Prefer token reuse over repeated credential logins.
Treat all Garmin data as private health-related context.

Available Tools

3 tools

garmin_sleep_summaryGarmin sleep summaryB

Fetch Garmin sleep score, duration, overnight HRV, sleep stress, Body Battery change, and resting heart rate.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. Defaults to today.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided; the description only says 'fetch', implying a read operation, but does not disclose potential data unavailability (e.g., if no sleep data for the date), rate limits, or whether all listed metrics are always returned.

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 a single direct sentence listing the fetched metrics, perfectly concise with no wasted 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?

For a simple one-parameter tool without output schema, the description covers the core action but lacks completeness about return format, data availability, and behavioral guarantees.

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 100% with the date parameter fully described in the schema (format and default). The description does not add new 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 the tool fetches specific sleep metrics (score, duration, HRV, stress, Body Battery, resting HR), which distinguishes it from siblings like wellbeing snapshot or workload guard.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, no prerequisites or exclusions mentioned, leaving the agent to infer usage context.

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

garmin_wellbeing_snapshotGarmin wellbeing snapshotB

Fetch a concise Garmin Connect wellbeing snapshot for a date: sleep, Body Battery, HRV, stress, training readiness, and a workload recommendation.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. Defaults to today.
`includeRaw`	No	Include raw Garmin responses for debugging.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It indicates a read operation but does not disclose authentication needs, rate limits, or behavior on missing dates. Minimal behavioral context.

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?

Single sentence is highly concise and front-loaded with the key purpose and included metrics. No wasted 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?

Adequate for a simple fetch tool with two parameters and no output schema. Lists what is included but lacks details on error handling or response structure.

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 100%, so the description adds little beyond schema. 'For a date' aligns with the date parameter. Baseline 3 is appropriate as schema does the heavy lifting.

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 the verb 'Fetch', the resource 'wellbeing snapshot', and lists specific metrics (sleep, Body Battery, HRV, stress, training readiness, workload recommendation). It effectively distinguishes from sibling tools like garmin_sleep_summary and garmin_workload_guard.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, or any prerequisites. The description only mentions 'for a date' without context on data availability or limitations.

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

garmin_workload_guardGarmin workload guardA

Check Garmin recovery metrics before committing to a workload and suggest a safer daily scope when signals are weak.

ParametersJSON Schema

Name	Required	Description
`workload`	Yes	The work the user wants to take on.
`ticketCount`	No	Number of tickets/tasks being considered.
`date`	No	Date in YYYY-MM-DD format. Defaults to today.

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It states the tool checks recovery metrics and suggests a safer scope, implying read-only behavior, but does not disclose specific metrics, side effects, or authorization needs. More detail on the suggestion mechanism would improve transparency.

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?

A single, well-structured sentence that front-loads the main action and purpose. Every word contributes meaning; no redundancy.

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?

While the description covers purpose and usage, it lacks detail on what recovery metrics are used, how the safer scope is determined, and what the tool returns. With no output schema, the description should hint at the output format.

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?

All three parameters have schema descriptions, so schema coverage is 100%. The description adds little beyond the schema—'workload' as the work to take on, 'ticketCount' as number of tasks, 'date' as YYYY-MM-DD. Baseline 3 is appropriate.

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 checks Garmin recovery metrics before committing to a workload and suggests a safer daily scope when signals are weak. This distinguishes it from siblings like garmin_sleep_summary and garmin_wellbeing_snapshot by focusing on workload readiness.

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 'before committing to a workload,' indicating when to use. However, it does not provide explicit when-not-to-use or alternative tools, though the context of siblings implies differentiation.

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.

3 tool updatesv1.0.0Jun 19, 2026
- First observedgarmin_sleep_summary
- First observedgarmin_wellbeing_snapshot
- First observedgarmin_workload_guard

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

B3.4/5.0

Scored 2026-06-19 20:20 across 3 tools

Disambiguation3/5

The sleep_summary and wellbeing_snapshot tools overlap significantly, as wellbeing_snapshot includes sleep data and more. An agent may be unsure which to use for sleep metrics alone, though descriptions help differentiate scope.

Naming Consistency4/5

All tools follow a consistent 'garmin_<area>_<descriptor>' pattern using underscores. While not verb_noun, the naming is predictable and readable.

Tool Count4/5

Three tools is slightly low for a comprehensive health tracking server, but the set covers key recovery and readiness metrics without being trivial.

Completeness3/5

The tools focus on sleep, wellbeing, and workload recovery but lack common Garmin features like activity logs, steps, or heart rate trends, creating notable gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

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
23
SomviaOAuth
app.somvia
Apple Health training load, recovery, HRV and workout detail for Claude, ChatGPT and any MCP client.
Health & Wellness Fitness Tracking
2
Garmin — MissingMCPOAuth
com.missingmcp
Garmin data in Claude: 135 tools — activities, sleep, HRV, training, workouts. Free, open source.
Health & Wellness Fitness Tracking
210
Nutrition by Pack4Back BOAuth
com.pack4back
Log meals, water, and weight to Garmin Connect from Claude or ChatGPT.
Fitness Tracking Health & Wellness
121

Related MCP Servers

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 25 days ago (2026-08-29 10:26 UTC)
42
193 npm
12
MIT
health-mcp
Health & Wellness Fitness Tracking
jonathan249
A
license
Not graded
quality
D
maintenance
Exposes personal Garmin wellness data through MCP tools for accessing summary, sleep, HRV, heart rate, stress, body battery, and historical data.
Updated 3 months ago (2026-06-12 18:45 UTC)
MIT
WHOOP MCP Server
Health & Wellness Fitness Tracking
Tavaresiqueira
A
license
A
quality
D
maintenance
Exposes WHOOP recovery, sleep, strain, and workout metrics to MCP-compatible AI assistants using OAuth 2.0 authentication, enabling daily wellbeing snapshots, trend analysis, and workload recommendations.
Updated 3 months ago (2026-06-20 17:34 UTC)
6
412 npm
MIT
Garmin MCP Server
Fitness Tracking Health & Wellness
k8sautom8
A
license
Not graded
quality
D
maintenance
Connects to Garmin Connect and exposes your fitness and health data to OpenWebUI, Claude, or any MCP-compatible client via Streamable HTTP transport.
Updated 10 months ago (2025-11-20 08:48 UTC)
7
MIT