whoop

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful operational context beyond that: the exact REST mapping (GET /v2/user/measurement/body) and the required OAuth scope (read:body_measurement), which tells the agent what authorization is needed before calling. It does not mention rate limits or caching 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?

Two sentences, zero waste. The payload (what the user gets back) is front-loaded, and endpoint/scope metadata is compressed into a trailing clause.

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 present, the description compensates by naming the returned fields and their units, and it adds endpoint and scope information. For a zero-parameter read-only tool this covers everything an agent needs to call it and interpret the response.

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?

Zero parameters, so the baseline of 4 applies. The description goes slightly beyond by documenting the units of the values returned (meters, kilograms), which helps the agent interpret results correctly even though those are not parameters.

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?

States a specific verb+resource (get body measurement) and immediately enumerates the fields returned with units (height in meters, weight in kilograms, max heart rate). No sibling covers body measurement, so the resource name alone disambiguates it from the cycle/sleep/workout/profile siblings.

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 resource name implies when the tool is relevant (whenever the agent needs the user's height/weight/max HR), but there is no explicit when-to-use statement, no exclusions, and no named alternative. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, but the description adds real value on top: the required OAuth scope (read:cycles), the underlying REST endpoint (GET /v2/cycle/{cycleId}), and the payload contents (strain, kilojoules, avg/max heart rate, start/end). It does not discuss error behavior for invalid ids, but the added behavioral context exceeds the annotation baseline.

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?

Two compact clauses: the core action and returned fields first, then the REST route and scope. Every element is informative and front-loaded, with no filler or repetition of the title.

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 compensates by naming the returned fields, and it covers the auth scope needed to call it. Complete enough for a simple one-parameter read; only pagination/error semantics are absent, which are marginal here.

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 description coverage is 100% and there is a single parameter, so the schema already documents cycleId fully (including the example provenance). The description adds no syntax or format detail beyond 'by its id', so baseline 3 is appropriate.

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?

States a specific verb (get), resource (physiological cycle), and scope (single, by id), and enumerates the returned fields. The phrase 'a single ... by its id' clearly distinguishes it from the sibling whoop_list_cycles, so an agent can route without opening either schema.

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?

Usage is only implied: 'by its id' signals it needs an existing cycle id, and the schema note points to whoop_list_cycles as the source. There is no explicit statement of when to prefer this over whoop_list_cycles or any prerequisites/exclusions, so it sits at the minimum-viable tier.

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

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

Annotations already declare readOnlyHint=true, and the description adds material context beyond them: the required OAuth scope (read:recovery) and the exact REST route. It does not disclose failure modes (e.g., unscored cycles or missing data), which keeps it short of a 5.

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?

Two tightly packed sentences: the payload summary is front-loaded, followed by endpoint and scope. No filler, though the endpoint/scope tail reads as reference metadata rather than agent guidance.

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?

No output schema exists, but the description compensates by enumerating the returned recovery fields, and the single required parameter is fully covered by the schema plus the required scope. An agent has everything needed 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 description coverage is 100% — cycleId's type, minLength and provenance are already documented in the schema — so the description adds no syntactic or format detail about the single parameter. Baseline 3 applies.

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?

States a specific verb+resource ('Get the recovery scored for a specific cycle'), enumerates the returned metrics (recovery %, RHR, HRV RMSSD, SpO2 %, skin temperature), and names the exact REST endpoint, which cleanly distinguishes it from the sibling whoop_list_recoveries.

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 tool's use case (fetch recovery for one known cycleId) is implied, and the schema notes the cycleId comes from whoop_list_cycles. However, it never explicitly states when to prefer this over whoop_list_recoveries or whether the cycle must be completed/scored, leaving selection to inference.

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

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

Annotations already declare readOnlyHint=true, but the description adds real context beyond them: the underlying REST endpoint (GET /v2/user/profile/basic) and the required OAuth scope 'read:profile'. That auth prerequisite is genuinely useful for an agent deciding whether the call will succeed.

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?

Three short fragments, front-loaded with the outcome, then endpoint, then scope. No filler sentences and nothing repeated from the schema or annotations.

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?

No output schema exists, so the description carries the return-value burden and does so by listing the concrete profile fields. For a zero-parameter, read-only identity lookup, nothing an agent needs to call and interpret it is missing.

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 takes zero parameters, which is the baseline-4 case. The description does not need to explain inputs, and instead names what the identity fields returned are.

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?

States a specific verb and resource ('The current user's basic WHOOP profile') and enumerates the returned fields (user id, email, first name, last name). It is unambiguously distinct from the cycle/sleep/workout/recovery siblings, which are all time-series data tools.

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?

Usage is implied rather than stated: the only profile tool among the siblings, and 'Scope: read:profile' signals the required OAuth permission. There is no explicit when-to-use/when-not or alternative named, so guidance remains at the minimum viable level.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds value beyond that by disclosing the required OAuth scope (read:sleep) and the exact REST endpoint it wraps. It does not mention error behavior for an unknown id, which keeps it from a 5.

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?

One front-loaded sentence leads with the core operation before the endpoint and scope metadata. The endpoint and scope lines are compact and useful rather than padding, though they add mild density.

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?

There is no output schema, so the description compensates by naming the payload contents (stage summary, sleep needed, respiratory rate, sleep performance %, start/end) and the auth scope. Nothing essential for correctly calling this one-parameter read is missing.

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 description coverage is 100% and documents the single parameter as a UUID from whoop_list_sleep, so the schema carries the parameter meaning. The description restates 'by its id' without adding format or edge-case detail, matching the baseline for full schema coverage.

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?

States a specific verb (Get) and resource (a single sleep activity) plus the lookup key (id), and the word 'single' implicitly separates it from the sibling whoop_list_sleep. The parenthetical enumerates the returned fields, so an agent knows exactly what it gets back.

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?

Usage is only implied: 'by its id' signals a keyed fetch, and the schema notes the id comes from whoop_list_sleep, but the description itself never states when to use this instead of whoop_list_sleep or what to do when the id is unknown. Adequate but with a clear routing gap.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real context beyond that: the underlying REST path (GET /v2/activity/workout/{workoutId}) and the required scope read:workout, which tells the agent about auth prerequisites. It stops short of error/rate-limit 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?

Two compact sentences, front-loaded with the core action and field list, followed by endpoint and scope. Efficient with essentially no filler, though the parenthetical field dump is slightly dense.

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?

For a single-resource read with one fully documented parameter and no output schema, the description covers the resource, the identifying key, the response fields, the endpoint, and the scope. Only error/pagination behavior is absent, which is minor here.

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 description coverage is 100% and the single parameter is documented in the schema (UUID format, source tool). The description only restates 'by its id', adding no new syntax or format meaning beyond the schema. Baseline 3 applies.

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?

States a specific verb ('Get') and resource ('a single workout by its id') and enumerates the returned fields (sport, strain, heart rate, distance, zone durations, start/end). The 'single' scoping implicitly separates it from the list_workouts sibling.

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?

Usage is only implied: an agent understands it needs a workoutId, and the schema notes the id can come from whoop_list_workouts. There is no explicit when-to-use vs when-to-prefer-list guidance or any exclusion in the description itself.

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

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

Annotations only give readOnlyHint=true, so the description carries the rest: it discloses ordering, the shape of each cycle's score payload, pagination mechanics, the created-time filter window, and the required read:cycles scope. It does not describe rate limits or error behavior, but adds substantial context beyond the annotation.

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?

Five tight sentences, each contributing distinct information: domain definition, payload contents, pagination, filtering, and endpoint/scope. Front-loaded with purpose and free of filler.

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 usefully names the returned fields (day strain, kilojoules, heart rate) and the next_token cursor. Combining the endpoint, scope, and filter semantics makes it callable without further guesswork; only response envelope details are left implicit.

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 all four parameters are already documented in the schema. The description restates limit/nextToken pagination and the start/end window without adding format or defaulting detail beyond what the schema provides — baseline 3 is correct.

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?

States a specific verb and resource ('List the user's physiological cycles'), defines the domain term ('a WHOOP day, ~24h anchored to sleep'), and specifies ordering, contents, pagination, filters, and the underlying endpoint. This clearly separates it from the singular sibling whoop_get_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?

Conveys implied usage through 'most recent first' and 'filterable by created-time window', but never states when to prefer this over whoop_get_cycle or how it relates to whoop_list_recoveries/whoop_list_sleep. The agent must infer list-vs-get from the name alone.

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

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

With readOnlyHint=true already covering the safety profile, the description adds real behavioral context: pagination mechanics via limit/nextToken, created-time filtering, the underlying REST endpoint (GET /v2/recovery), and the required read:recovery scope for auth. It omits practical traits like rate limits or the possibility of missing recoveries for unscored cycles.

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?

Three tight sentences: scope of the list, returned fields, then pagination/filtering, followed by two compact metadata lines (endpoint, scope). Front-loaded and every clause carries information; nothing redundant.

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?

There is no output schema, so the description correctly compensates by enumerating the fields each recovery contains and its links to cycle and sleep, plus the pagination and filtering model. An agent has enough to call it correctly and interpret results.

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 description coverage is 100%, so the schema already fully documents end, limit, start and nextToken, including the ISO 8601 format and the 1-25 range. The description only restates the existence of limit/nextToken and start/end without adding format or constraint detail, so baseline 3 applies.

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?

States a specific verb and resource ("List the user's recoveries") plus ordering ("most recent first") and the payload it returns (recovery %, RHR, HRV RMSSD, SpO2, skin temperature). It also distinguishes itself from the single-record sibling whoop_get_cycle_recovery by nature of being a listing, and from whoop_list_cycles/sleep/workouts by resource.

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?

Gives clear context for when this applies: bulk retrieval of recoveries, filterable by created-time window, paginated. It does not explicitly name the alternative single-record tool or state exclusions (e.g. it never says recoveries only exist for scored days), so it stops short of a 5.

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

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

Annotations only declare readOnlyHint=true, so the description must carry most of the load and it does: ordering (most recent first), pagination mechanics, the filter axis (created-time), the REST endpoint, and the required OAuth scope read:sleep. It is silent on rate limits and response envelope details, which keeps it at a 4.

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?

Three dense sentences, front-loaded with purpose and ordering, then return contents, then pagination/filtering, then provenance and scope. No redundancy and no filler.

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 compensates by enumerating the fields each sleep record carries, and it also covers pagination, filtering, endpoint, and required scope. Nothing an agent needs to call this correctly is missing.

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 description coverage is 100%, so all four parameters are already documented in the schema, including limits, ISO 8601 format, and the next_token handoff. The description's mention of pagination and the start/end window largely restates that, adding only the 'created-time' framing, so baseline 3 is correct.

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?

States a specific verb and resource ('List the user's sleep activities') plus ordering ('most recent first'), and the enumeration of returned fields (score, sleep-stage summary, sleep needed, respiratory rate, performance %) makes the scope concrete. An agent can distinguish it from the singular whoop_get_sleep without opening either schema.

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?

Gives clear usage context: this is the paginated, filterable listing for sleep records, with limit/nextToken and a created-time window called out. It stops short of naming an explicit alternative (e.g., whoop_get_sleep for a single activity) or stating when not to use it, so it does not reach the top of the scale.

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

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

readOnlyHint=true already establishes the safety profile, and the description adds real context on top: result ordering, the pagination mechanism, the time-window filter, and the required read:workout scope. It stops short of noting rate limits or response envelope details, which keeps it at a solid 4.

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?

Three dense sentences, front-loaded with the core purpose and followed by return fields, pagination, and scope. No redundant restatement of the name or title.

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 usefully compensates by listing what each workout carries (strain, HR, distance, zone durations). Scope, pagination, and filtering are all covered, so an agent has everything needed to call 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 description coverage is 100%, so the schema already documents all four parameters including formats and the limit range. The description only names the parameters (limit/nextToken, start/end) without adding syntax or constraint detail, matching the baseline.

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?

States a specific verb (List) and resource (user's workouts) plus ordering (most recent first), which cleanly separates it from whoop_get_workout and the list_cycles/list_sleep siblings. It also enumerates the returned fields, so the agent knows what the tool yields.

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?

Frames the tool's operation context clearly: paginated via limit/nextToken and filterable by a created-time window (start/end). It does not explicitly say when to prefer it over whoop_get_workout for a single workout, but the list-vs-get distinction is inferable.

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