Get Health Overview

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context about what data is included (recovery score, HRV, RHR, SpO2, sleep, strain) and the time ranges (latest, last night, today/yesterday), plus personalized recommendations. This is meaningful beyond annotation hints, though no mention of auth or rate limits is needed for a read-only overview.

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 well-structured with a clear opening sentence, a best-use note, and bullet-point lists for returns and use cases. Every sentence adds value, and it is front-loaded with the core purpose. No wasted words.

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 no output schema, the description compensates by enumerating the key return categories and providing use-case guidance. Sibling tools exist for specific data details, and this tool is clearly positioned as an aggregate overview. The description is complete for an agent to decide when and how to invoke 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 tool has zero parameters and the schema is fully descriptive (empty object). The description does not need to add parameter details. Since there are no parameters, the baseline is 4, and the description appropriately focuses on return values rather than input semantics.

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 states the tool's function with a specific verb ('Gets'), resource ('comprehensive health overview'), and scope ('combining your latest recovery, sleep, and strain data'). It distinguishes itself from sibling tools that focus on individual data types, making it the go-to for an aggregated 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?

The description explicitly identifies when to use this tool ('This is the best tool to use when you want a quick summary of current health status') and lists concrete use cases. It does not explicitly name alternatives or provide exclusions, but the context clearly implies detailed data tools should be used when specific metrics are needed.

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