WHOOP

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

Annotations already state idempotentHint=true and destructiveHint=false, so the description doesn't need to repeat that. It adds valuable behavioral context: the permanence of config-based auth versus session-only login, and that calling with no args returns a link. No contradictions with annotations; the description enhances transparency.

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 a single block of 2-3 sentences and is front-loaded with the core purpose. It covers both modes without excessive verbosity, though it could be tightened slightly (e.g., 'MCP.AI for IDE agents' is a bit odd). Overall, it's efficient and well-structured.

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 tool with one optional param and no output schema, the description fully covers the two invocation modes and what happens in each. It doesn't explain error handling or return format beyond getting a link, but that's acceptable given the simplicity. It's complete for the agent's needs.

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 schema provides only a bare 'token' string without description, and schema coverage is 0%. The description compensates by explaining the token parameter as a JWT for session-only login and describes the no-args behavior. It doesn't detail edge cases (e.g., invalid tokens) but gives enough for correct invocation.

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's purpose: to authenticate to the MCP server by either generating a login link (no args) or accepting a JWT token for session login. It explicitly identifies the resource (the server) and the action (authenticate), and distinguishes from siblings like connect by focusing on auth mechanics.

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 gives explicit when-to-use guidance: recommends adding the token to server config for permanent access, and offers session-only login via token pasting. Also specifies the exact call patterns (with token or no args) and the workflow for IDE agents (browser login, copy token). This covers both usage context and 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?

The description goes beyond the annotations by explaining the two possible outcomes: authenticated state with empty pending, and missing credentials with connect_url. This provides useful behavioral detail that annotations do not cover.

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 (two sentences) and well-structured, presenting the core function and conditional outcomes without unnecessary verbosity.

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 the tool has no parameters and no output schema, the description sufficiently covers the essential return information (status and URLs) and the conditional behavior, making it complete for its simplicity.

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?

There are no parameters in the schema, so there is nothing to clarify. The description appropriately omits parameter details, and no missing semantics are apparent.

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 returns connection status and URLs, distinguishing it from sibling tools like authenticate or marketplace. It precisely identifies the operation as a check, not a mutation.

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?

While the purpose is clear, the description does not explicitly specify when to use this tool versus alternatives (e.g., 'use this to verify connectivity' or 'instead of authenticate'). It describes the behavior but lacks direct usage 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 provide readOnlyHint=false and destructiveHint=false, but the description adds rich behavioral context: invoke runs tools without installing, returns connect/checkout links based on credentials/wallet state, and the one-off install behind invoke. It also mentions that search/describe flag installation status. No contradictions with annotations; the description goes well beyond them.

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 a single dense paragraph covering 14 actions plus prompt library. Every sentence adds value, but the lack of bullet points or segmentation makes it hard to scan. It is verbose, though justified by the tool's complexity. Structure could be improved for readability without cutting 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 23 parameters and no output schema, the description covers the major flows comprehensively: search→describe→invoke, install vs invoke, billing via subscribe/cancel, prompt library, and auth/wallet edge cases. It explains return behavior for invoke (links) and describe (profile). It does not detail every possible action's response, but for an agent-facing description it is almost complete.

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 0% and there are 23 parameters. The description indirectly explains many via workflows (e.g., 'arguments' as JSON string, 'mcp_id' and 'tool_id' for describe/invoke, prompt-related params like prompt_title, prompt_slug, prompt_vars). However, it doesn't systematically enumerate or define each parameter, leaving some (like limit, immediate, cancel_comment) under-explained. Given the scale, the compensation is adequate but not thorough.

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's purpose: 'the in-platform catalog of every MCP/tool, AND the way to run them.' It explicitly differentiates from siblings like whoop tools by covering marketplace actions (search, describe, invoke, install) and prompt library functions. The verb-resource pairs are specific and the core flow is laid out.

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 explicit when-to-use guidance: 'prefer invoke for a single/occasional use' and 'use install only to make an MCP PERMANENT'. It also explains the distinction between subscribe/cancel for billing, and notes that writes require workspace owner/admin. It even covers fallback scenarios like connect and checkout links with retry instructions.

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 indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the description is not required to restate those. It adds mild behavioral context by asking for the conversation array for reproduction, implying the feedback goes to developers. However, it does not disclose potential external side effects (e.g., network transmission, ticket creation) beyond the verb 'report.' No contradictions with annotations, so score is not penalized further.

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 a single, front-loaded sentence: it states the action in the first clause and provides a targeted instruction in the second. Every word adds value and there is no redundant 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?

For a three-parameter tool with no output schema, the description covers the core operation and the most important parameter. However, the optional 'context' parameter is ignored, and there is no statement about what happens after reporting (e.g., acknowledgment or response). These are minor gaps for a simple feedback tool, but the description is mostly complete.

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 0%, so the description must compensate. It clarifies the purpose of 'message' (the bug/feedback text) and 'conversation' (recent messages for reproduction), but the 'context' parameter is left completely undocumented. This partial compensation earns a middle score.

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's function with a specific verb and resource: 'Report a bug, missing feature, or send feedback.' It distinguishes itself from all sibling tools, which are account/data retrieval or device tools, with no overlapping purpose.

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 the tool: whenever a bug, missing feature, or feedback is needed. It does not explicitly name alternatives, but no sibling tool serves a similar purpose, so exclusions are unnecessary. Slight deduction for not explicitly saying 'use this when'.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that the tool returns current version information, but beyond that it does not disclose output format, pagination, or any other behavioral 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?

The description is a single, direct sentence that front-loads the action and the target information. There is no redundant content or unnecessary elaboration.

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 the tool's simplicity, zero parameters, and strong annotation coverage, the description is nearly complete: it identifies what versions are shown and that the operation is read-only. It would be slightly stronger if it hinted at the response shape, since no output schema is provided, but this is not a major gap for a version query.

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 has zero parameters, so there is no parameter meaning for the description to add beyond the empty schema. With 0-parameter tools, this dimension is trivially satisfied and warrants the baseline score of 4.

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 a specific verb ('Show') and resource ('current MCP platform and adapter versions'), making the tool's purpose clear and distinct from the data-focused Whoop siblings. However, it does not explicitly differentiate from sibling 'toolkit_info', which could plausibly overlap with version information.

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 for checking current versions, but it gives no explicit guidance on when to choose this tool over alternatives or when it would be inappropriate. For a simple version-info tool, the implied context is reasonable, though not fully spelled out.

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 establish that this is read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond those annotations by specifying exactly what information is reported (installed MCPs, connection status, accounts, catalog tool counts) and emphasizing that it reflects the 'current' state.

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 a single, well-structured sentence that front-loads the action and resource, then packs the key output items into a clear list. Every word contributes meaning, and there is no repetition of the tool name or 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 parameterless, read-only introspection tool, the description is complete: it explains what the tool returns and covers the main information an agent would need. Since there is no output schema, the description appropriately carries the burden of describing the return values, and it does so sufficiently.

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 has zero parameters and an empty input schema, so there is no parameter semantics burden on the description. The baseline score of 4 applies because no parameters need explanation.

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 a specific verb ('Returns') and a clearly defined resource ('the current toolkit state'), followed by concrete details about what that state contains: installed MCPs, connection status, connected accounts, and catalog tool counts. This is enough to distinguish it from sibling tools like show_version or whoop_list_accounts, 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?

The description makes its intended use clear: call this tool when you need an overview of the toolkit's installed MCPs and their connection status. It does not explicitly mention when not to use it or name alternatives, but the context is straightforward and there are no competing tools with the same purpose.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds a valuable caveat that the data is from a wearable and not a substitute for professional medical evaluation, which exceeds the annotation coverage and provides transparency about data limitations.

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, using two short sentences to convey the tool's purpose and a caveat. No unnecessary words or redundancy; it is well-structured and direct.

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?

The description gives the core data fields and a medical disclaimer, but omits any explanation of the input parameter and does not mention output format or potential optionality of fields. Given the simple nature of the tool, the description is adequate but leaves gaps about parameter handling.

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 only parameter 'account' is entirely unexplained in both the schema and the description. The description does not clarify what 'account' refers to (e.g., user ID, member ID), leaving the parameter ambiguous. Since schema coverage is 0%, the description should compensate but does not.

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 that the tool provides body measurements (height, weight, maximum heart rate) for a WHOOP member, which distinguishes it from sibling tools like whoop_cycles or whoop_sleep. The resource and implied action are unambiguous.

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 the tool (when body measurement data is needed) but does not explicitly differentiate it from alternatives or state any preconditions. The specificity of 'body measurements' gives clear context, though explicit usage guidance is lacking.

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, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context about pagination (limit/start/end/next_token) and the ability to query specific cycles with cycle_ids, plus a non-medical disclaimer. This goes beyond the annotations without contradicting them.

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 two sentences, front-loaded with key data fields, and contains no fluff. Every clause adds informational value.

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 the lack of an output schema, the description usefully names returned fields and pagination behavior. However, with six parameters, no output schema, and no mention of account/auth or output shape, the description is only moderately complete for an agent to confidently invoke and interpret 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 0%, so the description carries the burden of explaining parameters. It explains the purpose of limit/start/end/next_token and cycle_ids, but does not clarify the 'account' parameter, the format of start/end, or default limits. This is partial compensation for the missing 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 clearly identifies the resource as WHOOP physiological cycles and lists the specific data fields (strain, calories, average/max heart rate), which helps distinguish it from sibling WHOOP tools like sleep, recovery, or workouts. However, it lacks a direct imperative verb like 'list' or 'retrieve' in the main clause, relying instead on 'buscar' later in the description.

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 the tool: for daily WHOOP cycle data with pagination, or for specific cycles via cycle_ids. It does not explicitly contrast with sibling WHOOP tools or state exclusions, but the data fields and 'dia a dia' scope provide reasonable contextual 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 already state readOnly, idempotent, and not destructive. The description says 'lists', which is consistent but adds no additional behavioral details beyond confirming read-only nature. No contradictions.

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 a single, clear sentence without unnecessary words. It efficiently conveys the tool's function and output fields.

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?

The description lacks critical context such as whether authentication is required, the return format (e.g., list of objects), error conditions, or how the result might be used. The unexplained parameter further reduces completeness.

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 only parameter 'account' is not explained at all. It is a string and optional, but its purpose (filter? identifier?) is unclear. Since schema coverage is 0%, the description must compensate but does not.

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 lists WHOOP accounts linked to the install and specifies the fields returned (account_id, name, email). This distinguishes it from sibling tools like whoop_profile or whoop_workouts.

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 indicates the accounts are linked to the install, implying a query for all associated accounts. However, it does not explicitly state when to use this versus alternatives or provide any usage context (e.g., retrieving account IDs for subsequent calls).

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, idempotentHint, and non-destructive behavior. The description adds the return fields but does not disclose any other behavioral aspects like error conditions or authentication requirements, which is acceptable given the read-only 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 a single sentence that immediately conveys the purpose and expected response, with no unnecessary words. It is front-loaded and efficient.

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?

Although the tool is simple and annotations cover safety, the description is incomplete because it does not explain the input parameter or provide any context about how to use the tool effectively. The lack of output schema and parameter semantics makes it insufficient for a complete understanding.

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 schema has a single parameter 'account' with no description, and the tool description does not mention it at all. With 0% schema coverage, the description fails to clarify what 'account' refers to (e.g., user ID, email), leaving the agent unable to correctly fill the parameter.

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 returns a basic WHOOP member profile with specific fields (user_id, nome, email). This distinguishes it from sibling tools like whoop_sleep or whoop_workouts, which focus on other data.

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?

No explicit guidance on when to use this tool versus alternatives such as whoop_list_accounts. It does not mention prerequisites like requiring a specific account identifier or any scenario-based usage.

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, idempotentHint, and non-destructive behavior, so the description adds meaningful context beyond those: pagination style, ability to query specific cycles, and the medical disclaimer about wearable data. This gives the agent a reasonable behavioral model without contradicting the annotations.

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 brief and front-loaded with the resource type and returned fields, then adds necessary behavioral details about pagination and filtering. Every sentence contributes meaningful information without wasted words.

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 there is no output schema, the description adequately outlines the returned metrics, pagination strategy, alternate query path via cycle_ids, and a safety caveat. It still leaves some gaps around the account parameter and default date-range behavior, but it is sufficient for a moderate-complexity read-only 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?

With 0% schema description coverage, the description carries the parameter semantics burden. It groups limit/start/end/next_token as pagination parameters and explains what cycle_ids does, but it does not clarify the format of start/end, the meaning of limit, or the account parameter, leaving several parameters under-specified.

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 indicates the tool retrieves WHOOP recovery data and enumerates key return fields (recovery_score, HRV, resting HR, SpO2, skin temperature), which distinguishes it from sibling WHOOP tools like whoop_sleep or whoop_workouts. However, it lacks an explicit verb such as 'fetch' or 'list', relying on the tool name and context to imply retrieval.

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 useful usage guidance by explaining pagination via limit/start/end/next_token and that cycle_ids fetch recovery for specific cycles. It does not explicitly compare against siblings or state when another WHOOP tool should be used instead, leaving some ambiguity around tool selection.

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?

The description adds behavioral context beyond annotations: it explains pagination via limit/start/end/next_token and the alternative of passing sleep_ids, and includes a disclaimer about wearable data not replacing medical advice. Annotations already declare read-only and idempotent, so this extra context is valuable.

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 concise sentences that front-load the data fields, then pagination details, and end with a disclaimer. No wasted words.

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?

The description is adequate for a read-only tool with no output schema: it lists the returned metrics, pagination options, and the alternative to fetch specific records. However, it could clarify the start/end format and the account parameter.

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 description explains the role of limit/start/end/next_token for pagination and sleep_ids for specific records, covering most parameters. However, the 'account' parameter is not described, and the exact meaning of start/end (e.g., date range vs cursor) is ambiguous.

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 that it provides WHOOP sleep data including duration, efficiency, performance, stages, and respiratory rate. It differentiates from sibling tools by focusing on sleep metrics, though it lacks an explicit verb like 'retrieve' or 'list'.

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 explicit guidance on when to use this tool versus sibling tools like whoop_workouts or whoop_recovery. It mentions pagination and sleep_ids but doesn't provide context for tool selection or exclusions.

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?

The annotations already declare readOnlyHint and idempotentHint as true, so the safety profile is clear. The description adds behavioral value by naming the returned data fields, the pagination mechanism, and a caution that wearable data is not a medical substitute, going beyond what the annotations provide.

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 three concise sentences with no filler: purpose/fields, pagination/specific ID usage, and a health-data disclaimer. Every sentence 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?

Given there is no output schema, the description provides enough context about the returned data and filtering modes for typical use. It is slightly incomplete because account semantics and some output details are not addressed, but overall this is a useful and sufficient description.

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 0%, so the description must compensate; it does explain the pagination parameters (limit/start/end/next_token) and workout_ids. However, the account parameter is left completely unexplained, which is the main 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 that the tool retrieves WHOOP workout data, enumerating the key fields (sport, strain, heart rates, HR zones, distance/elevation) and the two access modes: paginated or by workout_ids. It also distinguishes itself from sibling WHOOP tools like whoop_sleep and whoop_recovery.

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 gives practical usage context by explaining that results are paginated via limit/start/end/next_token or can be retrieved for specific records with workout_ids. It does not explicitly discuss alternatives or when not to use the tool, but the WHOOP-specific scope makes the intended use clear.

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