Garmin Connect MCP Server

Get Sleep Data

get_sleep_data

Read-only

Retrieve sleep metrics for a date: duration, stages, quality score, and nightly summary. Optionally include per-minute time series for deeper analysis.

Instructions

Get a night of sleep: duration, sleep stages, quality score and the nightly summary. The per-minute series behind it (movement, heart rate, stress, body battery, HRV, respiration) are reported as counts only; set includeTimeSeries to inline them, or use the dedicated tool for the one series you need.

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": "get_sleep_data"
  }
}

Input Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format. Defaults to today if not specified.
`includeTimeSeries`	No	Inline every per-minute series for the night (default false). This is a very large response; prefer get_sleep_movement, get_hrv_data or get_respiration_data for a single series.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv4.5.7Aug 23, 2026

addedInput schema / properties / includeTimeSeries

Added value: +{
+  "description": "Inline every per-minute series for the night (default false). This is a very large response; prefer get_sleep_movement, get_hrv_data or get_respiration_data for a single series.",
+  "type": "boolean"
+}

First observedv4.3.0Jul 29, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already supply readOnlyHint=true and openWorldHint=true, covering the safety and data-scope profile. The description adds genuinely useful behavior beyond that: per-minute series are returned as counts only by default, and includeTimeSeries produces a very large response, helping the agent anticipate output size 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 sentences with no filler. The primary deliverable is stated first, followed by the routing caveat, and every clause adds information needed for tool selection or invocation.

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?

With no output schema, the description covers the key return components and the large-response caveat. It could add a bit more precision about response shape or units, but for a read-only aggregate tool with optional parameters, the essentials needed to call it correctly are present.

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%, so both date and includeTimeSeries are already well documented in the input schema. The description still adds value by explaining the default behavior (counts only) and the relationship between includeTimeSeries and the underlying per-minute series, reinforcing rather than merely repeating 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 names the resource (a night of sleep) and enumerates the concrete aggregate outputs: duration, sleep stages, quality score, and nightly summary. It also positions the tool against sibling per-series tools by noting that per-minute series are counts-only unless inlined, so an agent can distinguish it from get_sleep_movement, get_hrv_data, and get_respiration_data.

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?

It gives explicit routing guidance: for a single per-minute series, use the dedicated tool instead, and set includeTimeSeries when the full set is needed. This clearly separates when to use this tool versus the alternative series-specific tools.

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

Deploy Server