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

No annotations are provided, so the description carries the full behavioral disclosure burden. It lists the returned fields but does not state that this is a read-only/safe operation, whether authentication is required, or how the data is scoped to the user, leaving key behavioral traits unstated.

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

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

The description is a single front-loaded sentence with no wasted words. It efficiently conveys the exact measurements and their units.

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 a zero-parameter read tool with an output schema, the description is largely complete: it specifies the returned data and units, and the output schema handles structure. However, without annotations, it could do more to clarify that this is a safe, read-only operation and when to prefer it over get_profile.

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

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

There are zero input parameters, so the baseline is 4. The description adds useful semantic detail about the returned measurements and their units, though it does not need to explain parameter syntax because no parameters exist.

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

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

The description clearly identifies the exact data returned (height in meters, weight in kilograms, max heart rate) and scopes it to the user's WHOOP configuration. It is a noun phrase rather than an explicit verb, but the tool name and title supply the retrieval action, making it distinguishable from siblings like get_profile or get_recovery.

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

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

The description offers no guidance on when to use this tool versus alternatives such as get_profile. It does not state prerequisites, context, or exclusions, leaving usage inference entirely to the agent.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it discloses almost nothing. It does not state that this is a read-only fetch, whether authentication is required, whether the result can be empty for an unknown id, or any scoping behavior. Being a plain noun phrase, it adds no behavioral context beyond the schema.

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

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

A single front-loaded sentence fragment with zero filler. It is efficient, though it is a fragment rather than a well-formed instruction, which keeps it short of a 5.

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

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

With an output schema present, return-format explanation is unnecessary, and the sole parameter is fully covered by the schema. What is missing is the relationship to get_cycles and any note on what 'physiological cycle' returns, leaving a minimal-but-usable definition.

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

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

Schema description coverage is 100%: cycle_id is documented in the schema with type and an example origin ('from get_cycles or a recovery record'). The description adds nothing beyond that, so the baseline of 3 for schema-covered parameters applies.

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

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

The phrase 'A single physiological cycle by its numeric id' identifies the resource and implies a fetch-by-key, but supplies no verb (get/fetch/retrieve) and never names the sibling get_cycles it contrasts with. An agent can infer it is a single-record lookup versus the list tool, but must infer rather than read 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_cycles. The only implied routing signal is 'single ... by its numeric id', which the agent must extrapolate on its own.

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?

With no annotations, the description carries the full burden and does disclose non-obvious behavior: reverse-chronological ordering, that the current cycle has no `end`, and that the range is matched against the activity's own start/end window rather than the wall-clock query window. It omits auth needs and rate-limit behavior, keeping it short of a 5.

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

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

Three tight sentences: resource definition and ordering first, field meanings second, selection/pagination mechanics third. No filler and the most important orientation (what a cycle is) is 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 structure need not be restated, yet the description still supplies enough domain framing (cycle boundaries, current-cycle null end, field semantics, pagination) for an agent to call it correctly. Nothing critical 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 baseline is 3. The description goes beyond the schema by explaining what the returned cycle fields mean (score.strain = day strain 0-21, kilojoule = energy burned), defining cycle boundaries, and clarifying the range-matching semantics that the schema does not state.

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 the specific resource (physiological cycles, one per WHOOP day from wake-up to wake-up) and the ordering (newest first), which is a clear verb+resource framing. It implicitly distinguishes itself from get_cycle_by_id (list vs single), but never names that sibling explicitly.

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

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

Gives operational guidance on parameters ('Use start/end to select a date range and next_token to page'), but says nothing about when to prefer this list tool over get_cycle_by_id or get_sleep_for_cycle/get_recovery_for_cycle, which are the real routing alternatives among the 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?

No annotations are supplied, so the description carries the full behavioral burden, and it only reveals the returned fields. It does not state that this is a read-only operation, whether any authentication or scopes are required, or what happens on missing/expired credentials. With an output schema present the return-shape detail is largely redundant anyway.

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 short sentence with no filler or redundancy, and it is front-loaded. It is a sentence fragment rather than a full statement of the action, which keeps it just short of ideal.

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

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

For a zero-parameter getter with an output schema documenting the response, the description is nearly sufficient — an agent knows it fetches the current user's identity fields. It would be complete with one clause noting read-only behavior, since no annotations exist to convey that.

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 there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. Nothing in the text misdescribes the (empty) input contract.

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

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

The description names the resource and its exact contents ('the authenticated user's name and email'), which combined with the verb in the tool name makes the operation unambiguous. It is clearly separable from all siblings, which deal with recovery, sleep, cycles, workouts, and body measurements. It falls short of a 5 only because it describes the payload rather than restating the retrieval action.

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

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

There is no statement of when to call this tool versus alternatives, no prerequisites, and no mention of the authenticated-user scoping constraint as guidance. For a zero-argument profile getter the omission is low-risk, but no usage guidance is actually provided.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses sort order, the meaning of created_at vs the referenced sleep, and the non-obvious date-range/sleep-window matching quirk that would otherwise cause off-by-one confusion. It omits auth requirements, rate limits, and error behavior, so it stops 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?

The core content is front-loaded and dense with useful detail, but the final sentence ('WHOOP matches the range against the activity's own start/end window') largely restates the earlier note and introduces the word 'activity' in a recovery tool, which is confusing rather than additive.

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

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

For a read-only list tool with a full input schema and an output schema, the description covers the essentials an agent needs — ordering, field meanings, pagination, and the critical date-range quirk — without having to explain return values. Only the absence of any auth/permission context 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?

Schema coverage is 100%, so the baseline is 3, and the description earns above that by adding real semantics the schema lacks: the range is matched against the underlying sleep window, so an end date of day N still returns the recovery scored on N+1. It also ties start/end to range selection and next_token to paging, though it does not clarify limit behavior.

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 opening sentence names a specific resource ('recovery records') and states ordering ('newest first'), then enumerates the payload fields, so an agent knows exactly what comes back. However, it never distinguishes this tool from the sibling get_recovery_for_cycle, leaving the retrieval-by-date-range vs retrieval-by-cycle choice 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?

It states the mechanics of use ('Use start/end to select a date range and next_token to page'), which implies the intended workflow, and the sleep-window caveat implicitly explains when boundary days include an extra record. It gives no explicit when-to-use or when-not-to-use guidance and never mentions the sibling alternative.

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

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

With no annotations, the description carries the full behavioral burden. It adds one useful domain fact — recovery is computed from the preceding sleep — but says nothing about read-only nature, auth requirements, or what happens when a cycle has no associated recovery. For a getter with zero annotation coverage this is thin.

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, stating the resource and its derivation. It earns its place, though the brevity leaves capability gaps that a slightly longer description could cover.

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 the single required parameter is well documented. What is missing is edge-case behavior (e.g. cycles without recovery) and any routing versus get_recovery, leaving it merely adequate 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 100% and the cycle_id description already explains its format and provenance ('e.g. from get_cycles or a recovery record'). The description adds no syntax or constraint beyond the schema. Baseline 3 applies since 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?

The description names a specific resource — the recovery score computed for a given cycle — and adds the causal detail that it derives from the preceding sleep. An agent can tell it fetches recovery tied to one cycle. However, it does not distinguish itself from close siblings like get_recovery or get_sleep_for_cycle, leaving the reader to infer the difference.

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 prerequisites, and no mention of alternatives such as get_recovery (all recoveries) or get_cycles. The only implicit signal is that a cycle_id is required, which the schema already states. Nothing routes the agent between this and its 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?

With no annotations, the description carries the full load and does it well: it discloses ordering (newest first), that naps are included and flagged, timezone handling (UTC with timezone_offset), and the non-obvious matching rule that the range is compared against the activity's own start/end window. It does not touch on auth requirements or rate limits, but the core behavioral profile is well 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?

Five dense sentences, front-loaded with what is returned and its ordering before moving into field semantics, timezone, and pagination. Every sentence carries information, though the middle field-explanation sentence is somewhat packed.

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 needn't be re-explained, yet the description helpfully annotates key fields (stage_summary in ms, sleep_needed, sleep_performance_percentage). Combined with ordering, timezone, and range-matching semantics, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning beyond the schema: it explains that start/end select a date window and are matched against the activity's own start/end, and that next_token is for paging. This goes past the schema's terse 'earliest/latest record' wording.

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 (retrieves WHOOP sleep records) and adds distinguishing scope details: records include naps (flagged by `nap`) and are returned newest first, which signals this is a listing tool rather than a single-record fetch. It does not explicitly name siblings like get_sleep_by_id or get_sleep_for_cycle, so an agent must infer the boundary.

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 tells the agent how to drive the tool ('Use start/end to select a date range and next_token to page'), which is useful operational guidance, but never states when to prefer this over get_sleep_by_id or get_sleep_for_cycle. Usage is implied by the paginated list framing rather than declared.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read by saying 'a single sleep record,' but does not explicitly state read-only behavior, permissions, error behavior, or any other operational trait.

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

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

The description is a single front-loaded sentence with no wasted words. It immediately states the resource and the key identifier context.

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

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

For a simple getter with an output schema, the description covers the essential identifier source, which is enough to invoke correctly. It remains incomplete regarding usage context versus sibling tools and behavioral expectations, especially with no annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It identifies the parameter as a UUID and usefully notes that it can come from a recovery record, but it does not add format or constraint details beyond what the schema already defines.

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 single sleep record retrieved by UUID, which clearly distinguishes this from the plural and cycle-scoped sleep siblings. However, it lacks an explicit verb and does not name an alternative tool, so it falls short of full sibling 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?

It hints at where to obtain the sleep_id ('from a recovery record'), but gives no when-to-use guidance, no prerequisites, and no comparison to alternatives like get_sleep or get_sleep_for_cycle.

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?

With no annotations provided, the description carries full behavioral burden. It explains the conceptual relationship (sleep that closed the cycle) but does not state permissions, read-only nature, rate limits, or any other operational behavior.

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

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

A single, front-loaded sentence that precisely defines the association without any wasted words. It is appropriately sized for a simple getter.

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

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

For a one-parameter read tool with a fully documented schema and an output schema, the description provides adequate conceptual clarity. It could still mention when to prefer this over get_sleep, but otherwise nothing critical is missing.

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

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

Schema description coverage is 100%, and the schema already documents cycle_id with meaning and examples. The description adds no parameter-level details beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description names a specific resource (the sleep that closed the given cycle) and clarifies the relationship, distinguishing it from get_sleep and get_sleep_by_id. The verb 'get' is implied by the tool name rather than stated explicitly, but the resource and scope are clear.

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

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

No explicit guidance on when to use this tool versus alternatives like get_sleep or get_sleep_by_id. The description implies usage when you have a cycle and want its associated sleep, but this must be inferred rather than being 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?

With no annotations, the description carries the full burden. 'Get' implies a read, but nothing is stated about authentication requirements, whether the call can fail for unknown/expired IDs, or rate limits. It adds essentially no behavioral context beyond the implied read semantics of the verb.

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 short sentence with no filler, and the distinguishing detail ('by its UUID') is front-loaded. It is not truncated in a way that loses meaning, though it is slightly terse for a tool definition.

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

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

The tool is simple: one required UUID param and an output schema that covers return values, so the description need not explain the response. It is minimally complete, but leaves the ID-sourcing workflow and failure behavior unaddressed.

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

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

Schema description coverage is 0%, but the param name 'workout_id' plus format: uuid and a strict UUID pattern make the schema largely self-documenting. The description's 'by its UUID' only marginally reinforces this and adds no format, source, or validity guidance beyond what the schema already encodes.

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 identifies the specific resource (a single workout record) and the keying mechanism (its UUID), which cleanly separates it from the sibling get_workouts list tool. It is a noun phrase rather than a verb+resource statement, so it reads more like a label than an action description, but the intent is 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?

There is no guidance on when to use this versus alternatives. The 'by its UUID' framing implies you need an ID already in hand (e.g. from get_workouts), but that workflow and any exclusions are left entirely to inference from sibling names.

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?

With no annotations, the description must carry the behavioral burden. It discloses that records are returned newest first, that distance/altitude are present only when GPS was recorded, and that the range is matched against the activity's own start/end window. It does not state read-only nature, auth requirements, or rate limits, but the field-level caveats are useful.

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 sentences, each earning its place: return ordering, field semantics, parameter usage, and matching behavior. Front-loaded with the core resource fact and 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 value structure need not be described, but the description still explains key fields, pagination, and date-range matching. For a list tool with no annotations and full schema coverage, this is nearly complete, though read-only/auth context is absent.

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

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

Schema coverage is 100%, and the schema descriptions already explain start/end inclusivity/exclusivity and limits. The description reinforces that start/end select a range and next_token pages, adding the notable matching semantics, but does not add syntax or format 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 clear resource: workout records, newest first. It describes fields (sport_name, score.strain, zone_durations, distance, altitude) which grounds the domain. It doesn't explicitly differentiate from sibling get_workout_by_id (single vs list), but the range-paging language implies a list.

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

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

It says to use start/end to select a date range and next_token to page, which is procedural guidance for invocation. There is no when-to-use versus get_workout_by_id distinction, and no exclusions or alternatives named.

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