Loading ToolBench
Strong foundation with consistent naming, clear descriptions, and proper schema definitions across all 11 tools. All tools follow verb_noun pattern (get_*, list_*). Descriptions are concise (34-194 chars) and explain purpose clearly. Input schemas use Zod with type constraints and descriptions. Tool annotations (readOnlyHint, openWorldHint) are present. Key gaps: output schemas are not documented (tools return text-wrapped JSON without explicit field definitions), error handling lacks recovery guidance, and parameter descriptions could be more prescriptive about constraints and formats.
Get the user's body measurements: height, weight, and max heart rate.
Get a single cycle by id.
Get the recovery score attached to a specific cycle.
Get the sleep record attached to a specific cycle.
Get the authenticated user's basic profile (name, email, user id).
Get a single sleep record by id.
Output schemas not documented. Tools return text-wrapped JSON via textResult() but LLMs cannot infer field structure, types, or which fields are safe to chain into downstream calls. Whoop API responses (cycles, recovery, sleep, workouts) contain rich data but no schema is published.
Error handling lacks recovery guidance. No try-catch blocks visible in tool implementations; API errors (auth failures, rate limits, invalid IDs) will surface as raw exceptions. LLMs receive no actionable next steps (e.g., 'Cycle not found. Try list_cycles() to find valid IDs').
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Get a single workout by id.
List physiological cycles in descending order by start time. Each cycle has strain and heart rate data.
List recovery records (recovery score, resting HR, HRV, SpO2, skin temperature) paginated and filterable by time range.
List sleep records with stage durations and sleep performance.
List workouts with sport classification, strain, average heart rate, distance, and HR zone durations.
Parameter descriptions lack prescriptive constraints. RFC3339 format is validated in Zod but not explained in descriptions (e.g., 'start' param says 'RFC3339' but does not clarify timezone handling, whether fractional seconds are required, or what happens if end < start).
No pagination guidance in descriptions. list_* tools accept limit (1-25, default 10) and next_token but descriptions do not explain when to use next_token, how to detect end-of-results, or whether results are sorted deterministically for chaining.
No dependency hints between tools. Descriptions do not explain that get_cycle_recovery and get_cycle_sleep require a cycle_id from list_cycles or get_cycle first, forcing LLMs to discover this relationship through trial-and-error.