mcp-garmin-connect

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

With no annotations, the description carries the burden and does well: it discloses the API tier requirement, the delivered format, and a non-obvious fidelity caveat (Garmin strips VO2 Max, recovery time, performance condition). It does not mention that the call writes a file to disk or any size/latency characteristics, which is the main remaining gap for an unannotated tool.

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

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

Front-loaded with the core action and artifact, then supporting caveats in short clauses. Every sentence carries information, though the 'sample by sample' enumeration is slightly decorative.

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

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 need not be explained; the description covers purpose, auth tier, format, and fidelity caveats. The one omission is the write-to-disk side effect implied by save_path, which matters for a file-producing tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: save_path is well documented in the schema, but activity_id has no schema description. The description's 'for one activity' partly compensates for activity_id, and its silence on the save_path/filesystem behavior leaves that side effect to the schema alone. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Download the original activity file') and pins down the exact artifact ('ZIP containing the .FIT') plus scope ('for one activity'). This is clearly distinguishable from siblings like get_activity_detail, which return processed JSON rather than the raw file.

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

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

'Personal API only' and 'which the unofficial flow cannot fetch' tell the agent the precondition and why this tool exists rather than an alternative. It never explicitly names a sibling or a when-not-to-use case, so routing is strongly implied but not spelled out.

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

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

No annotations are provided, so the description carries the full burden. It only says 'detailed summary' without disclosing what metrics are included, whether any side effects exist, or the response format. This is minimal behavioral disclosure for a data-retrieval tool.

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

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

One concise sentence with no redundant words. It is front-loaded with 'Detailed summary' and immediately clarifies the key identifier, making it easy to scan.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While an output schema exists, the description is otherwise minimal. It lacks usage guidance, behavioral detail, and sufficient parameter semantics. For a tool with one parameter and no annotations, this is adequate but leaves clear gaps in when and how to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter with 0% description coverage. The description clarifies that the parameter is a Garmin activity ID, adding meaning beyond the bare schema. However, it does not provide format, range, or examples, so it only partially compensates for the coverage gap.

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

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

The description clearly indicates the tool returns a detailed summary for one activity, and specifies the unique identifier (Garmin activity ID). It distinguishes this from sibling tools like get_recent_activities, though it lacks an explicit verb like 'retrieves' or 'gets'.

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

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

No guidance on when to use this tool versus alternatives, such as get_recent_activities for listing activities. The description implies you need a specific activity ID but does not state prerequisites, use cases, or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about permissions, whether splits exist for all activity types (e.g., laps on non-interval activities), or pagination/size. Its field list duplicates the output schema rather than adding behavioral context, leaving the agent without key caveats.

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

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

A single front-loaded sentence with the resource first and the returned metrics after; no filler or redundancy.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with an output schema, the description is minimally sufficient to select and call it. However, with no annotations and no sibling differentiation, an agent cannot confidently decide between this and get_activity_detail without external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single parameter activity_id has no description in the schema. The description's 'for one activity' obliquely clarifies the parameter's meaning and cardinality, but does not state the ID format or source (e.g., from get_recent_activities).

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

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

Names a specific resource (per-lap splits for one activity) and enumerates what is returned (pace, HR, cadence, elevation, HR drift), so the agent knows exactly what data this yields. It does not distinguish itself from the likely-overlapping sibling get_activity_detail, leaving the agent to guess which to call for laps.

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

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

No statement of when to use this versus get_activity_detail or get_recent_activities, and no prerequisites. The phrase 'for one activity' only weakly implies that a single activity_id is required, which the schema already enforces.

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

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

With no annotations, the description carries the burden, and it does disclose meaningful traits: the raw per-timestamp arrays are discarded in favor of daily summaries, and the `daily` array is newest-first. It stops short of stating read-only/no-side-effects explicitly, relying on the 'get' naming to convey that.

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

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

Front-loaded with the payload shape, then the sibling contrast, then the two behavioral notes. The 'large and rarely useful' rationale for summarization earns its place by preventing an agent from hunting for raw data.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one optional param, output schema present), so the description needn't explain return values. It covers the purpose, alternative, and array ordering; the only gap is the absence of an explicit safety profile given no annotations exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single `days` parameter is fully documented in the schema (range 1-30, default 7). The description adds nothing about the lookback window, so it sits at the baseline for a fully-documented schema.

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

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

The first line names the resource (body battery), its scope (daily range), and the exact metrics returned (charged, drained, highest, lowest, end of day). The second sentence explicitly contrasts it with the sibling get_recovery, so an agent can distinguish the two without inspecting the schema.

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

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

It names the alternative (get_recovery) and the condition that selects it: get_recovery gives only today's levels, while this tool is for history/trends. The routing decision is fully specified with no inference required.

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

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

Since no annotations were provided, the description carries the full behavioral burden. It discloses essential behavioral traits: this is a 'Personal API only' function and that secondary metrics (fat/muscle) are conditional upon the device reporting them, which is vital for agent expectation setting.

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

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

The description is reasonably concise but contains some commentary ('unofficial flow') that isn't strictly necessary for execution. It front-loads the core utility (Weight from Garmin) but could be tighter overall.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The definition is quite complete given the simple parameter count and the specialized nature of the data. It tells the agent exactly what metrics to expect and the necessary operational context (Garmin/Personal API), which is the most important information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline score for parameter semantics is 3. The description provides no additional semantic meaning regarding how the 'days' lookback window should be interpreted or constrained beyond what the schema already provides.

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

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

The description is highly specific, clearly stating the function (retrieving weight/body fat/muscle) and the source (Garmin Connect). This immediately differentiates it from sibling tools that provide general activity summaries or health stats.

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

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

The description provides strong motivational context, stating that weight is critical for fitness decisions. However, it does not explicitly define when *not* to use it, nor does it offer clear comparisons to other similar health tools like get_health_summary.

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

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

No annotations are provided, so the description should disclose behavioral traits like read-only nature, data source, or units. It merely lists output metrics without any behavioral context. There is no contradiction, but the description fails to carry the transparency burden.

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

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

The description is a single concise phrase, listing three key metrics. It is front-loaded and contains no fluff. However, it's so brief that it verges on being a title rather than a descriptive sentence, so it doesn't earn a 5.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (0 params, output schema present), but the description could offer more context about what these metrics represent or how they're calculated. It's enough to know the tool returns fitness data, but it lacks clarity on scope or source. An output schema may fill the gap, but the description alone is minimal.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the input schema is empty. Per the rubric, a baseline of 4 applies for 0 params. The description doesn't need to explain parameters, and it doesn't, which is acceptable.

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

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

The description clearly identifies the tool's purpose: it provides VO2 max, cycling FTP, and race predictions. These specific metrics distinguish it from sibling tools like get_recovery or get_sleep. Though it's a noun phrase rather than a full sentence, the meaning is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives. It doesn't state 'for fitness metrics' or recommend get_recovery for recovery data. The agent must infer usage solely from the listed metrics and sibling names.

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

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

With no annotations, the description carries the full burden, and it does disclose one real behavioral trait: the tool only works against the personal API (an auth/access constraint an agent needs). It says nothing about whether data must be synced first or whether a missing value is possible.

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

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

Two short sentences with the resource front-loaded and the access constraint appended; nothing is padded. The phrase 'Personal API only' is terse to the point of being slightly opaque.

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

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 need not be described, and no parameters need explaining. What remains missing is the sibling relationship to get_fitness and any hint about data freshness, which matters for a 'today' scoped metric.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete. Baseline 4 applies for a no-argument tool.

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

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

Names a specific resource (Garmin's fitness age) and scopes it temporally to 'today', so the agent knows exactly what is returned. It does not distinguish itself from the nearby get_fitness sibling, leaving the boundary between generic fitness metrics and fitness age implicit.

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

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

There is no guidance on when to call this versus get_fitness or get_training_load, and no stated preconditions such as needing a recent activity sync. 'Personal API only' is an access constraint, not a usage rule.

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

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.

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.

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.

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.

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.

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.

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

No annotations are provided, so the description carries the full burden. It does disclose the content composition (recovery, sleep, stress) and implicitly what is excluded, which is useful, but says nothing about aggregation behavior, freshness, or how values are summarized. The presence of an output schema offloads return-shape disclosure, which keeps this at a 3.

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

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

One short sentence, front-loaded with the core value proposition ('compact health snapshot') followed by the domains covered. No filler.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only aggregate tool with a fully documented schema and an output schema, the description covers what the tool returns well enough. The one real gap is routing guidance against get_full_snapshot and the single-domain siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% ('Lookback window in days.'), so the single parameter is already fully documented in the schema. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource (health snapshot) and its scope: it combines recovery, sleep, and stress. The word 'compact' implicitly distinguishes it from get_full_snapshot and from the single-domain siblings (get_recovery, get_sleep, get_stress), though it never names them.

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

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

No when-to-use or when-not-to-use guidance is given. The agent is left to infer that a compact combined snapshot is preferable to get_full_snapshot or to three separate calls; nothing in the description says so.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose the array ordering ('newest-first') and the data composition, which is real added behavior, but says nothing about data freshness, behavior when fewer than `days` of history exist, or that the call is a safe read.

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

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

Three short sentences, front-loaded with what is returned before the sibling comparison. The quoted 'how am I today' phrase is slight color but earns its place by making the routing rule concrete.

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

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 need not be explained, and one optional parameter plus the sibling routing are both covered. Minor gaps remain around how the baseline is computed and what happens with insufficient history.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single `days` parameter is fully documented with default, min, and max in the schema. The description only gestures at range ('longer range'); it adds no interpretation beyond the schema, so the baseline 3 applies.

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

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

The first line names the resource precisely (daily HRV) and enumerates what it contains: last-night value, weekly average, and a baseline. It also explicitly distinguishes itself from the sibling get_recovery by contrast, so an agent can pick between them without opening a schema.

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

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

It states exactly when get_recovery suffices ('how am I today') and when this tool is needed (trend questions), naming the alternative and the condition that selects it. The 'same data over a longer range' framing removes any ambiguity about overlap.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the unit and personal API restriction, but does not clarify read-only behavior, authentication requirements, or whether it returns daily records versus aggregated data.

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

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

The description is two short sentences with no wasted language. The key information, fluid intake and unit, is front-loaded.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, has one optional parameter, and includes an output schema, so the description covers the essential purpose and unit. It could be more complete by clarifying read-only behavior or the 'Personal API only' implication, but it is adequate for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully documents the single 'days' parameter as a lookback window with a default and range. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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

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

The description clearly identifies the resource as logged daily fluid intake and specifies the unit in millilitres. It does not explicitly differentiate this tool from sibling health-metric retrieval tools, but the resource itself is distinct.

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

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

The description states 'Personal API only', which gives a scope constraint, but provides no guidance on when to use this tool versus alternatives or whether there are prerequisites for accessing personal hydration data.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints at the data source ('based on recent activities') and the windowing semantics ('calendar-ish months'), but discloses nothing about aggregation method, permissions, or how partial months are handled.

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

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

It is a single, front-loaded sentence with no padding, which is structurally sound. However, the hedge word 'calendar-ish' undermines precision for an API contract and doesn't earn its place in a spec.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because an output schema exists, return values needn't be explained, and a one-parameter read tool is simple. Still, the core ambiguity with get_running_summary and the vague windowing term leave the agent without enough to call this confidently over its sibling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the single 'months' parameter (with default, min, max) is already fully documented in the schema. The phrase 'last N months' merely echoes the parameter and adds no format or interpretation detail, so the baseline 3 applies.

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

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

The description states the resource (monthly running stats) and scope (last N months), but 'Monthly running stats' largely restates the tool name rather than adding a distinguishing verb+resource framing. It never differentiates from the sibling get_running_summary, which an agent could easily confuse with this tool.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to or away from alternatives. Given the very close sibling get_running_summary, the absence of any disambiguation leaves the agent to guess which one to call.

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

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

With no annotations, the description must disclose behavior but only says data is 'returned'. It does not explain whether the data is live, filtered, or what scope personal records cover, nor any side effects or limitations.

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

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

The description is very brief—a single fragment—but this brevity results in under-specification. It lacks a clear verb or complete sentence structure, making it less useful despite being short.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich set of sibling tools and no annotations, the description is inadequate. It fails to clarify what 'personal records' means, when to use this tool, or what distinguishes it from similar health/fitness tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the schema fully covers the invocation contract (none required). The description adds no parameter info, but no params minimizes the need; baseline 4 is appropriate.

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

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

The description states that personal records are returned from Garmin Connect, giving a resource and source, but uses no imperative verb and lacks specificity about what constitutes 'personal records'. It does not distinguish from siblings like get_fitness or get_running_summary.

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

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

No guidance is provided on when to use this tool versus alternatives. The description only identifies the resource, offering no context or exclusions.

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

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

With no annotations present, the description does carry the full burden, and it does disclose two useful traits: results are summary-level rather than full activity detail, and explicit dates override the lookback. It says nothing about ordering, whether limit truncates the newest or oldest activities, or the read-only nature of the call.

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

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

Three short sentences with the core purpose front-loaded and the window logic second; nothing is padding. The window-timing sentence partially duplicates the schema descriptions, which is the only waste.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All four parameters are optional and fully documented in the schema, and an output schema exists, so return values need no explanation. The one real gap is the absence of any routing signal among the many sibling activity/summary tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, including the precedence rule ('Ignored when start_date is given'), so the baseline is 3. The description restates that same precedence and the inclusive-window semantics, adding no format or interaction details the schema lacks.

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

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

States a specific resource ('Recent Garmin activities') and the shape of the return ('normalized sport-aware summary fields'), so an agent knows this is a list-of-activities tool rather than a per-activity detail tool. It does not, however, distinguish itself from summary-oriented siblings such as get_running_summary or get_monthly_running_stats.

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

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

The description explains the date-window mechanics ('Pass start_date/end_date ... otherwise the days lookback is used'), but that is parameter guidance rather than tool-selection guidance. It never says when to reach for this tool instead of get_activity_detail, get_running_summary, or get_recent_load, so the agent must infer that from the name alone.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the result is an aggregation grouped by sport rather than raw activities, which is meaningful context. It omits any mention of read-only safety, auth needs, or data source, but these are low-risk for a simple aggregation and an output schema exists.

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

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

A single tight sentence with zero filler, and the aggregation scope is front-loaded before the time window. Nothing is wasted.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one optional parameter, output schema present), so the description need not explain return values or bounds. It is nearly complete, with the only real gap being lack of differentiation from the closely named sibling get_training_load.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'days' parameter is fully documented in the schema as 'Lookback window in days.' The description reinforces the windowing concept ('last N days') but adds no syntax, bounds, or default information beyond the schema, so baseline 3 applies.

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

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

The description names a specific resource and scope: training volume aggregated by sport over a configurable day window. It is far more specific than the bare name 'get_recent_load'. However, it does not differentiate itself from sibling 'get_training_load', leaving ambiguity about which load tool to pick.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as get_training_load or get_fitness. The only hint is the word 'recent', which is implied usage at best.

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

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

No annotations are present, so the description carries full responsibility. It discloses the data content but does not indicate whether this is a read-only operation, whether it has any latency or prerequisites, or any other behavioral traits. A simple getter like this would benefit from a statement about it being a read-only snapshot.

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

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

The description is a single, front-loaded phrase that directly names the resource and its key components. Every word adds value, with no filler or unnecessary elaboration.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with zero parameters and an output schema present, the description adequately identifies the resource and enumerates the main data points. It could optionally clarify that it returns only the current state, but the tool's simplicity makes the description sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is 100% with empty properties. Since there are no parameters to explain, the description is not required to compensate; per the baseline for zero-parameter tools, a score of 4 is appropriate.

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

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

The description identifies the specific resource (recovery state) and lists its components (readiness, HRV, sleep, body battery, and status), which distinguishes it from sibling tools like get_sleep and get_fitness. However, it uses a noun phrase rather than an explicit verb like 'Gets', making it slightly less direct than ideal.

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

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

There is no guidance on when to use this tool versus its many siblings. The description simply states what it returns, leaving the agent to infer the appropriate context without any exclusions or alternatives.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that results include 7-day and 30-day trend summaries (not just raw daily values), but it says nothing about permissions, rate limits, or whether trends are returned even when a shorter window is requested. As a read-only metric fetch the risk is low, so a 3 is fair.

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

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

One compact sentence that front-loads the core resource and immediately follows with the aggregation scope and cap. Every clause carries information; nothing is padded or repeated.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values, and the single optional parameter is fully covered by the schema. The only material gap is the absence of sibling-differentiation guidance against get_health_summary/get_full_snapshot, which leaves tool selection partly ambiguous.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — the single 'days' parameter is fully documented with a default of 30 and a max of 30. The phrase 'up to 30 days' echoes that constraint but adds no new syntax or format meaning, so the baseline 3 applies.

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

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

The description names a specific metric (resting heart rate) and the aggregation it returns (daily values plus 7-day and 30-day trend summaries), which is a clear verb+resource statement. It does not, however, distinguish itself from metric-adjacent siblings like get_health_summary or get_full_snapshot, so an agent must infer the boundary.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as get_health_summary or get_full_snapshot, which could also surface heart-rate data. The agent receives no routing signal for choosing this tool over its many siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. It never states that this is a read-only aggregation, says nothing about the lookback window semantics, pagination, or result shape, and gives no permission or rate-limit context. The metric list hints at aggregation behavior but does not constitute behavioral disclosure.

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

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

A single front-loaded sentence fragment with no filler; the metric enumeration is the most useful content and appears first. It is terse to the point of being clipped, but nothing is wasted.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is low complexity, the parameter schema is complete, and an output schema exists so return values need not be explained. However, with zero annotations the description still owes the agent a read-only signal and some distinction from the overlapping monthly-stats sibling, which it does not supply.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single `days` parameter is fully documented in the schema (default 90, range 1-365, meaning stated), giving 100% coverage. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

The phrase 'Running summary' largely restates the tool name, but the trailing metric list (sessions, distance, pace, HR, longest run, fastest run, monthly split) does specify what the summary contains. It does not differentiate from siblings like get_monthly_running_stats, whose name overlaps with the 'monthly split' element, so the agent cannot resolve the overlap from the description alone.

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

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

The description offers no when-to-use guidance, no exclusions, and never mentions an alternative tool. With near-duplicate siblings such as get_monthly_running_stats and get_recent_activities, the absence of routing guidance is a real gap rather than a minor omission.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no data source, sync freshness, timezone handling for sleep windows, or permissions. It only restates the resource and the lookback window, leaving the read semantics to be assumed.

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

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

A single front-loaded sentence with no filler; the resource and scope come first. It is a fragment rather than a full sentence, but nothing in it is wasted.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with an output schema and full schema coverage, the description covers what the agent needs to call it correctly. The remaining gap is routing among the numerous sibling summary tools, which is a usage rather than a completeness problem.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the days parameter is fully documented in the schema with a default of 7 and a 1-30 range. The description's 'last N days' merely echoes the schema, adding no format or interpretation detail, so the baseline 3 applies.

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

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

The description states a concrete resource (sleep) plus the two data types returned (duration and scores) and the scope (last N days). It is clearly distinguishable from siblings like get_activity_detail or get_stress by resource, though it never names an alternative to route between them.

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

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

There is no when-to-use guidance, no exclusions, and no mention of the many overlapping siblings (get_recovery, get_health_summary, get_full_snapshot). The agent must infer that this is the sleep-specific read tool purely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the personal-API scope, but says nothing about read-only semantics, pagination or volume limits for a 1-30 day window, or what happens when no SpO2 data exists.

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

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

Two short sentences with no filler, and the metric identity is front-loaded. It is telegraphic to the point of under-specification rather than padded, but nothing is wasted.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return formatting need not be explained, and the one optional parameter is fully specified in the schema. Still, for a health-metric tool with no annotations, the description should clarify what "acclimation" values represent and whether data is daily-aggregated or sparse.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single "days" parameter already documents its meaning, default of 7, and 1-30 bounds. The description adds no additional detail (e.g., aggregation method or timezone handling), so the baseline 3 applies.

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

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

"Blood oxygen (SpO2) acclimation per day" names the resource and the granularity, which separates it from metric siblings like get_hrv_history and get_steps_history. However, there is no verb and "acclimation" is an unusual framing whose meaning is not clarified, so the agent knows the topic but not exactly what is returned.

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

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

"Personal API only" is an access constraint, not usage guidance. Nothing states when to call this versus get_health_summary, get_full_snapshot, or get_recovery, and no preconditions or exclusions are given.

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

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

No annotations exist, so the description carries the full behavioral burden. It discloses only the 'Personal API only' access constraint and leaves data freshness, aggregation semantics, and whether goals are user-set or computed unstated. The 'get' name implies a read, but that is inference rather than disclosure.

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

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

Two short sentences with the core purpose front-loaded and no filler. The 'Personal API only' fragment is terse but meaningful.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with an output schema, the description covers purpose and an access constraint. It is still thin on what 'goals' means and on any usage context, leaving minor gaps an agent must infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%: the single 'days' parameter is documented with default, min, and max. The description adds nothing beyond the schema, so the baseline 3 applies.

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

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

States the specific resource: daily step totals and goals, which an agent can distinguish from sleep, HRV, or training-load siblings. It doesn't explicitly name a sibling it is not, but the resource is concrete enough to route correctly.

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

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

There is no when-to-use guidance and no mention of alternatives such as get_health_summary or get_full_snapshot. 'Personal API only' is an access constraint, not usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only names the data returned. It doesn't state that this is a read-only operation, how the duration buckets are derived, or any granularity/aggregation behavior. The output schema covers return shape, but the operation's behavior is left unexplained.

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

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

A single, front-loaded sentence with no filler that immediately states the resource and the data provided. Appropriately sized for a simple single-parameter getter.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema means return values needn't be explained, and schema coverage is complete for the lone parameter. What's missing is any usage context or relation to the many sibling health metrics, leaving a small but real gap for an agent choosing among 14 similar tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one optional parameter (days) exists and the schema documents it fully at 100% coverage, so the schema does the heavy lifting. The description adds nothing about the lookback parameter, so baseline 3 applies.

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

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

States a specific resource (stress) and the metric shape (daily all-day stress levels and duration buckets), which is clear enough to distinguish from most siblings. However it doesn't explicitly differentiate itself from related recovery/fitness tools like get_recovery or get_fitness, so it falls short of a 5.

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

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

The description gives no when-to-use guidance, no mention of the lookback window, and no routing to or away from sibling tools such as get_recovery or get_fitness. The agent must infer usage entirely from the name.

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

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

With no annotations provided, the description bears the full burden of disclosing behavioral traits. It only lists the data categories, but does not mention whether the operation is safe/read-only, whether any authentication is required, or any rate limits. It also doesn't describe the time period or units, though the output schema may cover those details. This falls short of the transparency expected for a tool with no annotation support.

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

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

The description is a single, compact phrase that lists exactly the essential data elements. Every word earns its place, with no filler or repetition. It is appropriately sized for a simple no-parameter getter and is easily scanned.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters) and presence of an output schema, the description is nearly complete. It conveys the core purpose and the kind of data returned. It does not elaborate on edge cases or typical use contexts, but for a basic read-only getter, this is sufficient. A slightly more explicit statement about data scope would push it to 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is 100% (vacuously). The baseline for 0 params is 4. The description adds no parameter-specific explanation, but none is needed since there are no parameters to clarify. The short description does not detract from schema adequacy.

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

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

The description clearly identifies the resource as Garmin training load and lists specific components (status, acute/chronic load, load focus), which distinguishes it from sibling tools like get_recovery or get_sleep. However, it lacks an explicit verb (e.g., 'returns' or 'gets'), relying on the tool name to imply the action, so it falls just short of a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, typical use cases, or cases where another sibling tool (e.g., get_recent_load) would be more appropriate. The only context is the data content, leaving the agent to infer usage.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one genuinely useful behavior: zones come from user settings and may not exist ('when available'), which warns the agent about empty or missing results. It says nothing about read-only nature, auth, or data staleness, but the conditional-availability caveat is real added value.

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

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

A single front-loaded sentence with no filler; the resource is stated first and the sourcing caveat second. It is perhaps too terse to be maximally useful, but nothing is wasted.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and with zero parameters there is no argument surface to cover. The main omission is the absence of any sibling routing or usage context, which is a modest gap for a low-complexity read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-related claims are made that could mislead.

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

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

The description names a specific resource (heart-rate zones and thresholds) and their source (Garmin user settings), so an agent can tell this apart from get_resting_heart_rate or get_training_load by resource. It does not, however, explicitly differentiate itself from broader aggregators like get_health_summary or get_full_snapshot, which may also surface zone data.

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

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

There is no statement of when to call this versus the many sibling metrics tools, nor any prerequisites or exclusions. The only contextual cue is the 'when available' qualifier, which hints at conditional data but is not usage guidance.

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