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

Goes well beyond the readOnlyHint and openWorldHint annotations: link is one-time, expires in 10 minutes, must be handed to the user to open in a browser, and it reads no WHOOP data. It also discloses two non-obvious edge-case behaviors — stdio mode returns setup instructions instead of a link, and an unconfigured WHOOP app returns its setup page address — which materially change how the agent should present the result.

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 what it returns, then the trigger, then the handoff instruction, then the caveats — a sensible priority order. It is a dense four-sentence block, but each sentence carries distinct operational information (expiry, browser handoff, stdio fallback), so little is wasted.

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

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

Although there is no output schema, the description explains what comes back in every mode: a one-time link, stdio setup instructions, or a setup page address. For a zero-parameter auth tool with a single job, an agent has everything needed to call it and relay the result.

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

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

The tool takes no parameters, so the empty schema is already complete and the description has nothing to disambiguate. Baseline for a zero-parameter tool; no syntax or format gaps exist to compensate for.

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 and resource — returns a one-time link that connects the user's WHOOP account — and immediately distinguishes itself from the sibling data tools by stating it doesn't read any WHOOP data. An agent can tell it is the auth/bootstrap tool, not a data retrieval 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?

Gives the exact trigger: use it when a data tool such as get_today reports WHOOP isn't connected or its authorization expired, and names the post-condition (after login, get_today and other data tools work). Sibling tools are named as the source of the signal, so the routing decision is explicit.

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

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

Annotations already declare read-only, idempotent, open-world behavior, yet the description adds substantial context beyond them: it fetches live data every call with no caching, reports explicitly when WHOOP is unreachable, lists unscored days as pending, and returns a get_auth_url prompt when WHOOP isn't connected. These are behavioral traits an agent needs and none are in the structured fields.

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 the return shape and scope before branching into alternatives and behavior, which is the right ordering. It is on the long side (roughly ten sentences) but nearly every sentence carries distinct information; only the calibration/pending detail borders on over-explanation.

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 fully compensates by naming the returned table columns, the averages aggregation, the newest-first ordering, and pending-day handling. Failure and auth paths are covered too, so an agent can call this correctly without further discovery.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by tying values to intent ('7 for the last week, 30 for the last month, up to 90') and by noting the default of 14 and the newest-first ordering. It meaningfully reduces ambiguity about how to choose a value rather than restating 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 ('Returns daily recovery for the last `days` days') and enumerates the exact columns returned, so the agent knows precisely what data it gets. It also distinguishes itself from get_today and get_sleep_analysis by name, making sibling selection unambiguous.

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

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

Explicitly routes the agent: 'For today alone, use get_today; for the sleep behind the numbers, use get_sleep_analysis,' and gives a concrete use case ('how has my HRV changed this month?'). It further maps questions to parameter values ('7 for the last week, 30 for the last month'), which is unusually actionable guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds genuinely new behavior: live fetch on every call with no cached copy, the day-attribution rule (a night counts toward the wake-up day), unscored nights appearing as pending, and failure paths (WHOOP unreachable, or not connected → call get_auth_url).

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 routing before the column inventory, and nearly every sentence carries actionable information. It is a dense single paragraph, though, and the long enumerations of table columns make it heavier to scan than it needs to be.

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 thoroughly (table structure, metrics, averages, pending nights), plus edge cases: auth state, live-fetch freshness, and unreachable-service behavior. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the range/default are already documented, but the description adds interpretive value the schema lacks: the mapping of day counts to question phrasing (7 = last week, 30 = last month) and the counting convention (back from today).

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 (nightly sleep over the last `days` days, newest first) and enumerates the actual returned tables and metrics, so an agent knows exactly what it gets. It also explicitly distinguishes itself from siblings by naming get_today and get_recovery_trends and the conditions that select them.

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 explicit when-to-use ('Use it for sleep patterns'), when-to-use-something-else with named alternatives ('For last night's stages, use get_today; for the recovery those nights produced, use get_recovery_trends'), and concrete parameter selection guidance ('7 for the last week, 30 for the last month, up to 90').

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, yet the description adds substantial context beyond them: live fetch on every call with no cached copy, un-scored days listed as pending, the in-progress day marked and excluded from averages, and a fallback path (returning a message to call get_auth_url) when WHOOP is not connected. This is exactly the behavioral disclosure annotations cannot carry.

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 the return shape and followed by usage, alternatives, and failure modes in a logical order. It is a dense paragraph rather than bullets, and a few clauses (e.g., repeating the day-range guidance already implied by the parameter) could be trimmed, but nearly 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?

With no output schema, the description fully compensates by enumerating the returned columns (strain, calories, avg/max HR, steps, averages), the row ordering, the pending/in-progress markers, and the error/not-connected behaviors. An agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3, and the schema already documents range (1-90) and default. The description goes further by mapping intent to value ('7 for the last week, 30 for the last month'), which is meaningful guidance beyond the schema's numeric bounds.

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 (daily strain history), the exact scope (last `days` days, default 14, including today), and the return shape (Markdown table, newest first). It also distinguishes itself from siblings by naming get_workouts and get_recovery_trends as the alternatives for their respective questions.

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 routes the agent: 'Use it for overall load and activity trends. For individual training sessions, use get_workouts; for how the body coped, use get_recovery_trends.' It further gives concrete parameter selection guidance (7 for the last week, 30 for the last month, up to 90).

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?

Goes well beyond the annotations by disclosing that data is fetched live on every call with no caching, that the answer ends with a version-update notice to relay to the user, and that failures surface a message pointing at get_auth_url when WHOOP isn't connected. The annotations cover safety/idempotency, and the description adds caching, freshness, version and auth-failure behavior on top.

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 the primary purpose and scoping/'use it first' guidance early, with failure modes last. The middle sentence enumerating every returned field is long and dense, but it is information-dense rather than filler, so only minor trimming is possible.

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 describing return shape and does so exhaustively (per-section fields, dated sections, Markdown format). Auth, connectivity, freshness and version-notice behaviors are all covered, leaving no obvious gap for an agent to call this 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies no arguments are needed; there is no parameter semantics to add.

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 ('Returns the user's latest WHOOP status as Markdown') and then enumerates the three sections returned (recovery, sleep, strain). It is immediately distinguishable from siblings like get_workouts or get_sleep_analysis, which cover different scopes.

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 names the trigger conditions ('how am I today?', 'should I train hard?') and the alternatives for a different scope ('For more than one day, use get_recovery_trends, get_sleep_analysis, get_strain_history or get_workouts'). Both when-to-use and when-not-to-use are covered with named siblings.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety bar is met structurally; the description adds genuinely new behavior beyond them: live fetch with no caching, 'unscored' handling for unprocessed WHOOP data, an explicit error message when WHOOP is unreachable, and an auth-not-connected path returning a prompt to call get_auth_url.

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 what is returned before routing advice and behavioral notes, and every sentence carries information — the long field enumeration is justified because there is no output schema. It is a dense single paragraph, though; the return-format inventory could be lightly compressed.

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 fully specifies the return shape (main table, details table, totals), the ordering, the null/'unscored' case, and both failure modes. Nothing an agent needs to call it correctly or interpret the result 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 100% and the schema already documents min/max/default for `days`, so baseline is 3. The description goes further by mapping values to intent ('7 for the last week, 30 for the last month, up to 90'), which helps an agent choose a value rather than just validating it.

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 with scope: individual workouts from the last `days` days, newest first, and enumerates the returned fields. It explicitly contrasts itself with the sibling get_strain_history ('whole-day strain including activity outside workouts'), so an agent can route between them without opening either schema.

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

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

Gives explicit when-to-use ('questions about specific sessions or training volume'), names the alternative and the exact condition that selects it (get_strain_history for whole-day strain), and even tells the agent how to pick `days` (7 for last week, 30 for last month, up to 90). Failure routing to get_auth_url is also specified.

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