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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further by disclosing the full breadth of returned content, including strength-specific set/rep/weight data. It stops short of covering edge cases like missing data, unit conventions, or auth failures, which keeps it from a 5.

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

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

The key statement is front-loaded, and the long field enumeration is functional rather than decorative since it determines whether the tool fits the agent's data need. The list is dense but every clause names a distinct data category; minor tightening would only marginally improve it.

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 returns and does so thoroughly, including the conditional strength-activity fields that would otherwise be invisible. An agent can decide correctly whether to call it and how to obtain its argument.

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% for the single activity_id parameter, so the baseline is 3. The description adds real value beyond that by naming the two tools that produce a valid id, which the schema does not say.

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?

Opens with a specific verb and resource ("Full summary of one Garmin activity") and then enumerates the exact fields returned, so an agent knows precisely what data this tool surfaces. It explicitly distinguishes itself from garmin_get_activity_laps and from the search/day tools that locate ids.

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 routing in both directions: per-lap rows belong to garmin_get_activity_laps, and the required activity_id is obtained via garmin_search_activities or garmin_get_day. That is a when-to-use plus how-to-prepare instruction, 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?

Beyond the readOnly/openWorld annotations it discloses three things structured data cannot: location is never returned (privacy boundary), long activities can fail on the Cloudflare free plan with a CPU-limit connector error, and the agent should report that failure rather than retry. That failure-mode handling is exactly the behavioral context an agent needs.

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 output shape, then use cases, then prerequisite, then failure handling — four dense sentences with no filler. Every sentence contributes a fact the agent cannot get from annotations 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?

There is no output schema, so the description carries the return-value burden and does so by enumerating the metric families returned plus the lap/rep row duality. Combined with the failure-mode note and the id-sourcing hint, nothing needed 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% and there is only one parameter, so the baseline is 3; the description earns an extra point by telling the agent where activity_id comes from (garmin_search_activities), a provenance hint absent from 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 the exact output shape ("one row per lap of an activity, plus one row per interval rep when it was an interval session") and enumerates the metrics returned, which distinguishes it clearly from siblings like garmin_get_activity (summary) and garmin_get_activity_streams (raw time series). An agent knows from the first clause what granularity this tool yields.

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 concrete example questions ("how did each rep go?", "which kilometres were slowest?") that select this tool, and supplies the prerequisite workflow (get activity_id from garmin_search_activities). It stops short of explicitly naming when to prefer garmin_get_activity or garmin_get_activity_streams instead, so no 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 only declare readOnlyHint and openWorldHint=false, so the description carries the behavioral load and does so well: Garmin-side downsampling to roughly `points` rows, omission of channels the activity didn't record, exclusion of location data entirely, and the default channel set. It also fixes the row layout (distance in km then elapsed time in s), which an agent could not infer otherwise.

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 the tool returns, then channel defaults, then the id prerequisite. Every sentence adds a fact an agent needs; nothing is redundant with the 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 fully compensates by describing the return shape (`columns` and `rows`, leading distance/elapsed-time fields). For a three-parameter read tool with rich schema coverage and minimal annotations, nothing material 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 earns more by restating the default channel list and adding semantics the enum doesn't carry — that cycling activities should use speed rather than pace, and that unsupported channels are silently dropped rather than erroring. The `points` parameter's downsampling behavior is also characterized as approximate, matching the schema's "Approximate number of rows."

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: time series for one activity, downsampled to about `points` rows, with illustrative questions ("did my HR drift in the last 10 km?") that make the output type unambiguous. It implicitly distinguishes itself from summary-style siblings like garmin_get_activity, though it never names garmin_get_activity_laps, the closest sibling by granularity.

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?

Clear usage context is conveyed through the two example questions and the explicit prerequisite "Get the activity id from garmin_search_activities," plus a selection rule for channels ("Use speed instead of pace for cycling"). It lacks explicit when-not guidance, e.g. pointing to garmin_get_activity for summary stats or laps for per-lap splits.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds meaningful behavioral context: the empty-result condition for non-workout activities and the detailed shape of the returned step/target/repeat data. Auth and rate-limit behavior are not discussed, 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?

Front-loaded with the core description, then compact sentences for the sibling comparison, empty case, and ID source. The opening sentence is dense with enumerations but every element maps to real return content, 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?

There is no output schema, and the description compensates by spelling out the return structure — steps, end conditions, targets, repeat groups. Combined with the empty-result caveat and ID provenance, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so the single activity_id parameter is fully documented in the schema. The description adds only a pointer to garmin_search_activities as the source of the ID, which is useful but modest; the baseline of 3 fits when the schema carries the definition.

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?

It states a specific verb and resource — the structured workout an activity was started from — and enumerates the returned content (steps, step-end conditions, targets, repeat groups). It distinguishes itself from siblings by naming garmin_get_activity for planned-vs-actual comparison and garmin_search_activities for ID lookup.

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 says to compare with garmin_get_activity, notes the empty-result edge case for activities not started from a Garmin Connect workout, and tells the agent where to obtain the activity id. That covers when to use it, what it returns in the negative case, and the sibling relationship.

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 read-only, closed-world operation, and the description adds substantive context beyond that: the default last-7-days window, the 31-day hard limit per call, the contents of the response, and the 30-minute averaging granularity when include_samples is set. What's missing is pagination/throttling behaviour and whether partial data is returned for days without a device sync, which matters for a health-data range query.

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 sentences with no filler: payload definition first, the one optional flag next, then the routing alternative and the range constraints. Front-loaded with the resource and its scope, so an agent can decide quickly.

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?

No output schema exists, and the description compensates fully by enumerating the returned fields (event type, start time, duration, impact, Garmin feedback) and the charge/drain framing. Combined with the annotations and the fully documented schema, nothing material is missing for correct invocation.

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

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

Schema description coverage is 100%, so all three parameters are already documented, and the description largely restates the schema: include_samples as "level through the day (averaged per 30 min)", the 7-day default, the 31-day cap. The added value is modest interpretation of what a sample represents, but no time-zone, boundary, or format guidance beyond what the schema already says.

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 resource and scope ("Body Battery per day over a date range") plus the exact payload the tool returns: charge/drain totals and per-event breakdowns for sleep, activities, rest and stress periods. It explicitly names the sibling garmin_get_daily_summaries as the tool for daily max/min, so an agent can distinguish the two 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 a concrete routing rule ("For daily max / min Body Battery use garmin_get_daily_summaries") and states the default window and the 31-day cap, which shapes how the agent should fill the date range. It stops short of addressing overlap with garmin_get_stress or garmin_get_sleep, which also surface stress/sleep data and could confuse selection.

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 only declare readOnlyHint=true and openWorldHint=false; the description adds real behavioral context: a 7-day default window, a hard 92-day cap per call, and the caveat that today's row is partial. That partial-data warning is exactly the kind of trait an agent needs and cannot get from the annotations or 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?

Front-loaded with purpose and scope, then limits, then alternatives — a sound ordering with no filler sentences. The metric enumeration is long but earns its place by letting an agent match on specific fields; only slight trimming would improve it.

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, two-optional-parameter range query with no output schema, the description covers what is returned, the default and maximum window, the partial-today caveat, and sibling routing. Nothing an agent needs in order 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 description coverage is 100% and both parameters already document their defaults and the 92-day limit, so the description's mention of defaults and the cap largely restates structured data. Baseline 3 applies; no extra syntax or timezone nuance is added beyond what start_date/end_date already say.

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 ('all-day wellness per day over a date range') and then enumerates the exact metric families returned (heart rate, Body Battery, stress, intensity minutes, steps, calories, respiration). It explicitly distinguishes itself from garmin_get_sleep_summaries, garmin_get_hrv_summaries and garmin_get_days, so an agent can pick it 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?

Gives an explicit selection criterion ('for trends') plus named alternatives for the cases this tool does not cover: sleep and HRV over a range route to garmin_get_sleep_summaries / garmin_get_hrv_summaries, and all-in-one per-day data routes to garmin_get_days. When and when-not are both 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 establish this is a safe read (readOnlyHint=true, openWorldHint=false), so the description only needs to add context — and it does, notably the non-obvious semantics that sleep is keyed by this wake-up date and that calories include intake only when food is logged. It stops short of describing response shape or any data-availability caveats for missing days, which keeps it a 4 rather than 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 front-loaded purpose clause is followed by a dense but purposeful field inventory, then two short routing sentences. The metric list is long, yet every item earns its place as coverage disclosure given there is no output schema; slightly tighter grouping would make it 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 no output schema and no structured return documentation, the description carries the burden of telling the agent what comes back, and it does so comprehensively while also handling the cross-date sleep-keying trap and the compound use case. Nothing an agent needs in order to call this correctly 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 description coverage is 100% and the single date parameter is already documented with its format and 'default: today in the user's time zone' behavior, so the baseline is 3. The description adds only indirect guidance about which dates to request, not new meaning about the parameter itself.

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 verb and resource ('One day at a glance') and then enumerates the exact metrics returned — resting heart rate, Body Battery, stress minutes, intensity minutes, steps, calories, hydration, HR alerts, sleep and HRV. That enumeration makes it distinguishable from garmin_get_daily_summaries and the single-metric siblings 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?

It gives explicit when-to-use framing ('for readiness and recovery questions'), a concrete call pattern for a specific decision ('should I train hard today?' → call for today and yesterday), and routes to named alternatives for detail (garmin_get_sleep, garmin_get_hrv, garmin_get_activity). Both the positive case and the handoff case are 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 readOnlyHint=true and openWorldHint=false, so the description's added value is the operational envelope: 7-day default window, 31-day ceiling, one-row-per-day granularity, and the fact that a `summary` block carries average/min/max per field. It omits pagination, empty-day behavior, and rate limits, 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?

Front-loaded with the core action and scope, then the field list, then alternatives. The metric enumeration is long but earns its place by previewing the return payload; only the repeated 31-day limit is mildly redundant with the 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 compensates by naming the returned metrics and disclosing the `summary` aggregate structure, plus the date-range constraints. It is essentially complete for calling correctly, though a note on how days with missing data are represented would close the remaining gap.

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

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

Schema coverage is 100% and both date parameters are fully described with defaults, so the schema does the heavy lifting. The description largely restates the 31-day cap and the 7-day default already present in the parameter descriptions, adding little new meaning.

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

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

States the specific verb and resource ('garmin_get_day over a date range, one compact row per day') and enumerates the metrics returned, so an agent can distinguish it from garmin_get_day, the per-metric summary tools, and garmin_search_activities without opening a 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 an explicit use case ('am I absorbing this training?' / recovery-vs-load), states the defaults (last 7 days) and the hard cap (31 days per call), and routes to named alternatives for deeper single-field drilling. When-to-use and when-not-to-use are both present.

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 this is a safe read-only, non-open-world call, so the bar is lower. The description still adds operational context beyond them: components may be marked stale when there is no recent data, and the VO2max exclusion prevents misreading the returned components. It does not say what happens when no fitness age exists for the date.

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?

It is a single, dense sentence that front-loads the resource and then enumerates what is returned, with a second short sentence for the stale-data caveat and a third for the VO2max clarification. Every clause carries information, though the embedded component list makes it slightly hard to scan.

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?

There is no output schema, so the description must convey the return shape, and it does so by naming the three age values plus the component breakdown and the stale flag. The only gap is the no-data/failure case for a given date, which the description leaves unstated.

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 single optional date parameter already documents the YYYY-MM-DD format and the 'today in user's time zone' default. The description only says 'on a date,' adding no semantics beyond the schema, so the 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?

The description names a specific resource (Garmin fitness age) and the exact payload: fitness age for a date, chronological age, achievable fitness age, and the underlying components (resting heart rate, BMI, vigorous days/minutes). It is clearly distinguishable from sibling metrics like garmin_get_hrv, garmin_get_body_battery, or garmin_get_profile, which share inputs but not outputs.

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 clear context for when this tool is the right one (querying fitness age for a given date) and explicitly rules out a common wrong assumption with 'Garmin does not use VO2max here.' It does not, however, name an alternative tool or state when not to call it (e.g., dates before a device supported the metric).

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

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

Annotations already declare readOnlyHint and closed-world scope, so the description's added value is the domain behavior: goals are adjusted to include active calories, food totals are per serving × servings, and empty meals appear only when the user actually logs food. That is meaningful context beyond structured fields, though it doesn't cover error/failure modes (e.g. unauthenticated or no-data responses).

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 compact sentences, front-loaded with what the tool returns, followed by the per-serving caveat and the logging prerequisite. No filler, though the third clause could be folded in more smoothly.

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 responsibly sketches the return shape (daily totals versus goals, then per-meal foods) and the main content caveat. It stops short of noting behavior when no data exists for the date, but is otherwise sufficient for a single-optional-parameter 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 100% and the single date parameter already documents the YYYY-MM-DD format and today-in-local-time default. The description adds no further parameter semantics, which is acceptable at baseline given the schema does the work.

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 resource and scope: "One day's food log from Garmin Connect" with the exact data returned (calories, carbs, protein, fat, goals, meals). It is unambiguously distinct from siblings like garmin_get_hydration or garmin_get_weight.

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 via "One day's" and the schema's default-today note; there is no explicit when-to-use versus alternatives or prerequisites (e.g. that the user must have food logging enabled is stated as a caveat about content, not a selection rule).

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 readOnlyHint already declaring safety, the description still adds real content: it previews the returned fields including alert thresholds, and discloses the 15-minute averaging resolution used for samples. It does not say what happens when no alerts fired or when a day has no data, which would have made it 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 compact sentences, front-loaded with what the call returns, then the optional flag, then the alternative tool. No filler and nothing repeated from the name or title.

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 two-optional-param read with no output schema, the description supplies exactly what is missing: the shape of the response and the meaning of the sample flag. An agent can call this correctly and interpret the result from the description alone.

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 states the YYYY-MM-DD format, the today default, and the 15-minute averaging default. The description mostly restates that; its only addition is the sample-resolution use case, which is marginal beyond the schema.

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

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

Names the exact resource and scope (one day's all-day heart rate) and enumerates what comes back: resting, min/max, Garmin's 7-day resting average, and alert values with thresholds. That distinguishes it from garmin_get_heart_rate_zones, garmin_get_hrv and garmin_get_daily_summaries without the agent needing to open 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?

Gives explicit conditional guidance for the optional include_samples flag with a concrete motivating scenario, and routes range-based resting HR queries to garmin_get_daily_summaries. It stops short of a full when-not-to-use statement (e.g. vs. HR zones or HRV), so it is strong but not exhaustive.

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?

readOnlyHint=true and openWorldHint=false already establish a safe, local read, so the description's job is to say what comes back - and it does, naming zone bpm ranges, max/resting/lactate-threshold values, the calculation method, and the per-sport grouping. It does not say anything about sport coverage (which activities have zones) or behavior when no zones are configured, which is a modest gap 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?

Two sentences, zero waste. The payload (what the zones contain) is front-loaded and the sibling disambiguation follows it, which is the correct priority order.

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 parameters and no output schema, the description carries the full burden of describing the return shape, and it does so by enumerating the zone ranges, the three reference heart rates, and the derivation method. Nothing an agent needs in order to call or interpret this tool 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming the call is argument-free, which matches the empty schema. Baseline 4 applies for a no-parameter tool.

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 (heart-rate zones per sport) and enumerates its contents: bpm ranges for zones 1-5 plus max, resting and lactate-threshold heart rate and the method they are based on. That precision, plus the explicit contrast with garmin_get_profile, lets an agent distinguish it from every sibling without opening a 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 second sentence routes the agent: garmin_get_profile returns the same zones together with profile settings, implying this tool is the narrower choice when only zones are needed. The guidance is clear but implicit - it never states an explicit 'use this when' / 'use profile when' condition, which is the only thing separating it from a 5.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint=false), and the description adds real context beyond them: units in milliseconds (RMSSD), example HRV status values, that overnight readings are averaged per 30 minutes, and the wake-up-date keying convention. Missing is what happens when no data exists for the date, but overall this is well above the annotation baseline.

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 dense sentence that front-loads the resource and then lists the returned fields; every clause carries information. It is slightly list-heavy but has no filler or redundancy.

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

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

With no output schema, the description carries the burden of explaining returns and does so thoroughly: fields, units, status vocabulary, and aggregation granularity. Only the empty/no-data case and the exact response shape are left unspecified.

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 date parameter already documents the wake-up-date meaning and today's-date default. The description reinforces the wake-up-date semantics ("like sleep") but adds no format, timezone, or range guidance beyond the schema, so the 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 resource and scope: "One night's heart-rate variability from Garmin", then enumerates the payload (last-night average, 5-min high, 7-day average, baseline range, status, 30-min readings). The phrase "one night's" implicitly separates it from the sibling garmin_get_hrv_summaries, but that sibling is never named, so differentiation is inferred rather than explicit.

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

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

Usage context is only implied: "Keyed by the wake-up date, like sleep" tells the agent how to select a day, and the singular "one night's" hints at the per-day use case. There is no explicit statement of when to choose this over garmin_get_hrv_summaries or garmin_get_day, and no mention of behavior for nights without a recording.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses units and derivation (milliseconds, RMSSD), the keying convention (wake-up date, which matters for interpreting night boundaries), the returned metric set including the `summary` aggregate, and a hard behavioral limit of 92 nights per call. This is exactly the kind of context 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?

Dense but front-loaded: purpose and returned fields come first, then keying/units, then defaults and limits, then the sibling routing. Every clause carries information and nothing is repeated verbatim from the 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 takes on the burden of describing returns and does so concretely, down to the status enum values and the `summary` aggregates. Together with defaults, the 92-night cap, and unit disclosure, an agent has everything needed to call and interpret 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 description coverage is 100%, and both parameters are documented there including their defaults and the 92-day cap, so the description's 'Defaults to the last 7 nights; at most 92 nights per call' largely restates the schema. The only added interpretive value is the wake-up-date framing, which concerns result semantics rather than the parameters themselves. 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?

The description states a specific verb and resource ('Overnight heart-rate variability per night over a date range') and enumerates what comes back (last-night average, 5-minute high, 7-day average, baseline range, HRV status). It explicitly distinguishes itself from the near-identical sibling garmin_get_hrv, so an agent can choose 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?

It gives a clear selection rule: use this for trends across nights, and use garmin_get_hrv for a single night with overnight readings. That is an explicit alternative with a condition. It stops short of exclusions against adjacent wellness tools (sleep, stress, body battery), so it is strong but not exhaustive.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely non-obvious behavior: data may be absent unless the user logs it, the default span is 7 days, and calls are capped at 31 days. Units (ml) are also disclosed, which structured fields do not convey. It does not describe the response shape (e.g., one entry per day, zero-filled vs omitted days), which is why it is 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?

Two dense sentences with zero filler: the first front-loads what the resource is and lists the payload fields, the second carries the caveats. 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 no output schema, the description compensates by naming the four returned metrics and their unit, plus data-availability and window limits, which is most of what an agent needs. The only shortfall is not stating the per-day granularity/shape of the response or how missing days appear.

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 both parameters carry their own date-format pattern and default rules. The description's 'defaults to the last 7 days; at most 31 days per call' restates what start_date and end_date already document, adding no new meaning about parameter interaction or time-zone handling 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?

Names a specific verb+resource ('Hydration per day over a date range') and enumerates exactly what is returned: intake, goal, estimated sweat loss, and activity intake in ml. That field list distinguishes it cleanly from siblings like garmin_get_steps or garmin_get_food_log 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?

Gives a clear precondition ('Only has data if the user logs hydration') and windowing rules (defaults to last 7 days, max 31 days per call), which tells the agent when the tool is worthwhile and how far back it may reach. It stops short of naming an alternative sibling when the user wants a different wellness metric, so it is clear context rather than explicit routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the important data-availability precondition (user must enable cycle tracking) and, since there is no output schema, the field inventory that tells the agent what a successful response contains.

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 sentences, front-loaded with the resource and its fields, followed by use case and the availability caveat. The field enumeration is dense but each item earns its place given the absence of an 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 one optional, fully documented parameter and no output schema, the description supplies the return-field inventory and the data-availability caveat an agent needs. Only the relationship to the closely named sibling garmin_get_menstrual_day is left unresolved.

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 single 'date' parameter is fully documented with format and default, so the baseline is 3. The phrase 'around a date' adds a small amount of meaning by implying the date is a center point rather than an exact-day filter, but no further syntax or behavior is clarified.

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 (menstrual cycle data from Garmin Connect cycle tracking) and enumerates the returned fields: day in cycle, phase, period length, fertile window, predicted cycle length, ovulation date, and cycle analysis. It does not explicitly contrast itself with the sibling garmin_get_menstrual_day, though 'around a date' hints at a broader window than a single-day lookup.

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 concrete use case ('relating training, HRV and resting heart rate to the cycle') and a genuine gating condition ('Only has data if the user tracks their cycle in Garmin Connect'), which prevents futile calls. It stops short of explicitly routing between this tool and garmin_get_menstrual_day.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds domain behavior instead: the field set returned, an extra conditional field during pregnancy tracking (weekly weight-gain range), and the empty-result condition when the user does not track cycles. It does not discuss return structure or error/empty payload shape, 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?

Two sentences, front-loaded with what is returned, then the conditional pregnancy extension and the data-availability caveat. The parenthetical sibling reference conveys a lot in few words; the only mild cost is a dense field enumeration, but 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?

There is no output schema, so the description carries the return-value burden and does so by listing the fields returned and the pregnancy-specific addition. Combined with the availability caveat, an agent knows enough to call it and interpret an empty result; only the payload structure/nesting is left unspecified.

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?

With one optional parameter at 100% schema description coverage, the schema already fully documents the date format and the "today in the user's time zone" default. The description adds no date semantics beyond that, so the 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 ("One day of menstrual cycle tracking") and enumerates exactly what the payload contains: flow, symptoms, moods, ovulation day, notes, plus that day's cycle summary. It also explicitly ties itself to sibling garmin_get_menstrual_cycle ("same fields as ..."), so an agent can distinguish the per-day read from the cycle-level read 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?

The single-day scope plus the reference to garmin_get_menstrual_cycle implies the selection rule (per-date detail vs. overall cycle), and the final sentence gives a clear precondition: data exists only if the user tracks their cycle in Garmin Connect. It stops short of an explicit "use X for Y" directive, so the choice is inferable 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 readOnlyHint and a closed domain, so safety is covered. The description adds value by listing the concrete settings returned (time zone, week start, training days, per-sport zones with max/resting/lactate-threshold HR), which frames what the call yields. It could still note whether zones are user-configured vs. auto-detected or stale.

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 payload description and ending with the usage rationale. The middle list is dense but every item is distinct information; no filler or repetition of the title.

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?

No output schema exists, so the description must describe return content, and it does so reasonably thoroughly for a zero-arg profile read. The remaining gap is sibling differentiation against garmin_get_heart_rate_zones, which an agent might otherwise call redundantly.

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. Baseline 4 applies; schema coverage is 100% and the empty object is self-explanatory.

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?

Opens with a specific verb+resource ('The user's Garmin settings and heart-rate zones') and enumerates the contents: time zone, first day of week, training/long-run days, per-sport HR zones. It stops short of distinguishing from the sibling garmin_get_heart_rate_zones, which plausibly overlaps on HR zones.

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 clear positive usage rule: 'Use it to interpret heart-rate data from the other tools.' That is real context an agent can act on. No exclusions or explicit alternatives (e.g. when to prefer garmin_get_heart_rate_zones) are given.

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

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

Annotations supply the read-only, non-open-world safety profile, and the description adds substantial context beyond that: it enumerates the returned fields (stages, score components, sleep need reasons, naps, HR, SpO2, stress) in detail. This is valuable because there is no output schema to describe the response.

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 resource and scope, followed by a dense but purposeful field inventory and one clarifying convention. It is a single long sentence, but each listed item earns its place because no output schema exists.

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

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

For a one-parameter read tool with annotations covering safety and no output schema, the description supplies the response contents needed to judge relevance. Only the relationship to the sibling summary tool is 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 description coverage is 100% and the schema already defines 'date' as the wake-up date with a default of today. The description restates the wake-up-date keying and the 'last night is today's date' convention, which reinforces but does not add meaning beyond the schema.

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

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

States a specific verb+resource: 'One night of sleep from Garmin' and enumerates exactly what is returned. The emphasis on 'one night' implicitly separates it from garmin_get_sleep_summaries, but it never names a 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?

Usage is implied by the single-night scope and the wake-up-date rule, which tells the agent which date to pass. There is no explicit when-to-use guidance, no stated alternative such as garmin_get_sleep_summaries for multi-night ranges, and no exclusions.

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 (readOnlyHint true, openWorldHint false), and the description adds genuinely non-obvious behavior: nights are keyed by wake-up date, the 7-night default, and Garmin's hard 31-night cap. It stops short of describing pagination or what happens if the range is exceeded, so it is strong but not exhaustive.

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 field inventory, then constraints, then the sibling pointer — no filler sentences. The metric list is dense but each item helps an agent judge fit, so it largely earns its space.

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 only two optional date parameters and no output schema, the description carries the full burden well: it enumerates return fields including the summary aggregates, states the defaults and hard limit, and clarifies date semantics. Nothing an agent needs to call this 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 baseline is 3, but the description adds interpretive value beyond the schema by explaining that the wake-up date is the key, which changes how start_date/end_date map to sleep nights. The 31-night cap is repeated from the schema, so it earns no extra credit there.

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 ('Sleep per night over a date range') and enumerates the returned metrics, so an agent knows exactly what data it gets. It also distinguishes itself from the sibling garmin_get_sleep by scope (multi-night trends vs one night in full detail).

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 frames the use case ('for trends'), names the alternative for a different need ('For one night in full detail use garmin_get_sleep'), and gives the operating envelope: defaults to the last 7 nights, at most 31 nights per call. When-to-use, when-not, and the alternative are all present.

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 and local-scope behavior, and the description adds the important data-availability caveat that readings exist only when Pulse Ox is enabled on the watch. It also discloses the exact result fields, which the annotations cannot convey.

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: what is returned first, then the parameter usage, then the recording caveat. No filler and nothing important buried at the end.

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 naming each field and its unit. Combined with the availability caveat and the parameter's use case, 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. The description still adds meaning beyond the schema by clarifying that include_samples yields hourly averages (not raw samples) bundled with altitude in meters, and by giving a motivating use case.

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 ('One day's blood oxygen (Pulse Ox)') and enumerates exactly which values come back: average, lowest, latest, sleep average and Garmin's 7-day average. It never explicitly contrasts with siblings, though the metric-specific naming makes it hard to confuse with garmin_get_hrv or garmin_get_stress.

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 concrete condition for the optional parameter ('Set include_samples for hourly averages with altitude..., e.g. for altitude acclimation') and a prerequisite ('SpO2 is only recorded when Pulse Ox is on'). It stops short of stating when to prefer this tool over per-metric siblings, but none of them cover SpO2.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: today's row is partial (data-completeness caveat), the default range, and a hard 28-day ceiling per call. It does not describe error conditions or what an empty range returns, which keeps it from a 5.

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

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

Three short sentences with zero filler, and the most important content (what it returns, plus the partial-today caveat and range limits) is front-loaded. Every clause carries information an agent can act on.

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 two-parameter read tool with full schema coverage and a safety-covering annotation set, the description supplies what the structured fields cannot: the return shape, the partial-today caveat, and the range ceiling. With no output schema present, a slightly richer note on return structure or empty results would make it 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 description coverage is 100% and both parameters carry detailed descriptions including defaults, time zone, and the 28-day cap, so the schema does the heavy lifting. The description's 'Defaults to the last 7 days; at most 28 days per call' largely restates the schema rather than adding new parameter meaning, which fits the baseline 3.

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 first sentence names a specific resource and granularity (steps per day over a date range) and even enumerates the returned fields (daily step goal, walking/running distance in km). It is unambiguously distinguishable from every sibling (hrv, sleep, body_battery, etc.). It stops short of naming a sibling it is not, so it lands at 4 rather than 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 context is only implicit: the resource name makes clear it is for step data, and 'Defaults to the last 7 days; at most 28 days per call' sets scoping constraints. There is no explicit when-to-use/when-not guidance and no routing to alternatives (e.g. garmin_get_days or garmin_get_daily_summaries for aggregate daily metrics), leaving the agent to infer overlap.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral detail beyond them — that today's row is partial, the default window, and the 28-day per-call ceiling. It doesn't mention pagination or rate limits, but for a read-only daily-series tool this is solid added context.

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 resource and its metric definitions, then the partial-day caveat, then the window limits. No filler or redundancy; every clause carries information an 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?

There is no output schema, but the description effectively documents the return shape (per-day average stress plus minutes in each of four bands) along with the partial-day caveat for today. Combined with fully documented date parameters, 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 description coverage is 100%, so both date parameters are already fully documented in the schema, including defaults and the time-zone note. The description restates the 7-day default and 28-day limit but adds no new syntax or format meaning beyond the schema, 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 ('All-day stress per day over a date range') and immediately defines the returned metrics with their value ranges (average 0–100, minutes in rest/low/medium/high buckets). This is clearly distinguishable from siblings like garmin_get_hrv, garmin_get_sleep or garmin_get_body_battery 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?

Gives concrete operational context: defaults to the last 7 days and a hard cap of 28 days per call, which tells an agent how to scope requests. It does not name an alternative tool or state when to prefer a different stress/wellness endpoint, so it stops short of full when/when-not 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?

Beyond readOnlyHint/openWorldHint, the description discloses the return shape in detail: one row per day with weight plus smart-scale metrics, a `summary` block with average/min/max and first-to-last change, and `previous_weigh_in` as the last entry before the range. It also states the default window and the 366-day cap, which are behavioral limits not present in the annotations.

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

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

Three dense clauses, front-loaded with the resource and scope, then response shape, then defaults and limits. No filler sentences and no repetition of the tool name or title.

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 describing rows, summary fields, and the prior weigh-in. Annotations cover the safety profile, and the date constraints are stated, so an agent has everything needed 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?

Schema coverage is 100% and both date parameters already document format, defaults, and the 366-day cap, so the schema does the heavy lifting. The description restates the range concept and limits but adds no date semantics beyond what the schema provides, 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?

A concrete verb (weigh-ins) plus resource (weight/body composition over a date range) with a precise description of what a row contains. It is clearly distinct from garmin_get_weight_goals in substance, though it never names that sibling or any other to disambiguate 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?

Usage context is implied through the default window ('last 7 days') and the per-call cap ('at most 366 days'), which tells an agent how calls behave. There is no explicit when-to-use versus alternatives guidance and no statement about when this tool is inappropriate (e.g., goals or trend summaries are handled elsewhere).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds the reporting scope (goals in effect for a window) and the 366-day cap, and because there is no output schema it also sketches the returned fields and the kg unit. Some of the default-range text duplicates the parameter descriptions, which keeps it from a 5.

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

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

Two short sentences with zero filler: what it returns, the sibling to avoid confusing it with, and the range limits — all 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?

For a two-optional-parameter read tool with no output schema, the description covers purpose, unit, default window, and the span cap, which is nearly everything needed to call it. It could say what happens when no goal is in effect in the window, a minor gap.

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

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

Schema description coverage is 100% and both date parameters already document their formats and defaults, so the baseline is 3. The description adds only the kg unit for the returned target weight, not any new semantics about start_date/end_date.

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 ('weight goals in effect during a date range') and names the payload fields returned (target weight in kg, start/end date). It also explicitly distinguishes itself from garmin_get_weight, so an agent can tell goals apart from weigh-ins 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?

Names the sibling to use for a different need ('For weigh-ins use garmin_get_weight') and gives the default window plus the per-call span cap, which is exactly the context needed to choose this tool and size the query correctly.

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 a safe read (readOnlyHint=true, openWorldHint=false), so the bar is lower, and the description still adds real operational context: a 7-day default window and a hard 92-day cap per call. It also enumerates the returned metric set (HR, stress, respiration, SpO2, HRV with RMSSD/SDRR in ms, time in zones) and notes metrics appear only 'when recorded', which sets expectations about sparse results. No pagination or result-size behavior is mentioned.

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 dense sentence front-loads the resource and its scope, then the disambiguation, then the return fields, ending with the operational limits. Nothing is redundant with the title, and the em-dash aside keeps the sibling differentiation from becoming a second sentence of overhead.

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?

There is no output schema, so the description correctly carries the return-shape burden by listing which metrics come back and noting that they appear only when recorded. Combined with the default and maximum range, an agent has enough to call it and interpret results. Minor gaps remain around ordering, empty results, and whether zones are included per session or aggregated.

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 both parameters already document format, defaults, and the 92-day maximum. The description restates the same default window and cap without adding new meaning such as time-zone handling nuance or start/end conflict resolution. Baseline 3 is appropriate 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?

States a specific verb and resource ('Wellness activities over a date range') and immediately scopes it with concrete examples ('breathwork or Health Snapshot recorded on the watch'). It explicitly differentiates itself from the nearest sibling by naming garmin_search_activities as the tool for 'regular activities', so an agent can route correctly 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 a clear selection rule: use this for watch-recorded wellness sessions, use garmin_search_activities for regular activities. The boundary is stated positively and negatively enough to disambiguate. It stops short of addressing overlap with metric-specific siblings (garmin_get_hrv, garmin_get_stress, garmin_get_spo2), which also surface some of the same fields, so an agent must still infer when a single-metric tool is preferable.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds real value on top with the 7-day default window, newest-first ordering, the caveat that `summary` covers full weeks only, and the 100-activity cap per weekly call. It stops short of describing paging behavior (next_offset) or what happens when the range is empty, which keeps it from a 5.

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

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

Front-loaded with the core action and return shape, then the sibling routing, then the weekly-mode variant — a logical order with no filler sentences. It is a dense single paragraph, though, and the weekly-totals clause is packed tightly enough to require a second read.

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 fields returned in both normal and weekly modes. Combined with defaults, ordering, and sibling routing, 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 description coverage is 100%, so every parameter is already documented, including defaults, the date pattern, and the note that limit/offset don't apply with group_by. The description largely restates those defaults and adds only the 'when long enough' qualifier for splits, so 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 and resource ('List Garmin activities in a date range, newest first') and enumerates the returned fields, so an agent knows exactly what it gets. It also implicitly separates itself from garmin_get_activity by naming that tool as the follow-up for zones, dynamics, intervals and RPE.

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 the returned id with garmin_get_activity for deeper per-activity data, and use group_by "week" when the goal is volume over a training block. Both the when-to-use and the alternative are stated rather than inferred.

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