WHOOP MCP

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description still adds two genuine behavioral claims beyond them: it does not read WHOOP data and does not expose secrets, which is meaningful safety context for an agent deciding whether to call it.

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 short sentences with zero filler; the primary purpose is front-loaded and the exclusion clause follows immediately. Nothing could be removed without losing 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?

An output schema exists so return values need no explanation, annotations cover the safety profile, and the parameters are simple enums. Combined with low tool complexity, the description is largely sufficient, missing only explicit invocation guidance.

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 bears the burden. It hints at the client parameter via 'client guidance' and at output format via 'machine-readable', but never explains what the client enum values change or what markdown vs json response_format does. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific output (machine-readable install, runtime and client guidance) and even clarifies scope with 'Does not read WHOOP or expose secrets.' This clearly separates it from the data-reading siblings, though it never names a specific sibling alternative like whoop_capabilities or 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?

Usage is only implied: an agent needing install/runtime guidance would infer this tool, and 'Does not read WHOOP' excludes the data-reading siblings. There is no explicit 'use this when...' or pointer to an alternative like whoop_capabilities for capability discovery.

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 this is a safe, idempotent, non-destructive read. The description adds real context the annotations do not carry: that the cache is opt-in and gated behind an environment variable, which explains a disabled/empty result. It still says nothing about what the status output contains, but with annotations covering the safety profile that is acceptable at this level.

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 short sentences, no filler, and the core purpose is front-loaded ahead of the configuration detail. Every sentence earns its place.

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

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

An output schema exists, so return values need not be described, and the low-complexity read tool is largely covered by the purpose plus enable instructions. The gap is the unaddressed response_format parameter, but overall the agent has enough to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter, response_format, with 0% schema description coverage and a default. The description never mentions output format, so it neither explains the enum values nor compensates for the coverage gap. Since there is a parameter (not zero), the zero-parameter baseline of 4 does not apply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Show ... local SQLite cache status'. An agent can immediately tell this reports cache state rather than auth or data state. It does not explicitly distinguish itself from the similarly-named whoop_connection_status sibling, 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 word 'optional' and the enable instructions ('Enable with WHOOP_CACHE=sqlite or WHOOP_CACHE=true') imply the feature may be off and hint at when this tool is relevant. However, there is no explicit when-to-use, when-not-to-use, or alternative-tool routing versus whoop_connection_status or whoop_data_inventory.

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, and the description usefully adds 'Does not read WHOOP or expose secrets,' which distinguishes it from the data-reading siblings. It doesn't describe the structure of the explanation (deferrable to the existing output schema), so it lands just short of top marks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly written sentences, front-loaded with the topics covered and followed by the key non-behavioral clarification. No wasted words, though the topic list is slightly dense.

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

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

For a zero-required-param informational tool with an output schema already describing returns, the description covers what is needed. The missing piece is disambiguation from the other informational siblings, which keeps it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

One optional parameter (response_format) with 0% schema description coverage. The enum values are self-explanatory (markdown/json), but the description never mentions the parameter, so it adds no meaning beyond the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Explain') and resource (WHOOP capabilities), and enumerates the topics covered. It clearly is not a data-fetching tool, but it doesn't distinguish itself from other informational siblings like whoop_agent_manifest, whoop_quickstart, or whoop_data_inventory.

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

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

There is no 'use this when' guidance or comparison to the several other meta/informational tools in the sibling list. An agent seeing whoop_capabilities, whoop_quickstart, whoop_agent_manifest, and whoop_data_inventory side by side gets no routing signal.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: it performs no WHOOP network call and never exposes secrets, which is meaningful for a credentials-adjacent diagnostic. It stops short of describing output detail, but that is partly covered by the output 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?

Two tightly written sentences with the readiness scope front-loaded and the safety caveat second. Every clause earns its place; nothing is redundant or padded.

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 exists, so return structure need not be described. The description covers what is checked and the key behavioral boundaries (no network, no secret exposure). The one gap is the undocumented client/response_format parameters, which the description never touches.

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% for two optional parameters, and the description mentions neither 'client' nor 'response_format'. Both are enums with defaults, so they are somewhat self-describing, but the description does not compensate for the coverage gap the way a low-coverage tool should.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Check') and enumerates the exact resources being verified: env vars, token file, Node version, privacy mode and cache readiness. An agent can tell this is a local readiness/diagnostic probe rather than a data fetch. It does not explicitly name the overlapping sibling whoop_cache_status, 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?

Usage is implied by the content ('ready' readiness check), and the exclusion 'Does not call WHOOP' signals when this is appropriate versus data tools. But there is no explicit when-to-use, no stated prerequisites, and no routing against whoop_cache_status, which overlaps on the cache check.

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 read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds genuinely useful context beyond them: it is 'privacy-conscious,' 'does not provide medical advice,' 'does not store data locally,' and 'computes a defensive baseline' — real behavioral traits not derivable from the structured fields. It stops short of disclosing auth needs or rate limits.

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 core purpose, followed by operational and disclaimer context. No filler or repetition; every clause carries information, though the second sentence is slightly dense.

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

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

With an output schema present, the description needn't detail return values, yet it still names the payload categories (readiness, sleep, load, diagnostics, action candidates). Combined with the data sources and privacy/data-handling notes, an agent has enough to invoke it correctly; the only gap is explicit sibling routing.

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%, so the schema documents two of three parameters (days, timezone) with detail; the description adds no per-parameter syntax or format guidance and only loosely hints at a lookback window via 'recent' and 'baseline.' Baseline 3 is appropriate when the schema carries most of the parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Build a ... daily performance summary from WHOOP recovery, sleep, cycle and workout data') and enumerates the source domains it aggregates. The word 'daily' implicitly separates it from the sibling whoop_weekly_summary, but no other alternatives are named explicitly.

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

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

The description says it is a 'workflow tool' that 'returns readiness, sleep, load, diagnostic signals and concrete action candidates,' which implies the usage context (a consolidated daily snapshot rather than raw lists). However, it never states when to prefer this over whoop_weekly_summary, whoop_recovery_trend, or the individual list tools, leaving the routing to inference.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds a meaningful clarification: no WHOOP API calls and no user data exposure, confirming the tool is static metadata. This reinforces rather than repeats the annotations, though it omits how large or fresh the inventory is.

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 sentence fragments, front-loaded with the resource being inventoried followed by the scope/limitation clause. No filler, though the second clause reads as a fragment rather than a complete statement.

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 exists, so return shape need not be described. The description covers purpose, scope, and non-side-effects, which is sufficient for a zero-required-parameter read tool; only the response_format parameter is left undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single optional parameter (response_format, enum markdown/json, default markdown) with 0% schema description coverage, and the description never mentions output formatting. The parameter is self-explanatory by name and enum, so impact is limited, but the description does not compensate for the schema 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?

States a specific verb (inventory) and enumerates the resources it covers: data domains, auth scope requirements, privacy boundary, and recommended first calls. It is clearly distinguishable from data-fetching siblings, though it does not explicitly differentiate itself from adjacent meta-tools like whoop_capabilities or 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?

The negation 'Does not call WHOOP APIs or expose user data' implies this is a safe orientation/introspection call, which hints at when to use it. However, it never states when to prefer it over whoop_capabilities, whoop_quickstart, or whoop_agent_manifest, so the agent must infer the 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 readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds genuinely new context: the payload shapes are 'verified against the real tools by a build gate,' which tells the agent the demo output is a reliable parser target. It does not say whether the demo requires auth or is fully static, which is the remaining gap.

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 filler: the first states what is returned and why, the second supplies the trust guarantee. Front-loaded with the payload contract, which is the thing an agent needs first.

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

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

With no output schema, the description carries the burden of explaining returns, and it does name the three payload types the caller will receive. The only real omission is the response_format parameter, which leaves a small hole for a tool an agent may call to shape its own parser.

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 there is one parameter (response_format, enum markdown|json) that the description never mentions. With low coverage the description is expected to compensate, and it does not explain what response_format does or which value to pick.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb and resource: 'Returns realistic example payloads' of three named tools. It explicitly differentiates itself from the real siblings (whoop_daily_summary, whoop_wellness_context, whoop_list_recoveries) by positioning itself as the pre-flight preview rather than the live call, so an agent can tell it apart without opening any schema.

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

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

'before calling real WHOOP APIs' gives a clear trigger condition for using this tool instead of the live ones. It stops short of an explicit when-not or a statement of cost/latency tradeoffs, but the routing intent is unambiguous.

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

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

Annotations already cover readOnly/idempotent/openWorld, and the description adds genuinely new behavioral context: tokens are stored locally with 0600 permissions and are never returned by this tool, plus the autonomous-call prohibition. No contradiction with the annotations (readOnlyHint=false matches an exchange/write operation).

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, both earning their place, with the security/gating constraint front-loaded alongside the purpose. No filler.

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

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

An output schema exists, so return values need not be described, and the description usefully clarifies that tokens are not part of the response. The safety-relevant facts an agent needs before invoking are all present.

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 67%; the code and state parameters have their own schema descriptions. The description adds no meaning for code/state/response_format, so it neither compensates for the gap nor introduces confusion. 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?

Names a specific verb (exchange) and resource (WHOOP OAuth authorization code) and states the outcome (local tokens). It is clearly distinct from the sibling whoop_get_auth_url, which obtains the code rather than redeeming it.

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?

Explicitly states when NOT to call it: 'Gated: requires explicit user intent — agents must not call this autonomously.' That is a strong conditional guardrail, though it does not name an alternative tool or the precondition flow (get_auth_url first).

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/destructiveHint=false, so safety is covered. The description adds context the annotations cannot: that the call has no data side effects and that its trigger condition is the absence of a local token. It doesn't mention whether scopes changes affect downstream grants, but the added behavioral signal is real.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, each carrying distinct information (what it does, what it doesn't do, when to call it). No filler.

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

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

With an output schema present, return values need no explanation, and the description covers purpose, side-effect profile, and sequencing for a zero-required-param tool. The one gap is the missing pointer to the exchange step that consumes this URL.

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 67% with state and scopes well documented (scopes even explains the default). The description contributes nothing about parameters, so it neither compensates for the undocumented response_format nor adds syntax beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Generate a WHOOP OAuth authorization URL') and immediately scopes it negatively ('does not read or modify WHOOP data'), which separates it from the data-fetching siblings. An agent can tell this is a URL builder, not a data tool, without opening the schema.

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

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

'Use this first when no local token exists' gives an explicit precondition for choosing this tool over the auth-adjacent siblings. It stops short of naming whoop_exchange_code as the follow-on step, so the agent must infer the pairing rather than being routed to 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, open-world, and non-destructive, so safety is covered; the description adds real value by naming the required OAuth scope and flagging the output is not medical advice. It does not, however, surface the privacy_mode=raw escalation contract that lives only in 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?

Three short, front-loaded sentences that each carry weight: purpose and returned fields first, then the scope prerequisite, then the disclaimer. No redundant or filler text.

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, return values need no explanation, and the description covers purpose, auth scope, and the medical disclaimer. A brief note on privacy_mode/raw behavior or the response_format default would make it fully self-sufficient, but nothing essential is missing for a simple read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67% and the description contributes no parameter detail, so it neither duplicates nor compensates. privacy_mode and explicit_user_intent are well described in the schema, but response_format has no description and the tool text offers nothing to fill that 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?

States a specific verb ('Get') and resource ('body measurements') and enumerates exactly what is returned (height, weight, max heart rate), which cleanly separates it from the other whoop_get_* tools. An agent can identify the tool's output without opening the schema.

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

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

Usage is implied by the resource name, and the required scope (read:body_measurement) hints at when it is callable, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative for related data (e.g., get_profile). Adequate but with clear gaps.

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 safety is covered structurally. The description adds the read:cycles scope requirement, which is genuine behavioral context, but says nothing about the privacy_mode escalation path or what happens when the id is missing.

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 short, front-loaded sentences: purpose first, prerequisite second. No filler, no redundancy with the title or schema.

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

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

An output schema exists, so return values need not be described, and the auth scope is disclosed. Complete enough to call correctly, with only the single-vs-list routing and privacy escalation left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75% with the privacy_mode and explicit_user_intent parameters already well documented in-schema. The description adds 'numeric cycle id', but that slightly conflicts with the schema, which accepts a string or integer, so the added detail is not fully accurate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Get) and resource (WHOOP cycle) scoped to a single record ('one ... by numeric cycle id'), which implicitly distinguishes it from the sibling whoop_list_cycles. However, it never names the sibling or explains the single-vs-list distinction explicitly.

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

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

The description gives one prerequisite ('Requires read:cycles scope') but offers no guidance on when to use this single-fetch tool versus whoop_list_cycles or the related whoop_get_cycle_sleep / whoop_get_cycle_recovery siblings. Usage is implied by the resource name rather than stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely new operational context: the required OAuth scope and a 'Not medical advice' disclaimer. It stops short of describing payload behavior tied to privacy_mode.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler, with the core purpose front-loaded before scope and disclaimer. Every clause earns its place.

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

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

An output schema exists and annotations cover the safety profile, so return values and mutability need no explanation. Purpose, auth scope, and disclaimer are present; only sibling routing and the privacy_mode/escalation interplay are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is a high 75%, so the schema does most of the work, but the description mentions no parameters at all. It does not flag the privacy_mode=raw gating relationship with explicit_user_intent, which is the one nuance an agent would benefit from.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Get the recovery associated with a WHOOP cycle.' An agent can distinguish it from whoop_get_cycle and whoop_get_cycle_sleep by the 'recovery' resource, but the description never names those siblings or whoop_list_recoveries explicitly.

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

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

Provides the prerequisite 'Requires read:recovery scope', which is a useful gate, but gives no when-to-use guidance versus siblings like whoop_list_recoveries or whoop_recovery_trend. Usage is only implied by the resource name.

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 still adds the auth requirement (read:sleep scope) and a medical disclaimer, which is exactly the kind of context beyond annotations that earns credit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, scope and disclaimer front-loaded after the core purpose, with no filler or repetition of structured fields.

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

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

An output schema exists so return values need no explanation, and annotations carry the safety profile. The remaining gap is sibling disambiguation against whoop_get_sleep, which matters given how many near-identical sleep/cycle readers exist.

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%, just under the high-coverage baseline, and the description adds nothing about any of the four parameters. Notably, the privacy_mode/raw escalation flow (explicit_user_intent) is left entirely 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?

States a specific verb and resource ('Get the sleep associated with a WHOOP cycle'), which is more precise than a bare 'get sleep'. It does not, however, distinguish itself from the sibling whoop_get_sleep or explain what 'associated with a cycle' buys the agent over that tool.

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 one real prerequisite ('Requires read:sleep scope'), which is actionable context. But there is no when-to-use guidance relative to whoop_get_sleep, whoop_get_cycle, or whoop_get_cycle_recovery, so tool selection is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered by structured data. The description adds genuine context by disclosing the required read:profile scope, but says nothing about the privacy_mode/raw escalation path or rate limits.

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 tight sentences with the core purpose and prerequisite front-loaded and no filler. It is appropriately sized, though the brevity is also the source of its gaps rather than a sign of surgical precision.

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 exists, so return values need not be explained, and annotations cover the behavioral profile. What remains missing is any disambiguation from the duplicate-looking sibling whoop_profile_get and any hint about the privacy override parameters — gaps an agent must resolve by inspecting other tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67%, below the 80% threshold where the schema alone would justify a baseline 3. The description contributes zero parameter information, and response_format is undocumented in both the schema and description, while the privacy_mode=raw / explicit_user_intent=true coupling is left entirely 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?

States a specific verb and resource ('Get the authenticated user's basic WHOOP profile'), which is clear on its own. However, it makes no attempt to distinguish itself from the near-identical sibling whoop_profile_get, leaving the agent unable to tell which of the two to call.

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 names a required scope ('read:profile'), but a scope prerequisite is not usage guidance. There is no statement of when to use this tool versus whoop_profile_get, whoop_profile_update, or whoop_data_inventory, all of which overlap in the profile domain.

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 full safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds the required read:sleep scope and a 'not medical advice' caveat, which is useful auth/domain context, but says nothing about payload size or how privacy_mode affects what is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with the purpose front-loaded, followed by the prerequisite and the caveat. No filler; every clause earns its place.

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

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

With annotations covering safety and an output schema covering return structure, the description supplies purpose, scope prerequisite, and a disclaimer, which is nearly enough for a read tool. It is only missing explicit guidance on choosing among the sleep-related siblings.

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%, so the schema carries most param documentation (privacy_mode, explicit_user_intent are already described). The description only alludes to the id param ('by UUID') and adds no detail on privacy_mode=raw escalation or response_format; baseline 3 for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Get) and resource (one WHOOP sleep activity by UUID), and the singular framing distinguishes it from the sibling whoop_list_sleeps and the related whoop_get_cycle_sleep. An agent can tell what it returns without opening the schema.

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

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

The 'one ... by UUID' framing implicitly signals single-item retrieval versus the list_sleeps sibling, and the scope requirement is a prerequisite. However, it never explicitly says when to choose this over whoop_list_sleeps or the cycle-based sleep variants, so the agent must infer.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful read:workout scope requirement. It does not mention that privacy_mode=raw demands explicit_user_intent=true, which is a notable behavioral gate, so the additional context is limited.

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 short sentences, purpose first, prerequisite second. Zero filler and fully front-loaded.

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 exists, so return-value explanation is unnecessary, and the annotations cover the safety profile. Purpose and scope are both present. The main gap is not surfacing the raw-mode escalation requirement or the privacy_mode override in the description, but the schema handles those.

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% (response_format lacks a description; privacy_mode and explicit_user_intent are well documented). The description only says 'by UUID,' adding nothing beyond the schema's 'WHOOP resource id.' and arguably narrowing the schema's anyOf string|integer id to a UUID. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+scope: 'Get one WHOOP workout by UUID.' The singular 'one ... by UUID' implicitly distinguishes it from whoop_list_workouts in the sibling set, though it never names that alternative. Clear enough that an agent knows exactly what it retrieves.

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?

'Requires read:workout scope' provides a genuine prerequisite. However, there is no explicit when-to-use guidance and no routing against the obvious sibling whoop_list_workouts or the aggregated whoop_daily_summary. Usage is implied by the resource name rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond that: the required 'read:cycles' scope, plus that pagination is supported. It omits any note on the privacy_mode/explicit_user_intent escalation mechanics, which is the remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler, with the core action front-loaded and the prerequisite scope stated last. Nothing is redundant.

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

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

An output schema exists, so return values need not be described, and the schema covers the nine parameters thoroughly. The description adequately frames a read-only paginated list tool, though it could note the multi-page (all_pages/next_token) interaction pattern more explicitly.

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 parameters are already well documented in the schema (ISO 8601 formats, max 25 page size, max_pages). The description only restates start/end filtering and pagination, adding no syntax or semantics beyond the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List WHOOP physiological cycles'), which cleanly separates it from the singular sibling whoop_get_cycle. It does not explicitly name any sibling or scope boundary, so it stops short of full differentiation.

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?

Mentions supported filters (start/end) and pagination, implying when it is useful, and names the required auth scope. However it gives no when-to-use-vs-alternative guidance, e.g. when to prefer whoop_daily_summary or whoop_get_cycle over listing.

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 a safe read-only, idempotent, non-destructive operation, so the bar is lower. The description adds useful behavior beyond that: descending sort by related sleep start time and the specific fields returned (score, HRV, RHR, SpO2, skin temperature) only 'when scored', which flags nullable output. It omits pagination behavior despite dedicated page parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, all front-loaded: ordering first, then returned data, then access requirement and disclaimer. Every clause carries information and there is no filler.

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

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

An output schema and rich annotations already cover return shape and safety, so the description need not explain them. It correctly covers ordering, field availability, and the scope requirement; only pagination semantics across all_pages/max_pages/next_token are left entirely to 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?

Schema description coverage is 89%, so the schema already documents the date range, limit, pagination and privacy parameters thoroughly. The description adds no parameter-level meaning (e.g. how start/end bound recoveries, or the interaction of all_pages with next_token), so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (list WHOOP recoveries) with the sort order and the fields returned, so it is immediately distinguishable from the singular whoop_get_cycle_recovery. It stops short of naming the trend sibling or explicitly contrasting with it, so it is clear but not fully sibling-differentiated.

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 prerequisite scope ('Requires read:recovery scope'), which is real context, but gives no guidance on when to prefer this list over whoop_get_cycle_recovery, whoop_recovery_trend, or whoop_daily_summary. Usage is implied rather than explained.

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 read-only, idempotent, non-destructive, open-world profile, so the safety baseline is covered. The description adds valuable context beyond that: the read:sleep scope requirement, the fact that stages/performance/efficiency are only present 'when scored', and a medical disclaimer. It does not discuss pagination limits or data freshness, keeping it just short of 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?

Four short sentences with the purpose front-loaded followed by return content, filtering support and prerequisites. Every sentence carries distinct information and there is no filler, making it very efficiently 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?

An output schema exists, so return values need not be detailed, and the description still summarizes the payload shape. For a 9-parameter list tool it covers purpose, scope requirement and disclaimers, though it omits guidance relative to sibling retrieval tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 89%, so the schema already documents the date filters, pagination token, limit, privacy_mode and response_format. The description only gestures at 'start/end filters and WHOOP pagination', adding no syntax or format detail beyond what the schema provides, which matches the baseline 3 for high-coverage schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('WHOOP sleep activities'), which implicitly separates it from the singular whoop_get_sleep. However, it never explicitly names or contrasts itself with the closely related siblings whoop_get_sleep or whoop_sleep_trend, so differentiation is left to inference.

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

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

There is no guidance on when to use this list tool versus whoop_get_sleep (single record) or whoop_sleep_trend (aggregated trend), both present as siblings. 'Supports start/end filters' hints at bulk retrieval but does not state the conditions that select this tool over the alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuine context beyond that: the required read:workout scope and that WHOOP-style pagination applies, which the agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loading the core action before the filter, pagination, and auth notes. No filler or repetition.

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 exists, so return values needn't be explained, and the scope plus pagination behavior are disclosed. For a 9-parameter read tool this is nearly complete, though it omits any note on default page size or ordering that might help interpretation.

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 documents nearly every parameter (limit bounds, next_token, privacy_mode, etc.). The description only restates start/end filters and pagination and adds no syntax or format detail beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List WHOOP workouts') that an agent can clearly act on. It's distinguishable from the singular whoop_get_workout sibling by the 'List' verb, but the description never names that alternative, so it stops short of the 5-level explicit differentiation.

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?

Mentions supported filters (start/end) and pagination, implying this is the collection-retrieval tool, but gives no explicit when-to-use versus whoop_get_workout or other listing siblings, and no exclusions or prerequisites beyond the scope 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, so the repeated 'Read-only' adds little. But the description adds genuinely non-structured behavior: the profile is shared across all Delx connectors, and it prescribes the next step (a separate update call with a specific flag). No note on freshness or failure modes, so not 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?

Front-loads the core action and payload, then the workflow, then cross-connector context. Well-structured, though the final connector digression is somewhat long for its 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?

With no output schema, the description adequately describes what is returned (questions, profile state, missing fields). Combined with the explicit follow-up workflow and sharing semantics, an agent has everything needed to invoke and sequence this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%; locale has its own enum description, while response_format is undocumented in both schema and description. The description's 'English or pt-BR' merely restates the locale enum. Baseline 3 is appropriate since the schema carries most of the weight.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Return) and resource (the 11-question Delx wellness onboarding flow) plus the supplementary payload (shared profile state, missing critical fields). It clearly distinguishes itself from siblings like whoop_profile_get and whoop_profile_update by naming them explicitly.

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

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

Gives an explicit workflow: ask questions one-by-one, then call whoop_profile_update with explicit_user_intent=true to save. It also names the {connector}_onboarding alternatives and explains when relying on this one instead is acceptable.

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, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds genuinely new context: it discloses that secret values are redacted and that env-presence is reported without exposing values, which is the key behavioral promise of an audit tool.

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 with no filler; every clause maps to a distinct facet of the audit. The enumerated noun list is dense but 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?

An output schema exists, so return structure need not be described, and with one optional parameter the description is close to sufficient. The only gap is the unexplained response_format switch, which is minor for a read-only audit tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description never mentions response_format, its markdown/json enum, or the markdown default. The parameter is optional and self-explanatory from the enum, but the description contributes nothing beyond the schema here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Return') and enumerates the resource being audited: local privacy, cache, token-path, env-presence and redaction posture. It is distinguishable from siblings like whoop_cache_status or whoop_data_inventory, though it does not explicitly name which sibling it replaces.

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

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

No when-to-use guidance, prerequisites, or alternatives are given. An agent must infer from the name and content list that this is a diagnostic/inspection call, and cannot tell from the description whether it supersedes whoop_cache_status or whoop_connection_status.

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 readOnly/idempotent/non-destructive, and the description adds real context beyond them: the concrete file path, the read-only nature, the cross-connector sharing, and the fact that missing critical fields are surfaced. It doesn't discuss failure modes (e.g. profile not yet created), but the safety profile is fully covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loaded with the verb and file path, then the return contents, then the cross-connector scope. No filler; the field enumeration earns its length because there is no output schema.

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

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

With no output schema, the description carries the return-value burden and does so by listing the profile sections returned. The only gap is the unaddressed response_format parameter and how it changes the output shape.

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% for the single response_format parameter, and the description never mentions it, so nothing compensates for the gap. The enum (markdown/json) is largely self-explanatory, which keeps this above a 1, but the description adds no 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?

States a specific verb and resource ('Read the shared Delx wellness profile') and enumerates the returned fields, so an agent knows exactly what it gets. The cross-connector note distinguishes it from a connector-specific profile read, though it does not explicitly separate it from the near-named sibling whoop_get_profile.

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

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

Usage is only implied: it reads the shared profile file, and the cross-connector sentence hints the same data is reachable from other MCPs. There is no explicit when-to-use or when-not-to-use guidance, and the confusable sibling whoop_get_profile is never addressed.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), and the description adds real context beyond them: merge/patch semantics ('partial patch'), the exact storage location, a guarantee that secret-shaped fields are rejected at validation time, and that the state is shared across other Delx Wellness MCPs. It does not say what happens to nested keys omitted from the patch or what the call returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the action and target path before the constraints. The prohibited-secret clause is somewhat parenthetical but earns its place given the shared-file context. No filler sentences.

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 no-output-schema mutation tool with nested objects, the description covers what is written, where, the intent gate, and the secret rejection rule. It leaves the merge behavior for nested/omitted keys and the effect of response_format to inference, which is a minor gap rather than a blocking one.

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%, so the schema already documents the patch and explicit_user_intent params. The description enumerates the allowed top-level patch keys, matching the schema's list without adding format or nesting rules. The response_format enum is left unexplained in both places, so no value is added over structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Persist a partial patch') and a concrete resource (the shared Delx wellness profile at ~/.delx-wellness/profile.json). It is distinguishable from the read-side siblings (whoop_profile_get, whoop_get_profile) by the write verb and by clarifying the target is the local shared wellness profile rather than the WHOOP API profile. It stops short of naming the read sibling it complements.

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

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

Gives an explicit prerequisite gate: 'REQUIRES explicit_user_intent=true' plus guidance to set it only after the user confirms. It also frames itself as cross-connector so the agent knows the write is visible to other MCPs. It never states when NOT to use it (e.g., preferring a read-only path first) or names an alternative 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 readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuinely new behavioral context the annotations do not: it adapts to current state (env vars set? token present?) and targets the human user, which tells the agent the output is dynamic rather than fixed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero waste, with the purpose and the call trigger front-loaded. Every sentence carries distinct information (what it is, how it behaves, when to call).

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 no-required-param, no-output-schema, read-only walkthrough tool whose annotations already cover the safety profile, the description covers purpose, audience, adaptivity, and invocation timing. The only omission is any hint about what the walkthrough returns or how many steps 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?

Schema description coverage is 0% and the description never mentions the response_format parameter. However, the single optional enum (markdown/json) is self-explanatory from its values, so the gap is minor; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource ('Personalized 3-step setup walkthrough') and names the audience ('for the human user'), plus the adaptive behavior. An agent can tell this apart from whoop_onboarding, whoop_get_auth_url, and whoop_exchange_code because it is the entry-point walkthrough rather than a specific step.

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

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

Gives an explicit trigger and priority: 'Call this first when the user asks how do I connect WHOOP?' That resolves the ordering against sibling setup tools. It stops short of naming when NOT to use it or calling out the specific alternatives, so it is clear context without full exclusion 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely non-redundant behavior: it fetches WHOOP v2 records, computes least-squares slopes over chronologically ordered records, stores nothing, and carries a 'not medical advice' caveat. The return-field enumeration overlaps the output schema, keeping it just short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and scope, then a structured paragraph on return shape. Every sentence carries information, though the { avg, min, max, slope, direction, n_valid } enumeration partially duplicates the output schema and could be trimmed.

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 aggregation tool with an output schema, no required params, and full annotation coverage, this description is complete: it states the computation method, the record ordering, the no-storage behavior, and the intended question it answers. Nothing an agent needs to invoke or interpret it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%: the days parameter (min 2, max 30, default 30) and timezone are well documented in the schema, while response_format's enum is documented only by the schema itself. The description's mention of 'last N days (default 30)' repeats what the schema already says, adding little. Baseline 3 for moderate-to-high coverage is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (aggregate) and resource (WHOOP recovery) with explicit scope (last N days, default 30) and names the exact metrics produced (recovery score, HRV, resting heart rate). This clearly distinguishes it from raw-listing siblings like whoop_list_recoveries and from whoop_sleep_trend, which covers a different resource.

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

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

Provides a concrete use case ('answer "is my recovery trending up or down?"') and contrasts with the alternative approach of paging the raw collection yourself. It lacks an explicit when-not condition or a named sibling, but the context for choosing this over whoop_list_recoveries is clear.

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 destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds genuinely useful context beyond that: it names the concrete destruction (local token file deleted) and the human-in-the-loop requirement. It does not address idempotentHint=false (repeat-call behavior), which is the only remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the action, then the gating rule. No filler or repetition.

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 exists and annotations are rich, so return values need no explanation. The description covers purpose, gating, and consequences, leaving only repeat-invocation/idempotency unaddressed for an irreversible operation.

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 50%: explicit_user_intent is already well documented in the schema, and response_format is an enum with a default. The description echoes the intent-gating concept but adds no syntax or format detail, so it only marginally exceeds 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?

States a specific verb+resource ('Revoke the current WHOOP OAuth access grant') and adds the concrete side effect ('delete the local token file'). This is clearly distinguishable from the read-oriented siblings like whoop_connection_status and whoop_get_profile.

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 when-to-use ('only when the user explicitly wants to disconnect WHOOP') and when-not ('agents must not call this autonomously'). The gating condition is stated directly, leaving nothing to inference.

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

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

Adds substantive context beyond the annotations: it discloses the return object shape ({avg,min,max,slope,direction,n_valid}), how slope is computed (least-squares over chronologically ordered scored sleeps), direction semantics, and that it stores nothing. Annotations already cover readOnly/idempotent/destructive, so these additions are the value-add, though no pagination or failure-mode detail is given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the aggregation scope and metrics, then details the return shape and slope/direction semantics. Slightly dense with parenthetical details, but every sentence contributes information an agent needs to interpret the output.

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 an output schema exists, the description needn't reproduce return values, yet it explains slope/direction semantics that are central to interpreting results. Combined with the use-case framing and no-storage note, it is nearly complete, missing only edge-case behavior (e.g., insufficient_data handling changes).

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 67% and the description reinforces the days default (30) and its purpose, aligning with the schema's own min/max note. The timezone and response_format parameters are left entirely to the schema, so the description adds meaningful context for one param but not all three.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (aggregate) and resource (WHOOP sleep) with explicit scope (last N days) and enumerates the exact metrics produced. An agent can distinguish this from whoop_list_sleeps (raw paging) and whoop_recovery_trend without opening the schema.

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

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

Provides an explicit use case ('answer "is my sleep improving or degrading?" without paging the raw collection yourself') and implicitly contrasts with the raw-listing sibling. It lacks a clear when-NOT-to-use statement or named alternative tool, keeping it below 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 declare readOnly/idempotent/openWorld/destructive=false, so the safety profile is covered. The description adds real behavioral context beyond that: it is a composite workflow tool that conditionally 'compares a recent window against a prior window when available,' and that its output is a coaching-oriented review rather than a diagnosis. It stops short of describing pagination or output size, but the output schema carries return structure.

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 short paragraphs with the payload enumeration front-loaded and the comparative-behavior/use-case caveat second. Every sentence earns its place; only minor cost is the fairly long content list that could be trimmed.

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 composite workflow tool with an output schema (so return values needn't be explained) and rich annotations, the description covers what it builds, how it compares windows, and who it's for. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Three of four parameters are documented in the schema (days, timezone, compare_days), giving 75% coverage, and the undocumented response_format is a self-evident markdown/json enum. The description adds no parameter-level detail (e.g. what disabling comparison or choosing json changes), so the baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Build a weekly WHOOP operating review' — and enumerates the included sections (recovery, sleep, strain, workouts, bottlenecks, action candidates, metrics), so an agent knows exactly what composite artifact it produces. It distinguishes itself from point-list siblings implicitly via 'weekly' scope and the comparative workflow framing, though it never names an alternative tool outright.

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

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

Gives a usage context and a negative bound — 'intended for coaching and agent workflows, not medical diagnosis' — which is genuine guidance. However it never points to the alternative to use instead (e.g. whoop_daily_summary for a single day, or the trend tools for a narrower query), leaving sibling selection to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so safety and idempotency are covered structurally. The description adds that this is a derived normalization/aggregation step rather than a raw data fetch, which is useful context, but it says nothing about how the normalization behaves, what window is default, or auth requirements.

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 with no filler. It is efficient, though the abstract phrase 'shared wellness_context shape' is jargon that an agent without external context cannot fully parse.

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 exists, so return values need not be described. However, for a 6-parameter tool with only 33% schema coverage and zero usage guidance, the definition leaves real gaps around the optional inputs (notes, soreness, injury_flags) and when to select this tool over its siblings.

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% (2 of 6 parameters documented). The description mentions recovery, sleep, strain and workout load but never explains notes, soreness, injury_flags, or response_format, so it fails to compensate for the undocumented parameters. The 'recent workout load' phrasing loosely gestures at the days window but adds no syntax or format detail.

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 ('Normalize') and enumerates the resources involved (WHOOP recovery, sleep, strain, recent workout load), and names the target shape and consumers. It is clear what the tool produces, though it does not explicitly distinguish itself from sibling summary tools like whoop_daily_summary or whoop_weekly_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?

There is no explicit when-to-use guidance, no mention of prerequisites, and no named alternatives among the many sibling tools. The phrase 'for exercise recommendation engines and Telegram agents' implies an audience but not a decision rule for the agent choosing between this and whoop_daily_summary.

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