Skip to main content
Glama
Sign In
kavakoss

mcp-garmin-connect

by kavakoss
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_full_snapshot

Fetch a full Garmin data snapshot for holistic analysis, including training load and activity windows with data source visibility.

Instructions

Comprehensive Garmin data snapshot for holistic analysis.

Every section carries a data_source field naming the backend that answered it (personal, unofficial, or personal+unofficial when one section needed both — with the per-endpoint map in source_detail). In hybrid mode this makes it visible which numbers are official-API data and which came from the derived-metrics backend, instead of hiding a fallback. (data_source rather than source: some sections already use source for their own provenance string, e.g. garmin_training_status.)

Input Schema

NameRequiredDescriptionDefault
load_daysNoTraining load window in days.
activity_daysNoActivity window in days.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.2.0
    • addedInput schema / properties / activity_days / description
      Added value: +"Activity window in days."
    • addedInput schema / properties / activity_days / maximum
      Added value: +365
    • addedInput schema / properties / activity_days / minimum
      Added value: +1
    • addedInput schema / properties / load_days / description
      Added value: +"Training load window in days."
    • addedInput schema / properties / load_days / maximum
      Added value: +365
    • addedInput schema / properties / load_days / minimum
      Added value: +1
  2. First observedv0.1.0

TDQS

C2.5/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden, yet it never says the call is read-only, how expensive/slow a full multi-endpoint snapshot is, or whether it degrades when the unofficial backend is unavailable. The only behavioral content is the hybrid-mode fallback provenance rule, which is useful but narrow.

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 opening line is properly front-loaded, but the bulk of the text is one long parenthetical about the `data_source` field naming (`personal`, `unofficial`, `personal+unofficial`) that does not help an agent decide to call the tool. Effort is spent on return-field trivia rather than scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/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 values needn't be explained, yet most of the description is exactly that. Meanwhile the genuinely missing pieces — payload scope, cost, and routing relative to siblings — are absent, leaving the definition inadequate for a breadth-oriented aggregate tool.

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 both parameters (load_days, activity_days) are fully documented in the schema, so the baseline of 3 applies. The description adds no windowing guidance or interaction between the two windows.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Comprehensive Garmin data snapshot for holistic analysis" gives a verb and resource, but never says which sections the snapshot contains, so an agent cannot tell what it actually returns versus narrower siblings like get_health_summary or get_fitness. The name and first line convey broad intent only.

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

Usage Guidelines2/5

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

No statement of when to prefer this aggregate call over the two dozen granular sibling tools, nor any precondition or exclusion. The agent must infer that this is a catch-all and is left guessing whether it is a cheap overview or an expensive fan-out.

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

Deploy Server

Other Tools