WHOOP MCP by usefulapi

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 behavioral context beyond that: the authoritative REST endpoint (GET /v2/user/measurement/body) and the required OAuth scope (read:body_measurement), which tells the agent about auth requirements. It does not, however, address caching, update frequency, or what happens if measurement data is absent.

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?

It is a single sentence followed by the endpoint and scope, all front-loaded with the resource first. The endpoint path is arguably redundant with the tool's identity, but the scope reference earns its place. 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 and no parameters, the description carries the burden of describing returns, and it does so by naming the three fields and their units. Nothing critical is missing for a simple parameterless read, though it never says how to interpret the values or handle missing data.

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, so the baseline is 4 per the rubric. The description usefully documents the units of the returned values (meters, kilograms), which adds meaning even though there are no inputs to describe.

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 names a specific resource (the user's body measurements) and enumerates the exact fields returned (height in meters, weight in kilograms, max heart rate), so an agent can distinguish it from siblings like whoop_get_profile or whoop_get_cycle. It is clear but never explicitly contrasts itself with those 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?

There is no statement of when to call this versus whoop_get_profile or the other read tools, and no prerequisites or conditions are given. The only implicit cue is that it is a static user attribute lookup. No exclusions or alternatives are offered.

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. The description adds real behavioral context beyond that: the underlying REST endpoint (GET /v2/cycle/{cycleId}) and the required OAuth scope (read:cycles), which tells the agent what auth is needed. It does not discuss error behavior for an invalid id, but that is minor.

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?

Front-loaded purpose followed by returned fields, endpoint, and scope in a compact block with no filler. The endpoint path is slightly redundant but is legitimately useful identifying context.

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 read-only single-resource fetch with no output schema, the returned-field list compensates well for the missing return documentation, and the scope note covers auth. Only explicit routing to whoop_list_cycles is absent.

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 schema already states cycleId is an integer obtainable from whoop_list_cycles. The description adds no parameter semantics beyond that, 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?

Specific verb+resource ('Get a single physiological cycle by its id') plus the payload fields it returns. The word 'single' differentiates it from whoop_list_cycles implicitly, though no sibling is named explicitly.

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 by 'by its id', which suggests the agent must already have a cycle id, but there is no explicit when-to-use vs when-not guidance and whoop_list_cycles is not named as the alternative for enumerating cycles.

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 goes beyond that by disclosing the required OAuth scope ('read:recovery') and the underlying REST route, which tells the agent about authorization requirements before it attempts the call. Since there is no output schema, listing the returned fields (recovery %, RHR, HRV RMSSD, SpO2, skin temp) also adds real behavioral value.

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 compact fragments with no filler: purpose and returned fields first, then endpoint and scope. Nothing is repeated or padded, and the most decision-relevant information leads.

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-parameter, read-only tool with no output schema, the description is nearly sufficient: it enumerates the return fields and states the auth scope. It stops short of describing the response shape (e.g. whether recovery is a nested score object) but leaves no ambiguity about how to invoke the 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 description coverage is 100% and the schema already explains that cycleId is an integer obtained from whoop_list_cycles. The description only restates that the cycle is 'specific' and adds no format, example, or constraint beyond the schema, so the baseline of 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 ('Get the recovery scored for a specific cycle') and enumerates the returned metrics, so the agent knows exactly what comes back. The phrase 'a specific cycle' implicitly separates it from the sibling whoop_list_recoveries, but no sibling is named explicitly.

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?

There is no statement of when to use this tool versus whoop_list_recoveries or whoop_get_cycle, and no prerequisites or exclusions are given. The REST endpoint and scope note are provenance, not usage guidance; the caller must infer the workflow (obtain a cycleId, then fetch its recovery) 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?

Annotations declare readOnlyHint=true, and the description adds concrete context beyond them: the exact REST endpoint (GET /v2/user/profile/basic) and the required OAuth scope (read:profile). That scope disclosure is genuinely useful for an agent reasoning about authorization failures, though it says nothing about rate limits or error 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?

Three tight fragments — purpose, endpoint, scope — with the returned fields front-loaded. No filler, no repeated information, and the most important clause comes first.

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 zero-parameter read tool with no output schema, the description compensates by listing the returned fields and giving the endpoint and scope. Nothing an agent needs in order 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?

The tool takes zero parameters, so no parameter semantics are needed; baseline is 4. The description correctly adds no param noise.

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 ('The current user's basic WHOOP profile') and enumerates the exact fields returned (user id, email, first/last name). This cleanly distinguishes it from sibling tools like whoop_get_cycle or whoop_get_sleep, which target different resources.

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 by the resource name — an agent can infer this fetches profile data — but there is no explicit when-to-use statement, no conditions, and no named alternatives. Given the siblings are all disjoint resources, ambiguity is low, so this is adequate but not enriched.

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 required auth scope (read:sleep), the endpoint, and the shape of what comes back (stage summary, sleep needed, respiratory rate, sleep performance %, start/end). It does not discuss errors for invalid/expired ids, 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?

A single dense sentence that front-loads the action and id requirement, then packs endpoint, returned fields, and scope with no filler. Every clause carries information an agent would otherwise have to infer.

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 one-parameter read tool with no output schema, the description supplies the return fields, the auth scope, and the endpoint, while annotations cover the safety profile. Nothing needed to invoke it 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% and the schema already explains that sleepId is a UUID obtainable from whoop_list_sleep. The description adds nothing about the parameter beyond what the schema states, so the 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 ('Get a single sleep activity by its id') and pins it to the exact WHOOP REST endpoint GET /v2/activity/sleep/{sleepId}. The word 'single' cleanly distinguishes it from the sibling whoop_list_sleep, 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?

'By its id' establishes the retrieval precondition and implies use only after a sleep id is known, and the schema explicitly points to whoop_list_sleep as the id source. There is no explicit when-not guidance, but for a by-id fetch the usage context is unambiguous.

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 adds real value by disclosing the required OAuth scope (read:workout) and the underlying REST endpoint. It does not cover error behavior or rate limits, but the scope disclosure is meaningful 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?

Three compact segments (purpose, returned fields, REST/scope) with the purpose front-loaded. The field enumeration is list-heavy but earns its place since there is no output schema.

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 getter with no output schema, the description compensates by enumerating the returned fields, plus naming the endpoint and scope. Only usage routing and error/pagination behavior are absent, which is minor for a read-only one-param 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% and the workoutId description already documents the UUID format and its source (whoop_list_workouts). The description adds only 'by its id', so the baseline 3 applies with the schema carrying the weight.

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 a single workout by its id') and enumerates the returned fields (sport, strain, HR, distance, zone durations, start/end). The 'single' framing implicitly separates it from whoop_list_workouts, though it doesn't name that sibling explicitly.

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: the workoutId schema description points to whoop_list_workouts as the source, which hints at the list-then-get workflow. There is no explicit when-to-use vs when-not guidance or any statement of the alternative to this tool.

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 tells the agent this is a safe read, so the bar is lower, and the description still adds real context: the required OAuth scope (read:cycles), the underlying REST endpoint, cursor-based pagination via nextToken, and the shape of each returned score (day strain, kilojoules, HR averages). It does not mention rate limits or error behavior, but it clears the annotation-adjusted bar.

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?

Four tight sentences with the core purpose front-loaded and no filler; the definition of 'cycle' comes before the mechanical details. The 'WHOOP REST: GET /v2/cycle' clause and the pagination parenthetical are mildly redundant with the schema, keeping it just short of a 5.

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 carries the return-value burden by naming the score fields (day strain, kilojoules, avg/max HR), and it also covers pagination, filtering, ordering, and required scope. An agent has everything needed to call this tool correctly without opening other tools.

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. The description echoes the pagination (limit/nextToken) and created-time window (start/end) semantics without adding format or edge-case detail beyond what the schema states, so the baseline of 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 (List) and resource (physiological cycles), and goes further by defining the domain term as a WHOOP 'day' (~24h anchored to sleep), which an agent cannot infer from the name. Ordering ('most recent first') is also stated, so an agent can distinguish it from the singular whoop_get_cycle and the parallel list 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?

The description implies when to use it (bulk listing, filtered by created-time window) but never explicitly contrasts with siblings like whoop_get_cycle for a single cycle or whoop_list_recoveries for recovery data. Usage is inferable from the verb and filters, but there are no stated exclusions or alternative-routing guidance.

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, so the description carries most of the burden and does well: it discloses required scope (read:recovery), page-size cap and cursor mechanics, ordering, and the fact that each record links to its cycle and sleep. It stops short of rate-limit or error behavior, keeping 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?

Three sentences, front-loaded with identity and ordering. The parenthetical listing of returned signals is not padding – with no output schema it is the only place an agent learns what a recovery contains – and the endpoint/scope tail is compact.

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 four-parameter listing tool with no output schema, the description covers identity, ordering, returned fields, pagination behavior, filtering, endpoint, and required scope. Nothing an agent needs to call it 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% – start/end ISO-8601 semantics, the 1–25 limit bound, and the nextToken cursor are all already documented in the schema. The description only restates limit/nextToken and the start/end window, adding no syntax or format meaning beyond it, which is the baseline 3.

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'), which separates it from the singular whoop_get_cycle_recovery sibling. The underlying WHOOP REST endpoint (GET /v2/recovery) and scope (read:recovery) pin the purpose down unambiguously.

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 naming the pagination and created-time filtering affordances, so an agent can infer when this list tool is appropriate. However, it never states when to prefer this over whoop_get_cycle_recovery or whoop_list_cycles, nor any exclusions or prerequisites.

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 behavioral context on top: result ordering (most recent first), pagination via limit/nextToken, filtering by created-time window, required scope read:sleep, and the shape of what a record carries. It stops short of rate-limit or pagination-exhaustion details.

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 tightly packed sentences: scope/ordering first, then payload contents, then pagination/filtering and endpoint/scope. No filler, everything front-loaded and each clause earns its place.

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, and the description compensates by enumerating the returned fields (score, sleep-stage summary, sleep needed, respiratory rate, sleep performance %). Combined with pagination and filtering behavior and the declared scope, 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 start, end, limit and nextToken fully. The description restates the limit/nextToken pagination and start/end window without adding format or edge-case detail beyond the schema, so the 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 (list) and resource (user's sleep activities) plus the ordering ('most recent first') and the underlying endpoint GET /v2/activity/sleep with scope read:sleep. This clearly distinguishes it from the singled-record sibling whoop_get_sleep.

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 context is implied by 'List the user's sleep activities' and the mention of pagination and created-time filtering, but there is no explicit when-to-use guidance or routing away from whoop_get_sleep / whoop_list_recoveries. An agent can infer the browsing use case but is not told the alternatives.

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 supply readOnlyHint=true, so the description carries real weight here and delivers: sort order, pagination model, the created-time filter semantics, the underlying REST endpoint (GET /v2/activity/workout), and the required scope (read:workout). It stops short of auth/rate-limit or error behavior, but adds substantially 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?

Three tight sentences: purpose and ordering first, returned fields second, pagination/filtering and endpoint/scope last. Every clause carries information; nothing is redundant with 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 usefully summarizes the response payload (score, strain, HR, distance, zone durations) and the pagination/filter contract, which is what an agent needs to call it. It does not cover failure modes, token expiry, or rate limits, leaving minor gaps for a network-backed 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 already 100%, so the baseline is 3. The description goes slightly beyond the schema by framing start/end as a 'created-time window' (clarifying which timestamp is filtered) and by tying limit/nextToken together as one pagination mechanism, which helps the agent combine the parameters correctly.

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 workouts') plus an ordering guarantee ('most recent first') and enumerates the returned data (score, strain, HR, distance, zone durations). It is clearly a plural/list counterpart to whoop_get_workout, but it never explicitly names that sibling, so differentiation is inferential rather than stated.

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?

It discloses the mechanical usage pattern — paginated via limit/nextToken, filterable by a created-time window via start/end — which implies how to call it. However, it gives no when-to-use guidance, no exclusions, and does not route the agent to whoop_get_workout for a single record or to sibling list tools.

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