garmin-owl

Overview Schema Source Related Servers Discussions Admin

get_data_coverage

Read-only

Retrieve first and last dates with Garmin data per metric family and activity count to choose accurate start dates for long-range analysis; also lists user's devices.

Instructions

Get the first and last date with Garmin data per metric family (daily summary/resting HR, HRV, sleep, VO2 max, training readiness, activities), the activity count, and the user's devices.

Use before any long-range or "since the beginning" analysis to choose start_date instead of probing dates one by one; use get_daily_series or get_period_summary next, whose coverage shows the gaps inside the span. Families without any data are omitted. Training readiness has no Garmin range read, so its dates cover locally cached days only (method says so). Devices list model, status, registration date and primary flag; never serial numbers.

Costs about 20 Garmin requests and a complete answer is cached for 24 hours.

Requires saved local Garmin authentication (garmin-owl-auth). Reads Garmin and may update the local cache; never changes your Garmin account. Garmin failures are not retried automatically.

Input Schema

Name	Required	Description	Default
`refresh`	No	When true, ask Garmin again instead of reusing the answer cached for 24 hours. Defaults to false.

Output Schema

Name	Required	Description	Default
`note`	No		Dates bound where Garmin has data; days inside the span can still be missing. Use get_daily_series or get_period_summary coverage for gaps.
`devices`	No
`families`	No
`checked_at`	No	When Garmin was last asked: ISO 8601 with an explicit UTC offset, e.g. 2026-10-09T23:18:16+02:00. The wall time is already local; never add the offset again. The offset is the one Garmin recorded for the device at that moment, or this computer's time zone when Garmin gives only UTC.
`availability`	No
`activity_count`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.1Oct 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the read-only/open-world annotations: ~20 Garmin requests, 24-hour cache with a refresh escape hatch, requirement for saved local Garmin auth, may update the local cache but never mutates the Garmin account, no automatic retry on failure. It also flags two non-obvious behaviors: empty families are omitted, and training readiness dates reflect locally cached days only.

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

Conciseness4/5

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

Front-loads what is returned, then use-case, then caveats, then cost and auth constraints — a sensible ordering with little filler. Slightly dense with a parenthetical asides ("method says so") that could be trimmed, keeping it just short of top marks.

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?

An output schema exists, so return shape needn't be explained, yet the description still covers the non-obvious return semantics (omitted empty families, no serial numbers, cached-only readiness dates). Cost, auth prerequisites, and cache lifecycle are all present — nothing an agent needs before calling is missing.

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% and the single `refresh` parameter is fully documented in the schema itself, including its default and its relationship to the 24-hour cache. The description reinforces the cache window but adds no syntax or semantics beyond what the schema already provides, so baseline 3 applies.

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?

States a specific verb and resource: it returns first/last date with data per metric family, activity count, and devices, enumerating the metric families explicitly. This is clearly distinguishable from per-metric siblings like get_sleep or get_hrv, which return actual data rather than coverage boundaries.

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 to use it before any long-range or 'since the beginning' analysis to pick start_date instead of probing dates one by one, and names the follow-up tools (get_daily_series, get_period_summary) for gap inspection. Both the when and the alternatives are spelled out.

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