Skip to main content
Glama
happyc0der

garmin-connect-api

Get day summary

get_day_summary
Read-onlyIdempotent

Retrieve one calendar day's Garmin metrics—steps, calories, heart rate, stress, body battery, sleep, HRV, readiness, and weigh-in—in a single call.

Instructions

Return one calendar day's numbers in a single answer: steps, calories, heart rate, stress, body battery, last night's sleep, HRV, the morning readiness score and the day's last weigh-in.

It does not list the day's activities: use list_activities with start_date and end_date both set to the day. For one metric, its own tool (get_sleep, get_hrv, get_stress, get_steps, get_training_readiness) gives more detail in one Garmin request instead of five; for seven days use week_summary, for a range get_trend. A part whose request fails is null and named under unavailable; if every part fails, or Garmin rate limits, the call returns an error instead. A night's sleep belongs to the day it ended on.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayYesThe calendar date, YYYY-MM-DD.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayYes
rawNo
sleepNo
stepsNo
max_hrNo
min_hrNo
weightNo
step_goalNo
distance_mNo
hrv_statusNo
resting_hrNo
unavailableNoParts Garmin did not answer for, and why: a part missing from this summary is listed here if it failed, rather than looking like a day with nothing recorded.
average_stressNo
floors_climbedNoGarmin reports floors fractionally, e.g. 2.25.
total_caloriesNo
active_caloriesNo
body_battery_lowNo
body_battery_highNo
hrv_last_night_avgNo
training_readinessNoThe morning score Garmin sets on waking.
moderate_intensity_minutesNo
vigorous_intensity_minutesNoGarmin counts these double toward the weekly goal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/openWorld, yet the description adds substantial extra behavior: partial failures become null and are listed under 'unavailable', total failure or Garmin rate limiting returns an error, and sleep is attributed to the day it ended on. These are non-obvious traits the annotations do not convey.

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?

Front-loaded with the returned value set, then routing rules, then failure semantics. The metric enumeration is long but each item earns its place by defining scope; no filler sentences.

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?

Even though an output schema exists, the description fully covers scope, alternatives and error behavior. Nothing an agent needs to select and call this tool correctly is missing.

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% for the single 'day' parameter, so the baseline would be 3. The description adds one meaningful semantic rule beyond the schema — 'a night's sleep belongs to the day it ended on' — clarifying what date to pass for sleep data.

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 a specific verb+resource (aggregate one calendar day's metrics) and enumerates the exact contents returned: steps, calories, heart rate, stress, body battery, sleep, HRV, readiness and weigh-in. It is clearly distinguishable from siblings like list_activities, week_summary and get_trend.

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 explicitly states when NOT to use it (the day's activities → list_activities with start_date/end_date) and names alternatives with their selecting conditions: per-metric tools for one metric, week_summary for seven days, get_trend for a range. Nothing is left to inference.

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