Which integrations are available for this server?

Provides read-only access to Garmin Connect health data, including sleep, HRV, body battery, stress, training readiness, activities, and more.

How do I use garmin-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-mcp how did I sleep last night?" 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

by nbaradar

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

garmin-mcp

An MCP server that gives an LLM read-only access to your own Garmin Connect health data — sleep, HRV, body battery, stress, training readiness, activities and more.

Runs locally over stdio; switches to authenticated HTTP for remote use with environment variables only.

Heads up. Garmin's official Health API is partner-only and rejects personal-use applications, so this uses Garmin's private Connect API via python-garminconnect. That's against Garmin Connect's terms of service and can break without notice — it did in March 2026, when Garmin tightened its bot protection. Fine for personal use; don't build anything load-bearing on it.

Requirements

Python 3.12+ (garminconnect requires it — uv handles this for you)
uv
A Garmin Connect account

Related MCP server: health-mcp

Setup

uv sync
uv run garmin-mcp-login

Run the login from a normal terminal, not an elevated/Administrator one. On Windows an elevated process writes the token file with permissions that exclude your ordinary user account. Login appears to succeed, then every client that isn't elevated fails with Access is denied — see Troubleshooting. The command warns and asks for confirmation if it detects this.

garmin-mcp-login asks for your email, password and MFA code once, then writes session tokens to ~/.garminconnect/. Your password is used to obtain those tokens and is never stored.

This is a separate command for a reason: Garmin logins can require an MFA code, and an MCP server talking JSON-RPC over a pipe has nowhere to prompt. The server only ever reads the token file, and garminconnect refreshes the tokens on its own — you shouldn't need to log in again unless the refresh token expires or you revoke access.

Re-running the command is safe; it checks the existing tokens first and exits without asking for anything if they still work. Don't re-run it speculatively when something breaks — Garmin rate-limits login attempts per IP, and repeated tries make it worse. Almost every failure has a cause other than a dead token; check the log first.

Use it with Claude Code

Copy .mcp.json.example to .mcp.json and set the absolute path to your checkout (.mcp.json is gitignored, since it is machine-specific). Or register it globally:

claude mcp add garmin -- uv --directory /path/to/garmin-mcp run garmin-mcp

Use it with Claude Desktop

Add it to claude_desktop_config.json — on Windows %APPDATA%\Claude\, on macOS ~/Library/Application Support/Claude/:

{
  "mcpServers": {
    "garmin": {
      "command": "/absolute/path/to/uv",
      "args": ["--directory", "/absolute/path/to/garmin-mcp", "run", "garmin-mcp"],
      "env": { "GARMINTOKENS": "/absolute/path/to/home/.garminconnect" }
    }
  }
}

Three things matter here, each of which will otherwise fail silently:

Use an absolute path to uv. Claude Desktop does not inherit your shell PATH, so a bare uv is not found. which uv / (Get-Command uv).Source gives you the path.
Set GARMINTOKENS to an absolute path. ~ resolves against the environment of whatever launched the process, which is not necessarily your shell's.
You do not run the server yourself. Desktop spawns it on launch and kills it on quit; in stdio mode it has no port and nothing to attach to. After changing config, fully quit Desktop (tray icon → Quit) — closing the window leaves it running with the old config.

Then ask things like "how did I sleep last night?", "am I recovered enough to train hard today?", or "how did my resting heart rate trend over the last month?"

To check it by hand instead:

uv run mcp dev src/garmin_mcp/server.py     # MCP Inspector

Tools

Date arguments are deliberately permissive, because a model writes dates the way a person would:

keywords — today, yesterday, last night, last week, last month
offsets — -7d, 7d, 2 weeks ago, a month ago (unsigned means the past; only +3d looks forward)
absolute — 2026-08-02, 2026/08/02, 2026-08-02T22:15:00Z

Sleep is recorded against the morning it ends, so last night's sleep is date=today (and last night maps there too).

A rejected date fails the call before any network request, which is invisible in the response — so unrecognised values are logged with their arguments rather than failing silently.

Tool	What it returns
`garmin_get_health_snapshot`	Summary + sleep + HRV + body battery + readiness for one day, in one call
`garmin_get_daily_summary`	Steps, distance, floors, calories, intensity minutes, resting HR, stress
`garmin_get_sleep`	Sleep score and components, stage durations, overnight SpO2 and respiration
`garmin_get_hrv`	Overnight HRV, weekly average, baseline range, HRV status
`garmin_get_stress`	Average/max stress and the rest/low/medium/high split
`garmin_get_heart_rate`	Resting, min and max HR, seven-day resting average
`garmin_get_training_readiness`	Readiness score plus the factors behind it
`garmin_get_body_battery`	Daily high/low, charge and drain, over a range
`garmin_get_steps`	Daily step totals, goal and distance, over a range
`garmin_list_activities`	Recorded workouts in a range, with IDs
`garmin_get_activity`	Full detail for one workout by ID
`garmin_get_body_composition`	Weigh-ins: weight, BMI, body fat, muscle and bone mass
`garmin_get_user_profile`	Name, height, weight, and your measurement system
`garmin_api_request`	Any Garmin API path directly — the escape hatch

Every tool is annotated readOnlyHint: true. Nothing here can modify your Garmin account.

Why responses look trimmed

Garmin returns per-minute sample series; a single get_sleep_data call can exceed 100KB of JSON. By default those series are replaced with a marker like {"_omitted": "480 samples omitted; call again with detail='full' to include them"} and long lists are truncated to 8 entries.

Pass detail="full" when the individual data points actually matter.

Adding more endpoints

garminconnect exposes ~140 methods; 13 are wired up above. Adding another is one row in src/garmin_mcp/tools.py:

ToolSpec(
    name="garmin_get_spo2",
    method="get_spo2_data",          # any method on the garminconnect client
    title="Pulse oximetry",
    shape=Shape.DAILY,               # NONE | DAILY | RANGE
    description="Get overnight blood oxygen saturation for one day: ...",
),

Date parsing, payload trimming, read-only annotations, JSON serialisation and error handling all come from the registry (src/garmin_mcp/registry.py) — there is no function to write.

The three shapes map to how the underlying method takes arguments:

Shape	Signature	Tool parameters
`Shape.NONE`	`method()`	`detail`
`Shape.DAILY`	`method(cdate)`	`date`, `detail`
`Shape.RANGE`	`method(startdate, enddate)`	`start_date`, `end_date`, `detail`

Endpoints that don't fit — anything taking an ID, or fanning out across several calls — are written as ordinary @mcp.tool() functions in server.py; garmin_get_activity is the example to copy.

A test asserts every method in the table exists on the Garmin client, so a typo fails the suite rather than surfacing at call time.

Explore before you commit to a row. Use garmin_api_request to try an endpoint, and promote it once you find yourself reaching for it repeatedly.

Running remotely

Nothing in the code is stdio-specific. Set the environment and it serves HTTP instead:

export GARMIN_MCP_TRANSPORT=streamable-http
export GARMIN_MCP_AUTH_TOKEN="$(openssl rand -hex 32)"
export GARMIN_MCP_HOST=0.0.0.0
uv run garmin-mcp

Clients then send Authorization: Bearer <token> to http://host:8000/mcp.

Variable	Default	Purpose
`GARMIN_MCP_TRANSPORT`	`stdio`	`stdio` or `streamable-http`
`GARMIN_MCP_HOST`	`127.0.0.1`	HTTP bind address
`GARMIN_MCP_PORT`	`8000`	HTTP port
`GARMIN_MCP_AUTH_TOKEN`	—	Required for HTTP. Shared bearer secret
`GARMINTOKENS`	`~/.garminconnect`	Token store path — mount as a secret in a container
`GARMIN_MCP_LOG_LEVEL`	`INFO`	Log verbosity (stderr)

Notes for when you deploy:

The server refuses to start over HTTP without GARMIN_MCP_AUTH_TOKEN. Otherwise a missing variable would quietly publish your health data. The token is compared in constant time.
HTTP runs stateless with plain JSON responses, so there's no session affinity to preserve — restart or replicate freely.
Run garmin-mcp-login somewhere interactive and ship the resulting token file as a mounted secret; the server never needs your password.
Terminate TLS in front of it. The bearer token is a shared secret and plain HTTP would leak it.
For multi-user or proper OAuth, the SDK's AuthSettings / token_verifier hooks are untouched and additive — swap out _BearerAuth in server.py.

Development

uv run pytest

108 tests, fully offline — no credentials or network required. They cover date parsing, payload trimming, config validation, all three registry shapes, tool registration, the health-snapshot fan-out, and the HTTP bearer guard.

Diagnosing problems

Read the log before changing anything. The server writes every failure to stderr, including the tool name, the exception, and the arguments that caused it. MCP clients don't surface arguments anywhere, so this log is usually the only place the real cause appears.

Claude Desktop captures it per server:

# Windows
Get-Content "$env:APPDATA\Claude\logs\mcp-server-garmin.log" -Tail 30 -Wait

# macOS
tail -f ~/Library/Application\ Support/Claude/logs/mcp-server-garmin.log

mcp.log alongside it covers connection-level problems. Under HTTP transport the same output goes to your terminal instead.

Two signals worth knowing:

A tool that fails in a few milliseconds never reached Garmin. A real API call takes 100ms+; anything faster failed during argument parsing or before authentication.
Garmin session established appears in the log on every successful login. Its absence means authentication never succeeded, regardless of what the error says.

Troubleshooting

"Access is denied" / "not permitted to read it" — the token store was written by an elevated (Administrator) terminal, so its permissions exclude your normal user account. It then works from that terminal and fails everywhere else, which makes it look intermittent. Re-authenticating does not fix this — it would rewrite a file the client still can't read. Grant your account access instead, which keeps your existing token:

icacls "$env:USERPROFILE\.garminconnect" /grant "$env:USERNAME:(OI)(CI)F" /T

Then run garmin-mcp-login from a non-elevated terminal in future.

"session could not be refreshed just now" — the token is intact and this is usually Garmin rate-limiting the connection. Wait a minute; the server also retries once automatically. Don't re-authenticate unless it persists.

"no token store" — run uv run garmin-mcp-login.

Any authentication error, generally — garminconnect reports an expired token, a rate-limited refresh, and an unreadable token file with the same message (Username and password are required), because it performs the refresh network call inside the same error handler as the token file read. This server classifies them and tells you which one it actually is. Trust that classification over the raw library message.

Login fails mentioning Cloudflare or a 403 — Garmin likely changed its bot protection. Upgrade first: uv sync --upgrade-package garminconnect.

"Garmin is rate limiting" — wait a minute. Prefer one wide date range over many single-day calls.

A date argument is rejected — the parser accepts a wide range of forms, but not everything. The log line names the exact value it received.

A metric comes back empty or errors inside garmin_get_health_snapshot — usually means your device doesn't record it, or hasn't synced. The snapshot deliberately reports per-metric errors instead of failing the whole call. Note that a night with no recorded sleep returns a valid response with null fields, which is data absence, not an error.

Available Tools

14 tools

garmin_api_requestRaw Garmin API requestA

Read-onlyIdempotent

Call any Garmin Connect API path directly. This is the escape hatch for the ~130 endpoints without a dedicated tool (SpO2, respiration, VO2 max, race predictions, gear, workouts, badges, and so on). Prefer a dedicated tool when one exists -- their output is easier to read and their arguments are validated. Paths look like '/usersummary-service/stats/daily/2026-08-01/2026-08-03'; the response is returned as-is.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Garmin Connect API path, beginning with '/', e.g. '/wellness-service/wellness/dailySpo2/2026-08-01'.
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary
`params`	No	Optional query string parameters.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that responses are returned as-is with no processing, and provides path format guidance, which is useful context beyond the annotations. It doesn't cover error handling or rate limits, but those are less critical given the annotation safety profile.

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?

Three sentences, front-loaded with purpose, then usage guidance and an example. Every sentence earns its place with no redundancy or fluff.

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?

With full parameter schema coverage, strong annotations, and a clear escape-hatch role, the description covers the essential context: what it does, when to use it, and what to expect in the response. No output schema is needed because the response is intentionally raw, and the description explicitly says so.

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?

Input schema covers all 3 parameters with detailed descriptions and examples, so the description doesn't need to repeat them. It reinforces the path format with an example, but the main semantic payload already lives in the schema, so the description adds little beyond a baseline.

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 opens with 'Call any Garmin Connect API path directly' and clarifies its role as the escape hatch for ~130 endpoints without a dedicated tool, listing example data types. This clearly distinguishes it from the sibling-specific tools, which each target a single resource.

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 instructs to prefer a dedicated tool when one exists, citing easier-to-read output and validated arguments. It also gives a concrete example path and notes the response is raw, making the when-to-use decision unambiguous.

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

garmin_get_activityActivity detailA

Read-onlyIdempotent

Get the full record of one recorded workout by its activity ID: type, timing, distance, pace and speed, heart rate zones, cadence, power, elevation, calories, training effect and recovery time. Find the ID with garmin_list_activities first.

ParametersJSON Schema

Name	Required	Description	Default
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary
`activity_id`	Yes	Garmin activity ID, as returned in the 'activityId' field of garmin_list_activities.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is clear. The description adds value by enumerating the exact data fields returned (type, timing, distance, etc.), giving the agent a concrete expectation. The 'detail' parameter description also warns that 'full' can be enormous, which is useful behavioral context. No contradiction with annotations.

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, with the main purpose in the first and a prerequisite in the second. No repetition of schema details, no fluff. The content is front-loaded and every phrase earns its place.

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?

Given the simple complexity (2 params, no output schema, strong annotations), the description is complete. It lists the return contents, specifies the prerequisite workflow, and the parameter descriptions handle the summary/full choice. No critical information is missing for an agent to select and invoke the 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?

Schema coverage is 100%: both parameters have meaningful descriptions. The description adds extra guidance by pointing to garmin_list_activities for finding the ID, which reinforces the activity_id semantics beyond the schema. The 'detail' enum is thoroughly explained with use-case advice.

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 ('Get'), a specific resource ('full record of one recorded workout'), and the method (by activity ID). It clearly distinguishes from sibling tools by focusing on individual activity details versus daily summaries or user profile data.

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 instructs to find the ID with garmin_list_activities first, giving a clear usage workflow. The parameter description for 'detail' further explains when to use 'summary' vs 'full', providing effective context. However, it does not explicitly contrast with other sibling getters like garmin_get_daily_summary, so it misses a full 'when-not-to-use' clause.

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

garmin_get_body_batteryBody batteryA

Read-onlyIdempotent

Get body battery energy levels across a date range: the daily high and low, plus charge and drain totals. Body battery rises with rest and falls with activity and stress, so a multi-day range shows whether energy is trending down faster than it recovers.

ParametersJSON Schema

Name	Required	Description	Default
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary
`end_date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today
`start_date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	-7d

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by explaining the semantics (rises with rest, falls with activity/stress) and the return fields (high/low, charge/drain totals), which helps the agent interpret results without contradicting the annotations.

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, front-loaded sentences. The first sentence states what the tool does; the second adds useful interpretive context. No redundant phrases or filler, every clause earns its place.

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 simple read-only tool with no output schema, the description tells the agent what to expect (daily high/low, charge/drain totals) and why it matters (trending vs recovery). Combined with the rich parameter schema and safety annotations, the tool is fully described with no obvious gaps.

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?

The input schema covers all three parameters with detailed descriptions (date formats, relative values, and the summary/full detail distinction), so schema coverage is 100%. The description only refers generically to 'a date range' and doesn't add parameter-specific details beyond what the schema provides, landing at the baseline.

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 uses a specific verb ('Get') and names the exact resource ('body battery energy levels') plus the date-range scope. It lists the specific data returned (daily high/low, charge/drain totals), which clearly distinguishes it from sibling tools like garmin_get_stress or garmin_get_hrv.

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 gives a clear use case: analyzing multi-day energy trends, with the explanatory note about how body battery rises with rest and falls with activity/stress. It doesn't explicitly mention alternatives or exclusions, but the context is sufficient to infer when this tool is appropriate.

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

garmin_get_body_compositionBody compositionA

Read-onlyIdempotent

Get weigh-ins over a date range: weight, BMI, body fat and water percentage, muscle and bone mass, plus the range averages. Only returns data for days with a recorded weigh-in, so an empty result usually means no measurement rather than an error.

ParametersJSON Schema

Name	Required	Description	Default
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary
`end_date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today
`start_date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	-7d

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond this: it only returns days with a recorded weigh-in and explains that empty results indicate missing data, not an error. This is meaningful and does not contradict any annotations.

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. The first sentence front-loads the purpose, and the second adds an important caveat. No wasted words, ideal for quick AI parsing.

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?

With no output schema, the description carries the burden of explaining return values. It lists the key metrics returned and explicitly addresses empty-result behavior. Combined with comprehensive schema descriptions and annotations, the tool is fully specified for a read-only retrieval operation.

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 the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides (e.g., detail enum, date formats). The description's mention of returned fields complements but does not override or deepen parameter understanding.

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 gets weigh-ins over a date range and lists specific metrics (weight, BMI, body fat, water percentage, muscle and bone mass, range averages). This is a specific verb+resource with concrete data fields, making it distinct from sibling tools that retrieve other health metrics.

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 gives clear context: it returns weigh-in data for a date range and notes that an empty result means no measurement was recorded. While it doesn't explicitly mention when to use an alternative sibling tool, the context is sufficient for an agent to select this tool for body composition-related queries.

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

garmin_get_daily_summaryDaily summaryA

Read-onlyIdempotent

Get the all-round wellness summary for one day: total and goal steps, distance, floors, calories (active, resting, consumed), intensity minutes, resting heart rate, average stress, and body battery high/low. Start here for broad questions like 'how active was I on Tuesday' -- it answers in one call what would otherwise take several.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the context that this is a multi-metric aggregate summary, and the schema's `detail` parameter explains the summary/full payload trade-off. It does not discuss potential quirks like missing data or timezone behavior, so it adds moderate but not extensive 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?

The description is two sentences, both packed with information. The first concisely lists the returned metrics; the second provides clear use-case guidance. No wasted words or repetition, and key information is front-loaded.

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?

The tool is a low-complexity read-only retrieval with no output schema. The description lists all major categories of returned data, and the schema covers parameters well. It lacks only minor operational details (e.g., behavior on unavailable data), which are not critical for this type of tool. Overall, it is complete enough for an agent to invoke correctly.

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%: both `date` and `detail` have thorough descriptions with relative date syntax and the summary/full distinction. The description itself does not mention parameters, but the schema fully carries the burden. 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 a specific verb and resource: 'Get the all-round wellness summary for one day' and enumerates the included metrics (steps, distance, floors, calories, etc.), distinguishing it from specialized siblings like garmin_get_sleep or garmin_get_heart_rate. It also frames its role as the aggregate summary tool.

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 provides explicit usage guidance with 'Start here for broad questions like "how active was I on Tuesday"' and notes it 'answers in one call what would otherwise take several,' implying aggregation. However, it does not explicitly name alternative tools or state when not to use it, missing full exclusion guidance.

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

garmin_get_health_snapshotHealth snapshotA

Read-onlyIdempotent

Get an all-in-one recovery picture for one day: daily summary, sleep, HRV, body battery and training readiness together. Prefer this for open questions like 'how did I sleep', 'how am I recovering' or 'should I train today' -- it answers in one call what would otherwise take five, and each metric is trimmed to its headline numbers. Metrics your device does not record are reported as errors within the result rather than failing the whole call.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today

TDQS

A4.7/5.0

Behavior5/5

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

Beyond annotations (readOnly, idempotent), the description discloses that metrics are trimmed to headline numbers and that unsupported metrics are reported as errors within the result rather than failing the call. This adds meaningful behavioral context beyond the annotations.

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 with no fluff: the first states purpose and contents, the second gives usage guidance and error behavior. Highly concise and front-loaded.

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?

With one parameter, no output schema, and rich annotations, the description provides sufficient context for an agent: what is included, when to use it, and how errors are handled. The tool is simple enough that this description is 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 description coverage is 100% for the single `date` parameter, which fully explains format and defaults. The description adds no additional parameter detail, so the baseline of 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 provides an all-in-one recovery picture for a single day, listing the included metrics (daily summary, sleep, HRV, body battery, training readiness). This distinguishes it from sibling metric-specific tools like garmin_get_sleep or garmin_get_hrv.

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?

Explicit guidance is given: prefer this for open questions like 'how did I sleep' or 'should I train today', and it notes this replaces five separate calls. This clearly signals when to use it over the individual metric tools.

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

garmin_get_heart_rateHeart rateA

Read-onlyIdempotent

Get heart rate for one day: resting, minimum and maximum heart rate, and the last seven days' resting average. Use detail='full' for the continuous all-day heart rate series. For heart rate during a specific workout, use garmin_get_activity instead.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond this: it discloses the granularity of data (summary stats vs. continuous series) and warns that 'full' returns an 'accurate but potentially enormous' payload. No contradiction exists between description and annotations.

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 purpose, followed by a parameter tip and a sibling-tool alternative. Every sentence earns its place with zero redundancy. Highly concise and well-structured.

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 simple two-parameter read tool with rich annotations and thorough schema descriptions, the description provides enough context for correct selection and invocation. It explains what outputs to expect (resting, min/max, 7-day average), covers the full-detail option, and names the alternative for workout data. No output schema exists, but the description fills that gap adequately.

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%, and the schema already thoroughly explains both 'date' and 'detail' parameters, including defaults and trade-offs. The description only briefly mentions detail='full' for continuous series, which is already in the schema, adding no new parameter-level meaning. Baseline 3 applies because the schema carries the load.

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 ('Get'), resource ('heart rate'), and scope ('for one day') along with specific outputs (resting, min/max, 7-day average). It also distinguishes from the sibling tool garmin_get_activity by directing workout-specific heart rate queries there. This is a specific, actionable purpose statement.

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 says when to use this tool (for daily heart rate summary) and when not to (for workout-specific heart rate, use garmin_get_activity instead). Also provides guidance on the 'detail' parameter, recommending 'summary' for most cases and cautioning that 'full' is potentially enormous. This is excellent usage direction.

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

garmin_get_hrvHeart rate variabilityA

Read-onlyIdempotent

Get overnight heart rate variability for one day: the weekly average, last night's average, the personal baseline range, and Garmin's HRV status (balanced, unbalanced, low, poor). HRV is the most sensitive single indicator of accumulated stress or illness, so prefer this when asked about recovery trends rather than a single night's sleep.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds context about the temporal scope ('one day'), the specific data included (weekly vs last night averages, baseline range, status), and the typical use case. It does not mention any side-effect or hazardous behavior, which is appropriate for a read-only operation.

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 long, with the first sentence delivering the core functionality and outputs, and the second sentence providing usage context. Every word earns its place; there is no redundancy or filler, making it highly efficient.

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 the tool's moderate complexity, the description covers the key aspects: what it returns, the one-day scope, and when to prefer it. The schema handles parameter details, and no output schema exists, so the description adequately informs the agent about expected behavior. It could mention the return format, but that is not critical for selection.

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?

The input schema provides 100% coverage with clear descriptions for both 'date' and 'detail', including relative date syntax and the warning that 'full' can be 'potentially enormous'. The description does not need to add further parameter details since the schema is already comprehensive, and it adds no extra parameter-specific nuance beyond what is documented.

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 'overnight heart rate variability for one day' and enumerates specific outputs (weekly average, last night's average, baseline range, HRV status). It uses a specific verb 'Get' and a distinct resource, making it easy to understand its function and differentiate from sibling tools.

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?

The description explicitly advises to 'prefer this when asked about recovery trends rather than a single night's sleep,' which contrasts with the sleep tool. It also provides rationale ('HRV is the most sensitive single indicator of accumulated stress or illness'), giving clear guidance on when to use it over alternatives.

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

garmin_get_sleepSleepA

Read-onlyIdempotent

Get sleep for the night ENDING on the given date: overall sleep score and its component ratings, time in deep/light/REM/awake, sleep and wake times, average overnight SpO2, respiration and resting heart rate. Ask for 'today' to get last night. With detail='full' this also returns per-minute sleep stage, movement and heart rate series, which are large.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly and idempotent, so the description adds behavioral context beyond them: it clarifies the date boundary ('night ENDING'), introduces the impact of 'today' vs. a calendar date, and warns that detail='full' returns large per-minute series. This provides useful caution for usage without contradicting the annotations.

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 that are packed with useful information and no fluff. The first sentence defines the primary purpose and the key data fields; the second clarifies the 'today' special case and the full-detail trade-off. Every sentence earns its place.

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 output schema, the description is remarkably complete: it enumerates the fields returned, explains the date interpretation, and flags the payload size for full detail. Combined with rich annotations and a fully covered input schema, an agent has enough context to invoke the tool correctly.

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 100% with descriptions for both 'date' and 'detail'. The description adds further semantic value by explaining the night-ending convention and explicitly linking 'today' to last night's data, as well as stressing the large size of full detail output. This goes beyond the schema's basic format and defaults.

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 gets sleep data for the night ending on a given date, listing specific metrics like sleep score, time in stages, SpO2, respiration, and heart rate. This specific verb+resource clearly distinguishes it from sibling tools like Garmin's daily summary or HRV tools.

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 provides clear context on when to use the tool: it is for sleep data, and explicitly advises using 'today' for last night's sleep. It does not mention alternatives or exclusions, but the scope is well-defined enough for an agent to select the tool appropriately.

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

garmin_get_stepsDaily stepsA

Read-onlyIdempotent

Get daily step totals, step goal and distance for each day in a range. Cheap and compact -- prefer this over repeated daily-summary calls when the question is only about step counts over time.

ParametersJSON Schema

Name	Required	Description	Default
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary
`end_date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today
`start_date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	-7d

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds 'Cheap and compact,' which discloses performance and response-size traits beyond the annotations, and the schema's detail parameter further warns about 'full' being potentially enormous. This is valuable behavioral context, though not exhaustive.

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: the first front-loads the purpose, the second provides usage guidance. Every word earns its place, with no filler or redundancy.

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?

The tool is simple, read-only, and fully covered by rich schema descriptions and safety annotations. The description states what data is returned (step totals, goal, distance) and when to prefer it, making it complete for an agent to select and invoke correctly without needing an output schema.

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%, with each parameter (detail, end_date, start_date) fully explained including formats and behavior. The description's phrase 'in a range' aligns with the start/end date parameters but adds no new semantic detail beyond what the schema already provides, so the baseline of 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 opens with 'Get daily step totals, step goal and distance for each day in a range,' using a specific verb and resource. It also distinguishes itself from the sibling daily-summary tool by explicitly recommending this tool for step-only questions, making its purpose unmistakable.

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?

The description explicitly says 'prefer this over repeated daily-summary calls when the question is only about step counts over time,' giving clear when-to-use guidance and naming the alternative. This directly helps the agent choose between this tool and garmin_get_daily_summary.

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

garmin_get_stressStressA

Read-onlyIdempotent

Get stress for one day: the average and maximum stress score, plus how the day divided between rest, low, medium and high stress. Use detail='full' for the underlying per-interval stress series.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds behavioral detail about what the summary contains and that 'full' returns a per-interval series. No contradictions with annotations.

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 action. Each clause carries specific information: what is returned, the stress categories, and when to request the full series. No filler or redundant wording.

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 simple read-only tool with only 2 parameters, fully described in the schema, and no output schema, the description adequately explains return contents and the optional full-detail mode. It is complete for practical use.

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%: both 'date' and 'detail' have detailed descriptions. The description reinforces 'Use detail='full'' but adds little beyond the schema's own parameter explanations, so a baseline of 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 opens with a specific verb and resource: 'Get stress for one day.' It then enumerates the exact output components (average and maximum stress, plus time divided between rest/low/medium/high stress), which clearly distinguishes it from sibling health metric getters like sleep or heart rate.

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 clear guidance on when to use the default 'summary' vs 'detail='full'' ('Use detail='full' for the underlying per-interval stress series'). It does not explicitly compare alternatives among siblings, but the scope and data type make the use case obvious.

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

garmin_get_training_readinessTraining readinessA

Read-onlyIdempotent

Get Garmin's training readiness score for one day (0-100) together with the factors behind it: sleep score and history, recovery time, HRV status, acute training load and stress history. This is the tool for 'should I train hard today' -- it is Garmin's own synthesis of the recovery signals rather than a raw metric.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already convey readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful context: it is scoped to 'one day', includes a 0-100 score, and enumerates the underlying factors returned. No contradiction with annotations.

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, front-loaded with the core purpose, and wastes no words. The second sentence adds practical usage guidance and sibling differentiation without redundancy.

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?

With no output schema, the description adequately conveys what the tool returns: a score and the contributing factors. It also captures the tool's scope (single day) and purpose. Combined with the detailed schema and annotations, this is complete for a read-only retrieval tool.

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?

The input schema provides full 100% coverage for both parameters, including relative date syntax and the summary/full distinction. The description does not add parameter-level detail beyond what the schema already documents, so the baseline score of 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 'Get Garmin's training readiness score for one day (0-100)' and enumerates the factors it returns. It also explicitly distinguishes this tool from raw metrics by calling it 'Garmin's own synthesis of the recovery signals', setting it apart from likely sibling tools like sleep or HRV.

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 gives explicit usage context: 'This is the tool for "should I train hard today"' and says it is a synthesis rather than a raw metric. It implies when not to use it (for raw metric inspection) but does not name specific sibling alternatives, so it falls just short of a 5.

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

garmin_get_user_profileUser profileA

Read-onlyIdempotent

Get the account profile: name, birth date, height, weight, gender, activity level and -- importantly -- the measurement system. Worth checking once before interpreting units in other tools, since Garmin returns metric values regardless of what the app displays.

ParametersJSON Schema

Name	Required	Description	Default
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a non-obvious behavioral trait: Garmin returns metric values even if the app displays imperial, which is important for interpreting units across tools. This goes beyond annotations.

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: two sentences that front-load the core purpose and immediately provide a crucial usage tip. No wasted words or redundant 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?

For a simple read-only profile getter with one optional parameter and no output schema, the description is fully complete. It lists the returned fields, warns about metric units, and the schema handles the detail parameter. The tool is simple enough that no additional behavior needs explaining.

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?

The only parameter 'detail' is fully explained in the input schema with a clear description of 'summary' vs 'full' and usage guidance. Since schema description coverage is 100%, the description does not need to add parameter semantics; 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's purpose with a specific verb ('Get') and resource ('account profile'), and lists concrete fields (name, birth date, height, weight, gender, activity level, measurement system). It distinguishes itself from sibling tools like garmin_get_body_composition by focusing on the user profile and its measurement system.

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 gives explicit usage context: 'Worth checking once before interpreting units in other tools' and explains that Garmin returns metric values regardless of app display. While it doesn't mention alternatives or exclusions, this is a clear when-to-use hint that adds value.

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

garmin_list_activitiesList activitiesA

Read-onlyIdempotent

List recorded workouts in a date range, newest first, with activity ID, type, name, start time, duration, distance, pace, average and max heart rate, calories, elevation and training effect. Use this to find an activity, then pass its activityId to garmin_get_activity for the full detail of a single session.

ParametersJSON Schema

Name	Required	Description	Default
`detail`	No	'summary' (default) drops per-minute sample series and truncates long lists, which is what you want for almost every question. 'full' returns Garmin's raw payload including every sample -- accurate but potentially enormous, so use it only when the individual data points matter.	summary
`end_date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	today
`start_date`	No	Date as YYYY-MM-DD, or relative: 'today', 'yesterday', '-7d', '-2w', '-3m'.	-7d

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the list is ordered newest first, includes specific fields, and supports a date range. It also communicates a typical workflow (list then get detail), which is extra transparency not present in the structured 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?

Two sentences: the first states exactly what the tool returns and the ordering; the second gives the usage workflow. No fluff, redundant text, or filler. Front-loads the key purpose and ends with actionable guidance.

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 read-only list tool with three optional parameters, the description fully covers what the tool does, what fields it returns, and how it fits into the broader workflow (use to find an activity, then pass activityId to garmin_get_activity). No output schema exists, but the description enumerates the returned attributes, so the agent knows what to expect. Sibling tools are not needed for this simple use case.

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%, with each parameter (detail, end_date, start_date) already explained in the input schema. The description does not add new parameter-level semantics beyond what the schema provides, so the baseline of 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 states a specific verb ('List') and a clear resource ('recorded workouts'), and specifies the returned fields (activity ID, type, name, etc.) and ordering ('newest first'). It also distinguishes itself from garmin_get_activity by framing the list as a precursor to fetching single-activity detail.

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 tells the agent when to use this tool: 'Use this to find an activity, then pass its activityId to garmin_get_activity for the full detail of a single session.' This names the alternative tool and gives the context (finding an activity before retrieving its full detail).

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.

14 tool updatesv0.1.0Aug 3, 2026
- First observedgarmin_api_request
- First observedgarmin_get_activity
- First observedgarmin_get_body_battery
- First observedgarmin_get_body_composition
- First observedgarmin_get_daily_summary
- First observedgarmin_get_health_snapshot
- First observedgarmin_get_heart_rate
- First observedgarmin_get_hrv
- First observedgarmin_get_sleep
- First observedgarmin_get_steps
- First observedgarmin_get_stress
- First observedgarmin_get_training_readiness
- First observedgarmin_get_user_profile
- First observedgarmin_list_activities

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Scored 2026-08-03 09:35 across 14 tools

Disambiguation5/5

Each tool targets a distinct metric or resource (steps, sleep, HRV, stress, activities, etc.), with clear usage guidance in descriptions. Even overlapping tools like daily_summary and health_snapshot are differentiated by purpose (activity vs recovery), and the escape-hatch api_request is explicitly subordinated to dedicated tools.

Naming Consistency4/5

The vast majority follow a consistent garmin_ get_<noun> pattern, and list_activities is a natural exception. The only real outlier is garmin_api_request, which breaks the verb_noun convention but is a generic escape hatch rather than a resource-specific operation.

Tool Count5/5

14 tools is well within the ideal range. The set covers a broad health/fitness domain with dedicated tools for the most common queries, and the single escape hatch prevents the count from exploding into dozens of niche endpoints.

Completeness5/5

The dedicated tools cover all major data categories (daily summary, sleep, HRV, stress, heart rate, readiness, body battery, steps, body composition, activities), and the api_request tool provides access to the remaining ~130 endpoints. This ensures no dead ends while keeping the primary surface focused.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Withings Health DataOAuth
io.github.akutishevsky
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Health & Wellness Research & Data
241
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
Coach WattsOAuth
com.coachwatts
Remote MCP server for training, nutrition, wellness, and performance data with OAuth 2.0.
Health & Wellness Fitness Tracking
271
SomviaOAuth
app.somvia
Private Apple Health metrics and workout detail for ChatGPT, Claude, and any MCP client.
Health & Wellness Fitness Tracking
2

Related MCP Servers

mcp-garmin
Health & Wellness Fitness Tracking
obrien-matthew
A
license
A
quality
B
maintenance
MCP server for Garmin Connect that provides read-only access to daily health metrics, activities, workouts, and body composition data.
Updated 12 days ago (2026-09-01 02:16 UTC)
32
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
Garmin MCP
Health & Wellness Fitness Tracking
lokranjanp
A
license
A
quality
D
maintenance
MCP server that exposes Garmin Connect health and activity data (steps, sleep, stress, activities, etc.) via tools for querying, analysis, and visualization.
Updated 7 months ago (2026-02-20 05:31 UTC)
17
Apache 2.0
garmin-mcp
Health & Wellness Fitness Tracking
Sinfjell
A
license
Not graded
quality
B
maintenance
Connects MCP clients to Garmin Connect data, enabling queries about activities, sleep, heart rate, body battery, and training status.
Updated 21 days ago (2026-08-22 18:01 UTC)
MIT