Get Garmin heart rate

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which fully covers the safety profile. The description adds the regional qualifier (Garmin Connect China) and the daily granularity, which is useful context beyond the annotations. It does not contradict any annotation, and with the safety profile already covered, a 3 is appropriate.

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 sentence with zero waste. The core purpose and scoping qualifiers are front-loaded ('Get Garmin Connect China daily heart-rate data') and the format hint follows naturally. Every element earns its place.

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 no explanation. With one required parameter whose format is documented, and a clear scope, the description covers what an agent needs. The only minor gap is behavior for dates with no data, which is partially addressed by openWorldHint in the 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 description coverage is 0%, so the description must compensate for the single 'date' parameter. It does so by specifying the exact expected format, 'YYYY-MM-DD', which the schema omits. This is precisely the information an agent needs to format the parameter correctly, though it could add a note on what happens for unavailable dates.

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 uses a specific verb ('Get'), a clear resource ('heart-rate data'), and adds two important scope qualifiers: 'Garmin Connect China' (region-specific) and 'daily'. This distinguishes it from siblings like get_hrv (heart rate variability is a different metric), get_sleep, and get_body_battery, so an agent can tell what this tool does 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?

The description communicates the scope (Garmin Connect China, daily) which implies a context, but it gives no explicit guidance about when to choose this over the closely-related get_hrv, nor any exclusions or alternatives. The context is implied rather than stated, so an agent must infer the distinction from tool names.

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