Get Recovery Data

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

Annotations already cover the read-only, idempotent, non-destructive nature, so the description adds value by specifying exactly what fields are returned (recovery_score, hrv_rmssd_milli, etc.) and how to interpret recovery scores. This goes beyond the structured annotations by providing semantic meaning of the data, though it omits details like timezone handling or pagination beyond the limit parameter.

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 clear sections for the main purpose, recovery score interpretation, parameters, and return fields. It is longer than necessary because the parameter list echoes the schema, but the bullet point format and front-loaded summary make it easy to scan. Every section contributes to understanding the tool's output and usage, so there is no wasted content.

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 no output schema, the description appropriately explains return values and even provides interpretation guidance for recovery scores. All three parameters are documented, and the response fields are enumerated with units. The only missing completeness element is explicit alternative tool recommendations, but for a read-only data retrieval tool, the description gives sufficient information for an agent to invoke it correctly.

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 baseline is 3. The description's parameters section largely repeats the schema's descriptions, but it adds slightly more semantic clarity by stating 'Filter recoveries after this date' for start and 'before this date' for end, which is more explicit than the schema's generic 'Start date filter' and 'End date filter'. This is a minor enhancement, not a significant compensation 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 states the tool 'Retrieves recovery data from Whoop' and lists specific metrics (recovery score, HRV, resting heart rate, SpO2). This specific verb+resource combination distinguishes it from sibling tools like whoop_get_sleep and whoop_get_workouts, which focus on other data types.

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 implies usage by explaining the recovery score bands (Green/Yellow/Red) and how they relate to strain readiness, but it does not explicitly say when to use this tool over others or provide exclusion criteria. There is no mention of alternatives like whoop_get_health_overview for broader health metrics, so usage context is only implied, not fully articulated.

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