get_strain

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

No annotations are provided, so the description carries a high burden. It thoroughly describes safety implications (an explicit read operation with no destructive action implied), usage modes (last N days vs. date range), and return format ('summary with averages/totals plus the daily records'). It is very transparent about what the tool does and its non-mutating nature.

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 concise (three sentences) and front-loaded: it states the core purpose first, then details parameters, then use cases. Every sentence contributes unique value without redundancy.

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 appropriately summarizes what is returned ('summary with averages/totals plus the daily records'). The tool is straightforward with 3 simple parameters and no nested objects, and the description covers all critical aspects: data type, range constraints, modes of use, and example queries. Complete for a simple read tool.

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%, but the description adds significant value by explaining how to use start and end together for a historical range, giving a concrete example for March 2026. It also clarifies the mutual exclusivity of days vs. start/end, adding meaning beyond the schema descriptions.

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 specific verbs ('Get', 'returns') and clearly identifies the resource: 'WHOOP daily strain data'. It distinguishes itself from siblings like get_recovery or get_sleep by explicitly listing the data points it retrieves (cardiovascular strain score, heart rate, calories burned) and the context (daily/cycle).

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 clear context for when to use this tool (e.g., 'answer questions about daily exertion or workload, now or in the past') and gives an explicit example ('what was my average strain in March'). It does not, however, explicitly state when not to use it or mention sibling alternatives like get_workouts for exercise-specific data.

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