WHOOP MCP

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description reinforces safety by stating 'Does not read WHOOP or expose secrets', adding value beyond annotations without contradiction.

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, no redundancy. Every word serves a purpose. Front-loaded with key information.

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 simple tool with output schema, the description covers purpose and safety adequately but lacks parameter semantics. Given that there are no required parameters and low complexity, the missing parameter info is a gap.

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%, and the description does not explain the 'client' or 'response_format' parameters or their enum values. With only 2 enum parameters, the description should have provided guidance on their meaning and defaults.

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?

Description clearly states the tool provides machine-readable guidance for AI agents operating the WHOOP MCP, and explicitly states it does not read WHOOP data or expose secrets, distinguishing it from sibling tools that access WHOOP 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?

Description implies it is used for install and runtime guidance, but does not explicitly state when to use this tool vs alternatives like whoop_capabilities or whoop_onboarding. No exclusion criteria or context provided.

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=true and idempotentHint=true, and the description's 'Show' aligns with that. It adds the useful context that the cache is optional and how it's activated via environment variables, which is not in 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?

One concise sentence that front-loads the purpose and includes an important activation note. 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?

For a simple read-only status tool with an output schema and no required parameters, the description sufficiently covers the purpose and activation condition. The parameter is self-explanatory from the schema.

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 input schema has a single response_format parameter with clear enum and default values, but the description provides no additional meaning beyond the schema. With 0% schema description coverage, the description should compensate but doesn't mention the parameter at all.

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 'local SQLite cache status', clearly distinguishing it from sibling WHOOP tools which focus on data retrieval or configuration. It immediately conveys the tool's function.

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 states the tool is for the optional SQLite cache and explains how to enable it (WHOOP_CACHE=sqlite or true), giving clear context for when this tool is relevant. However, it doesn't explicitly name alternatives or state when not to use it.

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 readOnly, idempotent, non-destructive. Description adds that it does not read WHOOP or expose secrets, reinforcing safety and clarifying scope.

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 sentence efficiently conveys purpose, constraints, and scope. Front-loaded with key information.

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 an informational tool with output schema, description covers what it does, what it doesn't do, and scope. Output schema fills return format details.

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%, but the single optional parameter response_format is simple (enum with default). Description doesn't mention it, but the parameter is self-explanatory given tool purpose.

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?

Description clearly states the tool explains WHOOP data, unavailable raw sensor streams, privacy modes, workflow, and project links. It distinguishes from data retrieval tools by noting it does not read WHOOP or expose secrets.

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?

Description implies use for getting an overview of capabilities and limitations, but does not explicitly state when not to use or provide alternative sibling tools.

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 and idempotentHint, and the description adds important behavioral context: it does not call WHOOP and does not expose secrets. It also lists the specific components checked (env vars, token file, Node version, privacy mode, cache), going beyond 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 two sentences with no filler. The first sentence immediately states what is checked, and the second provides a safety note. It is front-loaded and every word contributes.

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 simple read-only status check, the description is largely complete: it covers purpose, scope, and safety. The presence of an output schema means return format is documented elsewhere. It lacks explicit guidance on when to use this vs sibling tools, but overall it is sufficient.

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 for parameter meaning. The description does not mention the 'client' or 'response_format' parameters at all. While the parameter names and enums are somewhat self-explanatory, the description adds no value in explaining them, leaving a 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 uses a specific verb 'Check' and identifies the exact resources checked: local WHOOP env vars, token file, Node version, privacy mode, and cache. It clearly distinguishes this from siblings by stating it does not call WHOOP, indicating a local-only readiness check.

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 clearly implies when to use this tool: to verify local readiness before making API calls. It also states it does not call WHOOP, providing context that this is safe. However, it does not explicitly name alternative tools or exclusion criteria for when not to use it, though siblings like whoop_get_profile and whoop_cache_status exist.

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 destructiveHint=false. The description adds valuable context: it states 'does not provide medical advice' and 'does not store data locally,' which are behavioral traits beyond the annotations. It also clarifies it fetches WHOOP v2 records, giving more operational detail.

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 short paragraphs. The first sentence is a clear, front-loaded purpose. The second paragraph succinctly lists what it does and adds disclaimers. It avoids excessive detail, though the second paragraph could be slightly tighter.

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 complexity (workflow combining multiple data sources) and the presence of an output schema, the description covers the main aspects: inputs (fetches recent records), processing (defensive baseline), and outputs (readiness, sleep, load, diagnostics, action candidates). It does not discuss authentication prerequisites, but the sibling context suggests auth is handled elsewhere.

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 67% (days and timezone are described, response_format has enum but no text). The description does not add parameter-specific meaning, but the schema already documents most parameters clearly. The response_format enum values (markdown/json) are self-explanatory, so no additional description is necessary.

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 opens with a specific verb and resource: 'Build a privacy-conscious daily performance summary from WHOOP recovery, sleep, cycle and workout data.' It clearly states the tool's function and distinguishes it from siblings like whoop_weekly_summary by focusing on 'daily' and the workflow nature.

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 describing the workflow (fetches records, computes baseline, returns recommendations) but never explicitly states when to use this tool vs alternatives. It does not mention exclusions or name sibling tools, so guidance remains implied rather than explicit.

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 destructiveHint. The description adds valuable context by stating it does not call WHOOP APIs and does not expose user data, which clarifies the tool's non-invasive nature and privacy boundary beyond the annotation flags.

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, immediately states the purpose, and then adds a key limitation. There is no filler or redundant wording; every word 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 the tool's simple inventory purpose and the presence of an output schema, the description adequately covers the tool's role, limitations, and content. It could optionally explain the response_format parameter, but the overall completeness is sufficient for orientation.

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 does not mention the response_format parameter at all. Since schema description coverage is 0%, the description should compensate, but it remains silent on how the parameter affects the output. The schema's enum and default provide some self-evidence, but the description adds no semantic value for this 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 uses the specific verb 'inventory' and lists concrete content areas (data domains, auth scopes, privacy boundary, recommended first calls). It explicitly distinguishes itself by stating it does not call WHOOP APIs or expose user data, making its role clear relative to sibling data-fetching 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 phrase 'recommended first calls' implies this is an entry-point tool for orientation, and the note about not calling WHOOP APIs suggests using it when you need an overview rather than actual data. However, it does not explicitly name alternative tools or provide direct when-to-use versus when-not-to-use 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?

The description adds the important behavioral guarantee that shapes are verified against real tools by a build gate, ensuring compatibility. Annotations already declare read-only and idempotent, so this is extra context beyond the structured data, not a contradiction.

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 with no filler. The first sentence front-loads the action and resources, the second adds a crucial reliability guarantee. Every word 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?

For a simple tool with no output schema and one optional parameter, the description covers purpose, usage context, and behavioral guarantees. It is complete enough for an agent to decide to call it and understand what to expect.

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%, and the description does not mention the 'response_format' parameter at all. The enum provides some indication, but the description fails to explain the trade-offs between markdown and json outputs, leaving the agent to infer meaning.

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 it 'returns realistic example payloads' of specific WHOOP tools, using a specific verb and resource. It distinguishes itself from the real sibling tools by being a demo, making the purpose 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 explicitly says it is for seeing the contract 'before calling real WHOOP APIs,' providing clear context for when to use it. It does not mention exclusions or alternatives by name, but the context is sufficient for a demo 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?

The annotations already indicate this is not read-only and not idempotent, but the description adds valuable behavioral details: tokens are stored locally with 0600 permissions and are never returned by the tool. This goes beyond the annotations and meaningfully informs an agent about side effects and safety.

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 short, front-loaded with the core purpose, and every sentence earns its place: the exchange action, local storage behavior, and the gating requirement. It does not waste words, though the gating instruction could be integrated more tightly with the rest of the usage 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?

With an output schema present, the description does not need to explain return values. It covers the essential operational facts: local token storage, permissions, non-return behavior, and the consent requirement. The only minor gap is guidance on what the agent should do after a successful exchange, but that is not necessary for correct invocation.

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 67%, and the schema already documents the key parameters: code accepts either an authorization code or a full redirect URL, state is recommended for PKCE verification, and response_format has an enum with a default. The description adds no parameter-specific guidance, but the schema carries sufficient meaning, so a baseline score 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?

The description states a specific action—exchanging a WHOOP OAuth authorization code for local tokens—with a clear resource and outcome. This is distinct from siblings like whoop_get_auth_url, whoop_connection_status, and whoop_revoke_access, so an agent can identify what this tool does without ambiguity.

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 clear context for when the tool should be used: as part of an OAuth exchange flow, and only with explicit user intent. It explicitly prohibits autonomous calls, which provides strong usage guidance, though it does not directly name alternative tools or state when not to use it.

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 idempotentHint=true, but the description adds that the tool 'does not read or modify WHOOP data,' which goes beyond the annotations by indicating it performs no WHOOP API reads at all—only URL generation. This is useful behavioral context not fully captured by the structured hints.

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 the core action, and every clause adds value: purpose, safety, and usage timing. No wasted words—compact yet informative.

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 tool is simple with an output schema present, so return format is covered elsewhere. The description covers purpose, non-data-touching behavior, and when to invoke it. It doesn't mention the next step (exchanging the code), but the sibling list includes whoop_exchange_code, making the flow inferable. Complete enough for a low-risk, 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?

The schema has high coverage (67%) and includes descriptive text for each parameter (e.g., 'Optional OAuth state value generated by the caller', 'Defaults to all read-only WHOOP scopes used by this server'). The description adds no additional parameter-level meaning beyond what the schema already provides, 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?

The description opens with a specific verb and resource: 'Generate a WHOOP OAuth authorization URL.' This clearly distinguishes it from sibling data-fetching tools, and the added note 'This does not read or modify WHOOP data' further differentiates it as a pure URL generator.

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 explicit guidance: 'Use this first when no local token exists.' This clearly indicates when to use the tool, though it does not explicitly name alternatives or exclude cases where a token already exists. The context is clear enough for an agent to sequence it early in the OAuth flow.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description adds the required OAuth scope and a medical disclaimer, which are useful behavioral context. It also implicitly confirms it's a read operation consistent with annotations. 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?

Three crisp sentences: purpose, scope, and disclaimer. Zero waste, front-loaded with the descriptive verb and resource.

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 simple read-only resource, the description covers purpose and scope, while annotations cover safety, and the schema covers parameters and output. The output schema exists, so return values are defined elsewhere. Minor gaps like whether measurements are historical or current are negligible for this 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?

The tool description itself adds no parameter semantics, but the input schema provides descriptions for two of three parameters (privacy_mode and explicit_user_intent) and an enum/default for response_format, giving roughly 67% coverage. The description could have noted the default response format or privacy behavior, but the schema largely compensates, so a 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?

The description clearly states the verb 'Get' and the resource 'WHOOP body measurements' with specific fields (height, weight, max heart rate), distinguishing it from sibling tools that list cycles, sleeps, etc. It also mentions the authentication scope, reinforcing its specific 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 this tool: when needing the authenticated user's body measurements. It doesn't explicitly name alternatives or exclusions, but the resource specificity is sufficient for a simple read tool, so it earns a 4 rather than 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 already cover read-only, idempotent, and non-destructive behavior. The description adds the meaningful OAuth scope requirement, which is not present in the annotations or schema. No contradiction with 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?

A single, front-loaded sentence conveys the essential purpose and a key prerequisite without any redundant words or repetition of schema details.

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 simple getter with an output schema and rich annotations, the description is sufficient. It does not discuss privacy_mode or response_format, but those are already documented in the schema, so the gap is acceptable.

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 already describes 3 of 4 parameters, so the baseline is 3. The description adds only a slight clarification that the id should be numeric, but does not explain response_format or privacy_mode, which are left to the schema.

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 action ('Get'), the resource ('one WHOOP cycle'), and the lookup method ('by numeric cycle id'), distinguishing it from sibling tools like whoop_list_cycles and whoop_get_cycle_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?

The description mentions the required OAuth scope ('read:cycles'), but does not explicitly state when to prefer this tool over alternatives or when not to use it. The singular 'one' implies single-resource retrieval, but no direct comparison to list or related getters is given.

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 destructiveHint: false, so the safety profile is covered. The description adds useful context by stating the required read:recovery scope and including a 'Not medical advice' disclaimer, which are not visible in the schema or 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 concise and front-loaded: one clear sentence stating the action and resource, followed by two essential short notes (scope requirement and disclaimer). No redundant or filler content is present.

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, the presence of an output schema, and strong annotations, the description is largely complete. It covers the core action, the required scope, and a caveat. It could be enhanced with an explicit alternative (e.g., use whoop_list_recoveries to list recoveries), but this is a minor gap for a single-resource getter.

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 covers 75% of parameters, and the description clarifies that the 'id' parameter is a WHOOP cycle id, which is not stated in the schema ('WHOOP resource id'). This adds meaningful semantic meaning. The other parameters (privacy_mode, response_format, explicit_user_intent) are already well described in the schema, so the baseline is appropriately elevated.

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 states a specific verb ('Get') and resource ('recovery associated with a WHOOP cycle'), clearly distinguishing it from sibling tools like whoop_list_recoveries (which lists recoveries) and whoop_get_cycle (which gets the cycle itself). This gives the agent a precise understanding of the tool's function.

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 when you have a WHOOP cycle id and need its associated recovery, and it notes the required read:recovery scope. However, it does not explicitly mention alternatives or when not to use this tool, leaving the distinction from whoop_list_recoveries and whoop_get_cycle implied rather than explicit.

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 destructiveHint false, providing safety context. The description adds the authorization requirement (requires read:sleep scope), which is useful. However, it does not disclose other behaviors such as defaults, limitations, or response handling beyond the schema.

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 extremely concise: three sentences, no redundancy, and front-loaded with the primary purpose. It includes only necessary notes on scope and a disclaimer, with every sentence earning 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 the tool's simplicity, the description is adequate but leaves gaps: it does not explain when to prefer this over sibling tools or mention any integration with related cycles. The output schema and annotations cover safety and return values, but usage context 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 coverage is 75% with meaningful descriptions for id, privacy_mode, and explicit_user_intent. The description adds no parameter-level information, but the schema already provides adequate semantics for most parameters. The response_format parameter lacks a schema description but is self-explanatory via its enum and default.

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 specific action: 'Get the sleep associated with a WHOOP cycle.' It identifies both the verb (get) and the resource (sleep associated with a cycle), distinguishing it from sibling tools like whoop_get_cycle or whoop_get_sleep by the explicit association with a cycle.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (if you have a WHOOP cycle and need its sleep, use this tool) but does not explicitly state when to use it versus alternatives like whoop_get_sleep or whoop_list_sleeps. It only adds a prerequisite (requires read:sleep scope) without exclusionary 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 cover read-only, idempotent, and non-destructive behavior. The description adds useful context about the required read:profile scope and the 'basic' nature of the profile. It does not disclose other behavioral details, but annotations reduce the burden.

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 is directly to the point with no filler. It front-loads the verb and resource and earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with annotations and an output schema, the description is adequate but has gaps. It does not mention the near-duplicate sibling whoop_profile_get or clarify what 'basic' excludes, leaving some ambiguity for tool selection.

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 67% (two of three parameters have descriptions), but the description itself adds no parameter meaning. It does not explain response_format or clarify privacy_mode behavior, leaving a gap that the description could have filled.

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 it gets the authenticated user's basic WHOOP profile with a specific verb and resource. However, it does not distinguish between this tool and the sibling whoop_profile_get, which appears to have a nearly identical 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 no guidance on when to use this tool versus alternatives. It mentions the required read:profile scope but does not explain contexts for choosing this over whoop_profile_update or other profile-related tools.

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 cover read-only, idempotent, and non-destructive behavior. The description adds the 'Requires read:sleep scope' authorization detail, which is a meaningful behavioral constraint beyond the structured annotations. The 'Not medical advice' disclaimer is additional context, though not strictly behavioral.

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 with front-loaded purpose, a scope requirement, and a disclaimer. Every word earns its place; no redundant content or 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 rich annotations, an output schema, and a well-described input schema, the description sufficiently orients the agent. It could mention privacy_mode behavior, but that is already handled by the schema. The core retrieval purpose and auth requirement are covered.

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 75%, with id and privacy_mode well-documented, and explicit_user_intent also described. The description itself adds no parameter-specific meaning, so the baseline of 3 applies because the schema carries the load.

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 'gets one WHOOP sleep activity by UUID', using a specific verb and resource with a unique identifier. This distinguishes it from sibling list tools (e.g., whoop_list_sleeps) and cycle-specific 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 UUID-based requirement implies you need a specific ID, and the mention of 'read:sleep scope' provides a prerequisite. It does not explicitly name alternatives or exclusions, but the context is clear: use this when you have a UUID and need a single sleep record.

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 destructiveHint=false, covering the safety profile. The description adds the authentication requirement ('Requires read:workout scope'), which is useful context beyond annotations. No contradictions found.

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 efficient sentence that front-loads the core purpose and includes the required scope. Every word earns its place; there is zero waste or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description is terse, the presence of a detailed input schema, output schema, and rich annotations fills in the gaps. It covers purpose and auth, and the schema explains privacy_mode, response_format, and explicit_user_intent. For a single-resource getter with good structured metadata, this is sufficiently complete, though a note about raw mode escalation could make it more robust.

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 75%, which is below the 80% threshold for a guaranteed baseline of 3. The description adds no parameter information itself, but the schema provides adequate descriptions for id, privacy_mode, and explicit_user_intent. The undocumented response_format is self-explanatory from its enum values (markdown/json), so the gap is minor.

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 'Get one WHOOP workout by UUID' – a specific verb, resource, and identifier. It distinguishes this tool from siblings like whoop_list_workouts (which lists) and other get_* tools for 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 implies usage when a single workout needs to be fetched by UUID, but it does not explicitly mention when to use this tool versus alternatives (e.g., 'use whoop_list_workouts to find UUIDs' or 'use whoop_get_sleep for sleep data'). No exclusions or alternative tools are referenced.

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 readOnlyHint, idempotentHint, and non-destructive behavior. The description adds a valuable behavioral detail beyond that: the required 'read:cycles' OAuth scope. It also mentions pagination support, giving the agent a sense of the tool's interaction pattern 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 three short sentences, front-loaded with the core action and resource. Every sentence adds useful information: what it lists, what filtering/pagination it supports, and the required scope. No filler or redundancy exists.

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 list tool with rich annotations, an output schema, and 89% schema description coverage, the description is mostly complete. It covers the resource, filtering, pagination, and auth. It could be slightly more complete by pointing to whoop_get_cycle for single-cycle lookups, but that gap is minor given the schema and annotations.

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 high (89%), and parameter descriptions already document date-time format, limit bounds, pagination, and privacy mode. The tool description only restates the start/end filters and pagination, adding little semantic value beyond what the schema provides.

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 ('List') and a clear resource ('WHOOP physiological cycles'), and adds useful scope details about start/end filters and pagination. It is clear and accurate, though it doesn't explicitly distinguish itself from sibling tools like whoop_list_recoveries or 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?

The description indicates what the tool supports ('start/end filters and WHOOP pagination'), so an agent can infer basic when-to-use context. However, it provides no explicit guidance about when to prefer this over sibling list/get tools, nor does it mention exclusions or 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 already cover read-only, idempotent, non-destructive behavior. The description adds context beyond that: sorted ordering, conditional availability of metrics ('when scored'), required OAuth scope, and a non-medical-advice disclaimer. No contradiction with 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?

Two sentences with no wasted words. The action and sorting behavior are front-loaded, and every clause adds value: returns fields, scope requirement, and disclaimer.

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 rich schema, output schema, and read-safe annotations, the description adequately covers purpose, ordering, returned metrics, scope, and conditional availability. It does not mention pagination or privacy-mode behavior, but those are documented in the parameter schema, so the remaining gap is minor.

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 high at 89%, so the schema already documents most parameters like start, end, limit, pagination, and privacy mode. The description adds sorting and return-value context but does not itself explain the parameter semantics, so the baseline of 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?

The description names the exact operation ('List WHOOP recoveries'), the sorting behavior (by related sleep start time descending), and the key returned metrics (recovery score, HRV, RHR, SpO2, skin temperature). This clearly distinguishes it from sibling list tools such as whoop_list_sleeps and whoop_list_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 states the required auth scope ('Requires read:recovery scope') and implies it is the endpoint for listing recovery records. However, it gives no explicit guidance on when to choose this over siblings like whoop_get_cycle_recovery or whoop_recovery_trend, and it does not mention exclusions or 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: 'Requires read:sleep scope', 'Supports start/end filters and WHOOP pagination', and the conditional 'when scored', which clarifies that some sleeps may lack scoring fields. No contradiction exists.

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 and front-loaded with the core action and resource. Every sentence earns its place: it covers what is returned, filtering/pagination behavior, required scope, and a necessary health-data disclaimer. There is no redundancy or 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?

Given the rich annotations, high schema coverage, and presence of an output schema, the description covers the essential operational context: the resource type, filters, pagination, scoring conditionality, and required scope. It is slightly incomplete in that it does not help the agent choose between this and sibling sleep-related tools, but the schema and output schema cover most invocation details.

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 89%, so the schema already carries most parameter semantics. The description adds general context like 'start/end filters' and 'WHOOP pagination', which maps to multiple parameters, but it does not meaningfully expand on parameter details beyond what the schema provides. 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?

The description clearly states the verb 'List' and the resource 'WHOOP sleep activities', and it adds meaningful detail about returned data (stages, performance, consistency, efficiency). It does not explicitly distinguish itself from sibling tools like whoop_get_sleep, whoop_list_cycles, or whoop_list_recoveries, so it falls short of a 5.

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 use for retrieving a paginated, filtered list of WHOOP sleep activities and mentions start/end filters and pagination. However, it does not explicitly state when to choose this over whoop_get_sleep or other sibling list tools, nor does it provide exclusions or alternative routing.

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 covered. The description adds useful behavioral context beyond the annotations: it supports start/end filters, uses WHOOP pagination, and requires read:workout authorization. There is no contradiction with 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 three short sentences with the core purpose first, followed by filtering/pagination behavior and the auth requirement. Every sentence earns its place, and there is no redundant restating of title or schema details.

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 an output schema present and 89% schema description coverage, the return format and parameter meanings are already well documented. The description supplies the remaining operational context: auth scope, filtering, and pagination behavior. Given the read-only annotations and absence of required parameters, this is a complete enough definition for reliable invocation.

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 89%, well above 80%, and every parameter already has a descriptive schema entry including defaults, ranges, formats, and enum meanings. The description's mention of 'start/end filters and WHOOP pagination' is a useful summary, but it adds no parameter meaning beyond what the schema already provides. 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?

Description begins with a specific verb 'List' and a clear resource, 'WHOOP workouts', and immediately adds the relevant batch behaviors (start/end filters, WHOOP pagination). This unambiguously distinguishes it from single-item tools like whoop_get_workout and from sibling list tools for other resources such as whoop_list_sleeps and whoop_list_cycles.

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 clearly communicates this is for listing workouts over a time range with pagination, which is a clear usage context. It does not explicitly name alternatives or exclusion conditions, but the resource-specific wording and sibling tool names make the appropriate use case easy to infer. It also provides a prerequisite, 'Requires read:workout scope,' which helps the agent decide if the call is currently possible.

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 idempotentHint=true. The description adds valuable context: the read-only nature is restated for emphasis, and it explains that the profile is shared across connectors. It also provides the follow-up action (call whoop_profile_update with explicit_user_intent=true), which is useful behavioral guidance. Nothing contradicts 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 front-loaded with the core purpose, and the first two sentences are concise. The third sentence is longer and packs multiple ideas (shared profile, connector alternatives), but remains readable and not bloated. Slight trimming could improve, but overall it is 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?

Without an output schema, the description adequately describes return content (flow, state, missing fields). It covers the shared profile context, read-only nature, and provides a clear next step. It is complete for a tool with two optional parameters and no output schema.

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 itself provides descriptive parameter semantics: locale explains defaults and language support, response_format explains default and options. However, the tool description adds no parameter information, and schema description coverage is only 50%, so the description does not contribute additional value beyond the schema.

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 the 11-question Delx wellness onboarding flow plus current shared profile state and missing critical fields. This specific verb-resource pairing distinguishes it from siblings like whoop_profile_get and whoop_quickstart.

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 provides explicit workflow guidance ('ask these questions one-by-one, then call whoop_profile_update...') and explicitly discusses alternatives: agents can call equivalent {connector}_onboarding tools or rely on this shared one. This gives clear when-to-use and covers 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 already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context: it returns 'local' posture and 'without revealing secret values,' which goes beyond annotations and informs the agent of safe, non-exposing 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?

The description is one concise sentence, front-loaded with the action and listing all covered aspects without redundancy. Every word adds 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 tool's moderate complexity (multiple audit aspects) and the presence of an output schema (which covers return structure), the description adequately enumerates all covered areas and the key guarantee about secret values. No significant gaps remain.

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 single parameter response_format is fully self-documented in the schema (enum of markdown/json with default markdown). Despite 0% schema description coverage, the schema itself provides complete semantics, so the description does not need to compensate. The default and enum are unambiguous.

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 ('Return') with a clear resource ('local privacy, cache, token-path, env-presence and redaction posture'). It clearly distinguishes this from sibling tools like whoop_cache_status or whoop_connection_status by combining multiple audit dimensions.

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 the tool is for auditing privacy posture without revealing secrets, providing clear context for when to use it. It does not explicitly exclude alternatives, but the scope is self-evident. Sibling differentiation is implicit via the specific audit focus.

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 destructiveHint false, and the description reinforces this with 'Read-only'. Beyond annotations, it adds the file path (~/.delx-wellness/profile.json) and details the returned fields, including 'missing critical fields', which provides useful behavioral context. No contradiction with 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 three sentences, starts with the action verb 'Read', and packs essential details without fluff. Every sentence contributes useful information, making it appropriately sized 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 simple read-only tool with one optional parameter and no output schema, the description provides a solid overview: what it reads, where it reads from, what it returns, and its non-mutating nature. It lacks explicit error handling or comparison to sibling whoop_get_profile, but these are minor gaps for such a straightforward 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?

The only parameter, response_format, is defined by an enum with markdown/json and a default value, making its semantics clear from the schema. However, the description does not mention the parameter at all, and schema description coverage is 0%, so the description fails to compensate for the absence of a textual explanation. Since the parameter is optional and self-explanatory, the omission is minor but still present.

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 reads the shared Delx wellness profile and enumerates the contained fields, making the purpose specific. However, it does not explicitly distinguish itself from the sibling tool whoop_get_profile, which likely has a similar purpose, so it loses a point for not differentiating.

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 notes the profile is cross-connector and available from other MCPs, implying this is one way to access the same data. It does not explicitly say when to prefer this tool over alternatives such as whoop_get_profile, nor does it mention criteria for choosing between connectors. The guidance is implicit, not explicit.

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 indicate a non-read-only, non-idempotent, non-destructive mutation. The description adds valuable context beyond these flags: it persists to a specific file path, rejects all secret-shaped fields at validation, and is cross-connector (read by other MCPs). It does not describe return value or error behavior beyond secret rejection, 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?

The description is well-structured: purpose first, then the required flag, field list, secret exclusion, and cross-connector context. Each sentence adds distinct value, and it is not overly verbose for the amount of critical information it conveys.

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 nested objects, 3 parameters, and no output schema, the description covers the essential behavioral and operational context: what it does, where it writes, required intent, supported fields, and security constraints. The only notable gap is not explaining the response format, but the response_format parameter hints at it.

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 input schema already documents patch's allowed keys and explicit_user_intent's requirement. The description adds meaning by restating the exact top-level field enumeration and emphasizing that partial patches are allowed. It also adds the critical rejection rule for secrets, which is not in the schema.

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 opens with a specific verb and resource: 'Persist a partial patch to the shared Delx wellness profile' with the file path. It clearly distinguishes from sibling read tools like whoop_profile_get by emphasizing it writes to a cross-connector profile shared by other MCPs.

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 strong usage guidance: it mandates explicit_user_intent=true and instructs when to set it ('AFTER the user has explicitly confirmed'). It also warns against secret-shaped fields. It does not explicitly name alternative tools, but the write/read distinction from siblings is clear from the resource path and cross-connector note.

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 destructiveHint, so safety is covered. The description adds valuable behavioral context by stating that the tool 'adapts to current state (env vars set? token present? what's next?)' and is a 3-step walkthrough, which goes beyond the annotation hints.

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 long, with no redundant phrases. The first sentence defines the tool's core behavior, and the second provides the exact user query that should trigger it. Every word 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?

For a simple tool with one optional parameter and no output schema, the description covers its purpose and usage trigger well. However, it does not explain what the tool returns or the meaning of the response_format parameter, which could leave an agent uncertain about expected output. The adaptive nature is hinted but not detailed enough for full 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 schema has one parameter, response_format, with no description in the schema (0% coverage). The tool description does not mention this parameter at all, failing to compensate for the lack of schema descriptions. Although the enum is self-explanatory, the description contributes zero semantic value.

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 as a 'Personalized 3-step setup walkthrough for the human user' and provides a concrete trigger phrase ('how do I connect WHOOP?'). This distinguishes it from generic onboarding tools, though it doesn't explicitly differentiate from sibling tools like whoop_onboarding.

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 guidance on when to call the tool: 'Call this first when the user asks "how do I connect WHOOP?"' This is a clear context signal. However, it does not mention when not to use this tool or suggest alternatives, 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 already convey readOnly, non-destructive, and idempotent behavior. The description goes further by stating it 'fetches recent WHOOP v2 records, computes statistics, stores nothing,' and it explains the slope calculation and direction value semantics, providing concrete computational behavior beyond the annotation hints.

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 purpose is front-loaded, and each of the four sentences adds meaningful detail about output fields, use case, or safety. The 'Not medical advice' clause is slightly extraneous but does not significantly hamper clarity.

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 statistical aggregation tool, the description defines every returned field (avg, min, max, slope, direction, n_valid) and explains direction values. It does not explain how response_format changes the returned structure, but the presence of an output schema likely covers that; the overall description is nearly complete for tool selection and invocation.

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 already describes days and timezone, and the description only repeats the default of 30 for days. The response_format parameter lacks any description in both the schema and the tool description, leaving the agent uninformed about when to choose 'markdown' vs 'json.' With 67% schema coverage, the description does not compensate for this 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 opens with 'Aggregate WHOOP recovery over the last N days into a per-metric trend for recovery score, HRV and resting heart rate,' specifying a clear verb, resource, and scope. It also distinguishes itself from raw-list siblings by saying 'without paging the raw collection yourself,' making its role explicit.

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 provides an explicit use case: 'Use this to answer "is my recovery trending up or down?"' and contrasts with paging raw collection, thereby implying an alternative. However, it does not name a specific sibling tool, so the differentiation is slightly less direct than it could be.

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 critical behavioral context beyond annotations: it details what is destroyed (local token file) and the gating mechanism (explicit user intent required, no autonomous calls). This complements the destructiveHint annotation without contradiction.

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 the verb and resource, then adds usage and gating. Every sentence contributes meaning without unnecessary detail.

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 simple revocation tool with an output schema, the description covers purpose, usage, gating, and destructive effect. It is sufficiently complete for an agent to decide when and 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?

The description reinforces the purpose of the explicit_user_intent parameter (gating), aligning with its schema description. However, the response_format parameter is not addressed, and with 50% schema coverage, the description only partially compensates for the undocumented 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's function: 'Revoke the current WHOOP OAuth access grant and delete the local token file.' This uses a specific verb+resource and is distinct from all sibling tools, none of which handle revocation.

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?

Explicit usage guidance is provided: 'Use only when the user explicitly wants to disconnect WHOOP' and 'agents must not call this autonomously.' This clearly delineates when to use the tool and when not to, satisfying the 'when/when-not' criterion even without naming an alternative.

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 description's added 'Read-only; fetches recent WHOOP v2 records, computes statistics, stores nothing' reinforces and expands on the safe, non-mutating nature. It also discloses the least-squares slope computation and the direction values, adding context beyond 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 two short paragraphs. The first states the aggregation scope and metrics; the second explains the output structure and a concrete use case. Every sentence contributes meaningful information without redundant or promotional language.

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?

An output schema is present, so the description does not need to detail return fields beyond the summary it gives. It covers what the tool does, how it computes results, when to use it, safety characteristics, and even a disclaimer ('Not medical advice'). This is complete for a read-only aggregation 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 descriptions cover 67% of parameters (days and timezone), and the response_format enum is self-explanatory. The description mentions the default of 30 days, which repeats the schema default. It does not add new explanatory value beyond what the schema already provides for parameters, so a baseline score of 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?

The description uses a specific verb ('Aggregate') and clearly identifies the resource ('WHOOP sleep') and scope ('over the last N days'). It lists the specific metrics computed (sleep performance percentage, duration, efficiency) and explicitly differentiates from raw sleep listing by stating it computes trends to answer 'is my sleep improving or degrading?' without paging the raw collection.

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 a clear use case: 'Use this to answer "is my sleep improving or degrading?"' It also implies an alternative (raw collection paging) with the phrase 'without paging the raw collection yourself.' However, it does not explicitly name sibling tools like whoop_list_sleeps or whoop_recovery_trend, nor does it state when not to use 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context beyond these: it is a workflow tool that compares windows, mentions 'when available' for prior data, and describes output scope ('action candidates', 'next-week success metrics'). No contradiction with 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?

Two sentences, front-loaded with the key purpose. The first sentence is packed with specifics (recovery, sleep, strain, etc.), and the second adds context about comparison and intended use. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists and parameter descriptions are present, the description covers the essential context: what the review includes, the window comparison, intended use, and non-medical scope. A minor gap is the lack of detail on edge cases (e.g., missing prior data), but overall it is sufficiently complete for a moderately complex workflow 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 75% with all four parameters having descriptions. The description's mention of 'compares a recent window against a prior window' loosely aligns with days/compare_days, but it does not add technical detail beyond the schema. Baseline 3 is appropriate because the schema carries the parameter semantics.

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 a specific action ('Build a weekly WHOOP operating review') and enumerates the included components (recovery, sleep, strain, workouts, bottlenecks, action candidates, success metrics). This distinguishes it from raw data retrieval siblings like whoop_list_sleeps or whoop_list_workouts, and the 'weekly' aspect differentiates it from daily_summary.

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 explicitly indicates intended use for 'coaching and agent workflows' and excludes 'medical diagnosis', providing clear context. It also notes the tool compares a recent window against a prior window, implying when it is appropriate. However, it does not name alternatives or specify when to prefer a simpler tool, so it stops short of full distinction.

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 the tool as read-only, idempotent, and non-destructive. The description adds that the tool normalizes data into a shared shape, but does not elaborate on the shape or any behavioral nuances. It does not contradict annotations, but adds minimal value beyond what 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 a single sentence that concisely conveys the core purpose. Every word contributes meaning, with no redundancy or 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?

The tool has an output schema, so the return format is presumably covered. However, the description omits prerequisites (e.g., need for prior authentication or data fetching) and does not guide the agent on when to invoke this tool versus siblings. Given the complexity of 6 parameters, more contextual guidance would be beneficial.

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 only 33% (days and timezone have descriptions). The tool description does not mention any parameters or their purposes, leaving the agent to infer meaning from parameter names alone. Since coverage is low, the description should compensate but does not, resulting in a below-adequate 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 uses a specific verb 'normalize' and clearly states the resource (WHOOP data into shared wellness_context shape). It differentiates from siblings by mentioning the target use case (exercise recommendation engines and Telegram agents), making the tool's purpose distinct among many WHOOP 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 usage for creating a unified wellness context but does not explicitly state when to use this tool versus alternatives like whoop_daily_summary or whoop_recovery_trend. No exclusions or prerequisites are provided, leaving the agent with only implicit context.

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