fitbit_get_breathing_rate

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

With no annotations provided, the description carries the full transparency burden. It explicitly discloses the cache-first behavior ('Returns from cache by default, auto-syncing if stale'), the 'live' parameter to bypass cache, and the output structure ('one entry per night with breaths_per_min') plus a typical range. This goes beyond most tool descriptions and fully informs the agent about the tool's runtime behavior.

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 structured with a clear opening line, a rationale paragraph, an Args block, and a Returns note. Every sentence adds distinct information, and nothing is redundant. Though longer than minimal descriptions, the extra length is justified by the need to compensate for sparse schema info. It remains highly readable and 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?

Given the tool has no annotations and no schema descriptions, the description covers all essential facets: what it returns, when to use it, how it behaves (cache vs live), parameter formats, and output shape. The presence of an output schema means return details are not a burden, but the description still adds interpretive guidance. It is complete enough for an agent to select and invoke the tool correctly without ambiguity.

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 input schema provides zero descriptions (0% coverage), but the description compensates fully by documenting all three parameters: start_date (with allowed formats and default), end_date (with format and default), and live (explaining its effect). It also adds contextual meaning (e.g., '30d' accepted as a relative date), which is essential for correct invocation.

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 begins with a specific verb+resource: 'Get nightly breathing rate (avg breaths per minute during sleep)' which precisely states the metric and measurement context. It clearly differentiates from sibling tools by focusing on breathing rate, a unique health metric among the listed getters.

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 usage context by framing the data as an 'illness/recovery signal' with a concrete threshold ('sustained increases of 2-3 bpm above personal baseline'). This tells the agent when the tool is relevant. However, it does not explicitly mention when not to use it or compare to alternative metrics (e.g., heart rate), so it stops short of full exclusion/alternative guidance.

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