Skip to main content
Glama

getDashboardData

Fetch all Garmin training dashboard data in one call—HR zones, fitness age, weekly activities, HRV, sleep, daily summaries, units, and locale—while caching to sync only new data.

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, the long runs with their half split and HR drift, the longest run and the race predictions (Riegel), the page's readiness verdict for today with its inputs (readiness), and today's fitness, fatigue and form (fitnessFatigue); quote them instead of your own sums. For another date range, use the activities: each one is on its own line. A load is null (n/a) when the sessions have none; estimatedLoads counts the loads that are estimates from heart rate. A week with partial: true starts before the period. Without HRV and sleep data the digest has no readiness: give the verdict as n/a.

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 observedv0.10.0

TDQS

A4/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 and discloses significant traits: local caching and delta Garmin fetches, sync metadata, units/locale, null loads, partial weeks and missing readiness. It stops short of explicitly stating read-only safety, auth requirements, rate limits or error behavior.

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?

Purpose is front-loaded, but the body is a dense run-on paragraph mixing return fields, cache behavior, parameter notes and edge cases. Bullet points or sections would substantially reduce parsing cost; most details are relevant, so the issue is structure rather than bloat.

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 two-parameter aggregate with no output schema and no annotations, the description is largely complete: it enumerates returned sections, explains the digest and sync blocks, and covers edge cases like null loads and missing readiness. The main omission is an explicit safety/mutation profile, e.g. whether the local cache write is the only side effect.

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 the baseline is 3. The description adds real semantics for `workouts` (last 8 repeats, older FIT files, deduplication) and ties `weeks` to the activity window, going meaningfully beyond the schema text.

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?

Names the exact aggregate resource (training dashboard data) and enumerates the constituent data sets: HR zones, fitness age, activities, HRV, sleep and daily summaries. The 'in one call' framing plus the enumeration distinguishes it from single-domain siblings such as getSleep or listActivities.

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?

Gives useful context for incremental refreshes ('keeps a local cache ... a rebuild or an update needs few calls') and says to use the activities for another date range. However, it never names a sibling tool explicitly or states when to prefer getSleep, getHrvRange, listActivities, etc., over this aggregate.

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