get_stress_and_body_battery

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

Annotations already declare this is a safe, idempotent read, and the description adds meaningful behavioral context: results are informational, not medical advice, and missing Garmin fields are reported as “not recorded” rather than zero. That missing-data caveat is especially useful beyond what the annotations provide.

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 three short sentences and front-loads the metrics returned, with no wasted prose. The unexplained “T4.” prefix is slightly opaque, but otherwise the structure is efficient.

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 annotations, full parameter schema, and existing output schema, the description is close to complete: it adds the important null-handling rule and disclaimer. It still leaves cross-tool selection ambiguity unresolved, which keeps it from a 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?

Schema coverage is 100%, and the schema already documents the YYYY-MM-DD format and the 90-day maximum for end. The description only says “per day over a date range” and adds no syntax or constraint details 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 description names the resource and the exact metrics returned: average stress, stress-band minutes, and Body Battery high/low/charged/drained over a date range. It is clear what the tool does, but it does not differentiate itself from siblings such as get_body_metrics or get_daily_overview.

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?

Usage is implied by “per day over a date range” and the listed metrics, so an agent can infer it retrieves daily stress and Body Battery data. However, there are no explicit when-to-use/when-not guidelines and no alternatives named, leaving ambiguity against related body-metric tools.

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