Garmin MCP for macOS

Overview Schema Source Related Servers Discussions Admin

garmin_api_sleep_daily

Read-only

Retrieve full daily sleep data for a specific date from Garmin Connect, preserving raw JSON fields without normalization; defaults to 7 days and supports date ranges up to 31 days.

Instructions

Full sleep response for a date, with fields preserved. Raw JSON fields are not normalized. Date ranges default to 7 days and allow at most 31 days (activity search uses pagination).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "garmin_api_sleep_daily"
  }
}

Input Schema

Name	Required	Description	Default
`date`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 26, 2026

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds genuinely useful context that returned JSON is raw and unnormalized. However, the date-range claim is misleading for a tool with one optional 'date' parameter, and the trailing note about activity search pagination does not describe this tool's behavior at all.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Short and front-loaded, but the final clause about activity search using pagination is irrelevant to this tool and spends the prime trailing position on noise. The middle date-range sentence is also misplaced for a single-date call.

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?

An output schema exists, so return shape needn't be explained, and read-only annotations cover safety. What remains missing is essential for correct invocation: date format and default behavior. The inclusion of unrelated pagination and range text suggests copy-paste rather than a deliberate completion of this tool's needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single 'date' parameter, so the description must carry the burden and it does not: no date format (e.g. YYYY-MM-DD) and no statement of what happens when 'date' is omitted (default today? latest?). The 7-day/31-day range language is confusing rather than clarifying for a one-param tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the resource and its nature clearly: a full, unnormalized sleep response for a single date, with fields preserved. The contrast with garmin_api_sleep_summaries is only implicit through the words 'full' and 'with fields preserved', so an agent can probably distinguish them but isn't told directly.

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?

There is no explicit statement of when to use this tool instead of garmin_api_sleep_summaries, garmin_sleep, or garmin_api_daily_summary. The only guidance-like sentence ('Date ranges default to 7 days and allow at most 31 days') implies multi-date usage, which conflicts with the single optional date parameter and gives no selection criteria.

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