Skip to main content
Glama

getDashboardData

Fetch all Garmin training dashboard data in one call: HR zones, fitness age, recent and comparison activities, HRV, sleep, daily summaries, units, and sync status.

Instructions

All the data of the training dashboard in one call: HR zones, fitness age, the activities of the last weeks weeks (compact summaries, with strength sets and laps where they apply), the activities of the weeks before for the period comparison, daily HRV, and the last 14 days of sleep and daily summaries, and units: the measurement system of the Garmin profile (metric, statute_us or statute_uk) that the page shows; the data itself is always metric; locale: the language of the Garmin profile, e.g. it or pt-BR. Keeps a local cache and fetches from Garmin only what is new since the last call, so a rebuild or an update needs few calls. sync in the result says what was fetched: Garmin calls, .FIT files downloaded (fitDownloads) and new activities. digest, first in the result: the server's totals for the whole period and for each Monday-Sunday week (sessions, km, hours, load), the training load of the last 7 and 28 days, best efforts, races and strength top sets; quote them instead of your own sums. For another date range, use the activities: each one is on its own line.

Input Schema

NameRequiredDescriptionDefault
weeksNoWeeks to cover, default 12, max 52
workoutsNoAlso the laps of the runs of each run name that repeats, to compare a workout across weeks: the last 8 (downloaded once) and older ones whose .FIT file is saved; default false

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden well: it discloses caching and incremental-fetch behavior, explains the `sync` result field, and clarifies that units/locale come from the Garmin profile while data remains metric. It does not state permissions or error behavior, but for a read-oriented aggregate tool this is substantial context.

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?

The description is front-loaded with the core purpose and contains no obvious fluff, but it is a dense, run-on set of clauses joined by semicolons that makes it harder to parse. It is appropriately sized for a complex aggregate tool, but the structure could be cleaner.

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?

For a complex aggregate tool with no output schema, the description covers the major returned components (digest, sync, activities, sleep, HRV, units, locale) and caching behavior. It stops short of explaining the full response shape for activities, but provides enough to call and interpret the tool 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 coverage is 100%, so the schema already documents `weeks` and `workouts` thoroughly. The description reinforces the meaning of `weeks` in its data enumeration but adds little about the `workouts` parameter beyond what the schema already says.

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?

The description clearly states that this tool returns all training-dashboard data in one call and enumerates the included data types (HR zones, fitness age, activities, HRV, sleep, summaries). It distinguishes itself implicitly from individual sibling tools by emphasizing the aggregate 'in one call' scope, though it does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a helpful hint for retrieving another date range via activities, and explains caching behavior that favors using this tool for rebuilds or updates. However, it does not explicitly guide when to use this aggregate tool versus individual siblings like getHeartRateZones or getSleep.

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