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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, and the description still adds real context: no GPS/location data is returned, setting either include flag yields an explicit unsupported error, results are paginated, and laps are not guaranteed. It does not mention auth requirements or rate limits, which keeps it below 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?

Four short sentences with no filler, and the core purpose is front-loaded. The opening clause 'not guaranteed laps' is cryptic out of context, but every sentence carries information the agent needs.

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 shape need not be described, and the description covers the important behavioral gaps: unsupported flags, absent location data, and pagination continuation. The remaining gap is page-size/offset semantics for split_limit and split_offset, which neither schema nor description explains.

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 carry parameter meaning and it only partly does: it defines activity_id's format (positive decimal string) and the failure behavior of include_gps/include_samples, and implies split_offset via the next_offset instruction. split_limit and split_offset's own semantics (max page size 100, offset bounds) are never explained in prose.

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: retrieves an activity summary plus one page of split summaries, and flags that laps are not guaranteed. The 'feature/group split summaries' phrasing is jargon-heavy, but combined with the tool name and sibling set (list_activities, get_sleep, get_hrv, get_daily_summary) an agent can still tell what this returns and how it differs from a listing 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 concrete usage constraints for the include flags (samples/GPS unsupported in v1, will error) and tells the agent to follow pagination.next_offset — genuinely useful invocation guidance. However it never states when to choose get_activity over list_activities or get_daily_summary, so the sibling routing 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes beyond them with real interpretive caveats: fields appear only 'if present', Garmin's restingValue may fall back to absolute minimum HR, and stress/Body Battery keep Garmin's native scale. It doesn't say what happens when the 31-day cap is exceeded, but the domain caveats are genuinely 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?

Three tight sentences: what data first, then the range constraint, then data-quality caveats. Telegraphic style but every sentence carries distinct, non-redundant 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?

With an output schema present, return shape needn't be described, and annotations cover safety, so the description's job is range rules and field interpretation, which it does. The residual gap is sibling routing and the failure mode past 31 days.

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

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

Schema coverage is 0%, so the description has to carry the load, and it does: ISO date format, inclusive bounds, the 31-day maximum, and end_date defaulting to start_date. Only start_date's role as the anchor of the range is left implicit.

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

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

The description names the exact data returned (daily steps, Garmin resting HR in bpm, stress, Body Battery), which distinguishes it from siblings like get_sleep and get_hrv without ambiguity. It omits an explicit verb such as 'returns' and doesn't state the grain (per-day records) outright, but the resource is unmistakable.

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 the operative constraint for calling it: an inclusive ISO range capped at 31 days, with end_date defaulting to start_date. It offers no guidance on when to prefer this over get_hrv, get_sleep, or list_activities, so the agent must infer the boundary from the field list alone.

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

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

Annotations already cover read-only, idempotent, open-world semantics, and the description adds genuinely new context: a hard 31-day span limit, the end-date fallback, and a data-quality caveat that units and sleep-start/wake-date association are unverified. That caveat is behaviorally important since it warns the agent the values may not be directly comparable or time-aligned.

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 what is returned, followed by range rules and caveats. No filler; the only cost is the slightly awkward 'Reported overnight/weekly' phrasing, which takes a moment to 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 needn't be explained, and the description instead covers the limits an agent could actually get wrong (span cap, default end date, unit ambiguity). What remains unstated is when baseline/status is or isn't included in the response, a minor gap for a 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 description coverage is 0%, so the description must carry the load, and it does: ISO format, inclusive bounds, max 31-day span, and the end_date → start_date default. It stops short of clarifying null handling for end_date, but both parameters are otherwise meaningfully specified beyond the bare schema patterns.

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 the specific resource (HRV averages plus optional Garmin baseline/status), which is clearly distinct from siblings like get_sleep and get_daily_summary. The verb is only implied by 'Reported' rather than stated as an explicit action, so it's clear but not maximally crisp.

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 31-day inclusive range and 'end defaults to start' give concrete calling constraints, implying a bounded date-range query. However, there is no explicit when-to-use vs. alternative guidance (e.g., HRV vs. get_sleep-derived metrics), leaving 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 cover read-only, idempotent, non-destructive, open-world behavior, so the description's added value is the 31-day range ceiling, the end_date default, and the caveat that Garmin calendarDate is preserved while wake-date vs sleep-start-date association needs live verification. That is meaningful operational context an agent cannot get from structured fields. It does not mention failure behavior when the range is exceeded.

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 is returned, then the range/default rules, then the calendarDate caveat — no filler. The final sentence is dense and slightly cryptic, but it is one line of real content rather than padding.

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 spelled out, and the description covers range limits, defaults, and the date-association ambiguity. What is missing is error behavior past 31 days and any timezone note, which matters for a date-scoped sleep query.

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

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

Schema coverage is 0%, so the description must carry the parameters, and it does: dates are inclusive ISO dates, the range is capped at 31 days, and end_date defaults to start_date. The semantics of both parameters are clarified beyond the bare pattern in the schema.

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

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

The description states concretely what is returned: sleep duration/stages in seconds, score components, and window times. That is far more specific than the name alone, though it never explicitly distinguishes this from get_daily_summary, which likely overlaps on sleep content.

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 a hard constraint (inclusive range of at most 31 days, end defaults to start) but no guidance on when to call this instead of get_daily_summary, get_hrv, or other siblings, and no exclusion conditions. The agent must infer the selection rule 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?

Annotations already cover read-only, idempotent, non-destructive, open-world, so the description's value-add is the page-size ceiling of 100, the 366-day maximum window, and the fact that dates are interpreted as Garmin-local. Those are genuine constraints beyond the annotations, though result ordering and empty-result behavior remain undisclosed.

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 lines with no filler; the hard constraints come first and the caveats follow. The "Units" sentence is terse to the point of ambiguity about which fields it applies to, which is a minor structural weakness rather than verbosity.

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

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

An output schema exists, so return values need not be explained, and the description covers the key caller-facing constraints for a paginated list tool with 0% schema description coverage. Gaps remain around offset interplay with next_offset and ordering, but nothing essential to a correct first call 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 0%, so the description carries the full burden: it clarifies that `sport` is a parent activity type key rather than a subtype and gives examples, and it bounds the date window and page size. `limit` and `offset` semantics are only obliquely implied by "max 100" and "pagination.next_offset", leaving two of five parameters weakly documented.

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 one activity page") plus concrete scope constraints (max 100, <=366 inclusive Garmin-local dates), which an agent can act on immediately. It implies a paged-collection read distinct from the sibling get_activity, but never names or contrasts with 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?

"Follow pagination.next_offset" gives real operational guidance for iterating pages, and the sport note steers callers away from passing subtypes. However, there is no statement of when to use this tool versus get_activity or get_daily_summary, and no prerequisites or exclusions are given.

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