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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: fetches in parallel, returns compact detail, and mirrors get_activity's field set — all useful for an agent reasoning about cost and output shape.

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

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

Two tight sentences: the capability and its output shape come first, then the usage examples and the ID-sourcing hint. No filler, no 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?

With no output schema, the description wisely anchors the return value to get_activity and labels it 'compact', which is enough for an agent to set expectations. Minor gaps remain: result ordering relative to the input IDs and behavior on an invalid or inaccessible ID are 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%, so the min/max item bounds and the numeric-ID pattern are already documented. The description still adds value by telling the agent where the IDs come from ('get the IDs from search_activities'), which is not derivable 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 a specific verb and resource ('side-by-side compact detail for 2-5 activities') and explicitly ties the output shape to a known sibling ('same fields as get_activity'), which lets an agent distinguish it from get_activity and summarize_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 concrete triggering examples ('compare my last two long runs', 'how did this race compare with last year's') and routes the agent to search_activities as the ID source. It stops short of an explicit exclusion such as 'for a single activity use get_activity', but the 2-5 range makes the boundary largely self-evident.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: detail='full' returns Garmin's raw record with 200+ fields, which warns the agent about payload size and shape — something no annotation conveys.

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 purpose, then the field inventory, then the sibling routing, then the full-mode caveat — a sensible order with no filler sentences. The field enumeration is long but each item is a real capability; slight density cost only.

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 burden of describing returns — and it does, listing the metric families returned and delimiting the split-summary granularity. For a 2-parameter read tool with full annotation coverage, nothing an agent needs in order to call and interpret it 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 baseline is 3; the description goes slightly beyond it by quantifying the 'full' mode (200+ fields, 'Garmin's raw record') where the schema only says 'raw payload'. It does not, however, explain what is dropped in compact mode beyond 'meaningful fields'.

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

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

Names a specific verb+resource ('One activity in detail') and then enumerates exactly what is returned: distance, times, pace, HR, cadence, running dynamics, power, training effect/load, temperature, RPE/feel, split summaries. It also explicitly separates itself from get_activity_analysis and from the raw 'full' variant, so an agent can distinguish it from siblings 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 a clear exclusion with the alternative named: split summaries here are warm-up/active/cool-down totals, 'not per-km; use get_activity_analysis for km/mile splits and laps'. It also routes to detail='full' for raw payloads. It does not spell out the typical search_activities -> get_activity flow in the description (that lives only in the schema parameter text), which keeps it short of 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 declare this a read-only, idempotent, non-destructive operation, so the description is free to spend its words on behavior that matters: timer time excludes pauses, the final partial split is labelled with its distance, best efforts only appear for distances the activity is long enough for, and manual/GPX/TCX entries return a short 'unavailable' note. That last point is a valuable pre-call warning about a silent failure mode an agent would otherwise misread as empty data.

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 front-loaded with the one-line summary and the use-case list, then organized as a compact glossary of the five sections, so it is scannable rather than rambling. The section glossary runs long, but each entry carries distinct information an agent cannot get from the schema alone.

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 describing the row shape of splits and the contents of laps, best_efforts, hr_zones and drift. Combined with the ID source and the unavailable-note caveat, an agent has everything needed to call this correctly 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 schema already documents unit, include and activity_id; the description nonetheless explains what each includable section actually contains (per-km rows with pace, cumulative time, avg/max HR, cadence, power, elevation), which the schema's terse 'Sections to return' does not. It does not restate the default include set or the unit default, leaving that to the schema.

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

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

The description names a specific verb-and-resource pair ('per-km or per-mile splits, laps, best efforts, HR zones, drift for ONE recorded activity') and scopes it to a single activity, which cleanly separates it from summarize_activities, compare_activities and get_activity. It also states the data provenance ('computed from Garmin's original FIT file'), so the agent knows this is derived analysis rather than a raw record fetch.

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?

Concrete user phrasings ('did I negative split', 'how long in zone 2', 'did my HR drift') give an agent strong signal for when to reach for it, and the prerequisite is spelled out: 'Get the ID from search_activities.' It stops short of naming the sibling to use instead for cross-activity or whole-activity comparisons, so routing in ambiguous cases still requires inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuine behavioral context beyond that: the empty-result meaning and the degenerate case where only a workoutPhrase exists (e.g. EASY_WEEK_LOAD_BASE). It does not mention auth or rate limits, but for a read-only lookup those are low-value omissions.

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 purpose, then interpretation details, then the sibling routing — a sensible order. The middle clause is dense with units and field names (metres for DISTANCE, m/s targets), but those details genuinely help interpret the payload and there is no filler.

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

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

No output schema exists, so the description must carry the return-value burden, and it does: it names the fields, their units, and the edge cases. Combined with the annotations, an agent has everything needed to decide to call it and to read the result.

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

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

The single parameter is fully documented in the schema (100% coverage, pattern and provenance), so the burden is minimal. The description restates the provenance ('Get the ID from search_activities'), which duplicates rather than extends the schema, but with only one param the semantic gap is negligible.

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: 'the planned workout linked to one recorded activity, if any', and enumerates what comes back (workoutName, sport, steps, targets). It also explicitly marks the boundary against get_activity_analysis, so an agent can distinguish it from 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?

Gives an explicit routing rule ('This is the plan; for how each rep actually went use get_activity_analysis (laps)') and a prerequisite ('Get the ID from search_activities'). It also defines the null case ('an empty result means no workout was linked'), removing ambiguity about what a blank response means.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real context: readings are in local time, roughly six per day at named checkpoints, and events (sleep, activities, stress) are attached. It does not mention pagination or truncation behavior beyond the 92-day cap, 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?

The core purpose and row shape are front-loaded, and the routing sentence is placed before the parameter guidance. It is dense with semicolons and repeats the detail='full' behavior already in the schema, which costs a little tightness.

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: row contents, units/scale (0-100), time zone, and the compact-vs-full distinction. Nothing an agent needs in order 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; the description still adds selection guidance (period preferred over dates), concrete period examples, and the 92-day limit. The detail='full' explanation largely restates the schema enum, so the added value is modest rather than substantial.

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

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

States a specific verb+resource ('Daily Body Battery... over a range, one compact row per day') and enumerates the returned fields (charged, drained, highest, lowest, events, end-of-day feedback). It also names the two sibling tools it is not, so an agent can distinguish 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 explicit routing rules: 'For today's state use get_readiness; for trends over weeks or months use summarize_wellness.' It also states the selection rule between the period enum and start_date/end_date, and the 92-day per-call cap.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely new behavioral context not present in the schema or annotations: the return shape is 'one flat row per day', which tells the agent the output is a per-day table rather than nested records – important given there is no output schema. It does not mention volume/pagination behavior for long ranges.

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 filler. The payload inventory is front-loaded so the agent immediately sees scope, and the second sentence is a single actionable routing rule.

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 specifying the row shape and metric list, and the schema fully documents parameter behavior. It is nearly complete for a read-only roll-up tool; the only missing piece is any hint about result size for wide date ranges or how metrics absent for a day are represented.

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%, with detail, period, start_date and end_date all documented including the 92-day span limit and the period-vs-dates exclusivity. The description adds no meaning beyond that – it never mentions how the detail or period parameters change the result. Baseline 3 applies because the schema does all 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?

The description names the resource (one row per day of daily wellness summaries) and enumerates the exact metrics returned (steps, distance, floors, calories, HR, stress, Body Battery, SpO2, hydration), so an agent knows precisely what it gets. The verb is implicit rather than stated, and it does not disambiguate against per-metric siblings like get_steps or get_heart_rate, which keeps it from a 5.

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

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

It gives an explicit routing rule: for trends over more than a few weeks, use summarize_wellness instead. That is clear when-to-use-an-alternative guidance, but it only covers one alternative and does not say when a per-metric sibling (get_steps, get_stress, get_body_battery) would be preferable to this multi-metric roll-up.

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), and the description adds real behavioral context: per-component stale flags, BMI sourced from the last weight entry and therefore 'often old', and an instruction to round the decimal. It does not discuss data availability or failure modes when no fitness age exists.

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 resource and its fields, then caveats. The middle sentence listing components is long and run-on, and the numOfWeeksForIm field name is opaque, but overall little waste.

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 only one parameter, so the description must carry the return-value burden — and it does, naming every field, its units, its staleness signal, and how to format the fitnessAge value. Nothing essential for a correct 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 coverage is 100% and the enum/pattern are already documented, so the baseline is 3. The description adds practical meaning by explaining why 'today' is normally the right value, which the schema alone does not convey.

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 ('Garmin's fitness age as of a date') and enumerates the exact payload fields (chronologicalAge, fitnessAge, previousFitnessAge, components). It also preempts the most likely confusion by declaring 'This is not VO2 max', which separates it from nearby wellness siblings.

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 guidance that date='today' is usually sufficient because the metric changes slowly, which steers the agent away from over-querying history. It stops short of naming an alternative tool or stating when not to call it, but no sibling clearly overlaps.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful behavioral detail: local-time reporting, ~2-minute reading granularity when a window is supplied, and a size warning for full raw payloads.

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

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

The description is three front-loaded sentences with no wasted wording. It states the main output first, then optional window behavior, then the full-detail warning.

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 read-only daily heart-rate tool with four parameters and no output schema, the description is complete enough. It lists the main return values and explains the optional high-resolution and raw-payload modes.

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 schema already documents parameter formats and defaults. The description still adds meaning by explaining that from/to produces every ~2-minute reading in that window and that detail='full' returns Garmin's raw payload, which is larger.

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 and scope: heart rate for one day, with the exact metrics returned (resting, min, max, 7-day average, hourly min/avg/max). This is clearly distinguishable from sibling wellness tools such as get_hrv or 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?

It gives clear usage context for the optional from/to window, including examples like overnight or around a workout, and warns that detail='full' is large. It does not explicitly compare against sibling alternatives, keeping it at 4 rather than 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?

The annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds that the response contains both a summary and per-reading values, which is useful since there's no output schema, but it says nothing about reading granularity, units, empty-night behavior, or result size.

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, zero filler. The resource and return shape come first, and the disambiguation against the sibling follows immediately.

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 single-parameter read tool with full annotation coverage and no output schema, the description does the essential job: it says what comes back and how it differs from the aggregate sibling. Only minor gaps remain, such as what a 'reading' represents or what happens when no data exists for the night.

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 fully documented in the schema, including the 'today'/'yesterday' tokens and time-zone resolution. The description's 'one night' phrasing reinforces that this is a per-night lookup but adds no format detail 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?

The description names the resource precisely ('HRV summary plus individual readings for one night') and distinguishes it from the sibling get_hrv_summaries by saying the readings themselves are what differ. It lacks an explicit verb like 'retrieve', but the scope is unambiguous.

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

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

It names the alternative (get_hrv_summaries) and states the exact condition that selects this tool instead: only when the individual readings matter. This is a textbook when-to-use/when-not-to-use statement.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that values are daily and that a baseline band and status classification come back, but says nothing about timezone resolution, gaps in data, or the 92-day span limit the schema mentions.

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?

One compact sentence that front-loads the resource and granularity before enumerating returned metrics. The colon-list style is dense and readable, though the fragment form leaves the action verb implicit.

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 usefully enumerates the returned metrics (overnight average, 5-minute high, 7-day average, baseline band, status), which is the main thing an agent needs. It stops short of noting result ordering or handling of missing days, but for a simple three-parameter read tool this is close to sufficient.

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%, including the enum meanings, timezone resolution, Monday week start, inclusive dates and 92-day max span. The description adds no parameter detail beyond 'over a range', so it neither compensates nor needs to; 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 (heart rate variability) and scope (daily values over a range), plus the exact metrics returned: overnight average, 5-minute high, 7-day average, baseline band, status. It does not explain how this differs from the sibling get_hrv, so an agent must infer that this is the aggregated daily view.

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: 'over a range' signals this tool is for multi-day queries, but there is no explicit when-to-use guidance, no distinction from get_hrv or get_daily_summaries, and no mention of the period-vs-start_date/end_date choice, which the schema alone carries.

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

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

Adds substantial context beyond annotations: the pass-through nature of the data ('as Garmin returns it'), the high likelihood of empty results and how to interpret them, and the 92-day cap. Annotations already cover read-only/idempotent safety, so this is additive. It does not describe response shape or error behavior.

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

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

Front-loads what the tool returns, then the empty-result caveat, then the range mechanics. Efficient, though the empty-result explanation takes two clauses that could be trimmed slightly.

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 3-param read tool with no output schema, the description covers interpretation caveats and range mechanics well. Minor gap: no note on how empty days appear in the returned series (omitted vs. zero-value).

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 baseline is 3. The description adds the mutual-exclusivity pattern (period vs. start_date/end_date), the 92-day cap, and example period values, which is genuinely useful beyond the schema's own notes.

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: 'Water intake the user logged in Garmin Connect, day by day over a range, as Garmin returns it.' It also distinguishes itself from get_daily_summaries, which is named as an alternative carrier of hydration_ml.

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?

Explains the key interpretation caveat (usually empty; empty means nothing was logged, not zero intake) and names an alternative source (get_daily_summaries hydration_ml). It also explains how to specify the range. It lacks an explicit 'prefer X when' routing sentence, but the alternative mention gives clear context.

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

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

Goes beyond the read-only/idempotent annotations by disclosing the return structure (summary and dayView) and the important emptiness condition. It does not describe error behavior for dates without data, but the core behavioral picture is clear.

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?

Single dense paragraph that front-loads what is returned and then the date constraint. A clause duplicating the schema's date formats is mild waste but the rest 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 does the necessary work of explaining the two-part return (summary, dayView) and when it will be empty. For a single-parameter read tool this is sufficient to call 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 the schema already documents YYYY-MM-DD plus 'today'/'yesterday' with timezone resolution, so the description's restatement of the accepted formats adds no new meaning. The only added value is the one-call-per-date instruction.

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 resource (menstrual cycle) and scope (one date), and the title confirms the granularity. It is clearly distinct from every sibling, none of which touch cycle data, though it does not explicitly say so.

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?

States the key constraint 'call once per date', which tells the agent this is not a range query, and notes the data is empty unless the user tracks cycles in Garmin Connect. It does not point to any alternative for multi-day or historical ranges, so the exclusion side is only implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful return-content context, but does not disclose missing-data behavior, units, rate limits, or other operational details beyond 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?

The description is a single tight sentence that front-loads the scope and summarizes the returned data without waste. Every phrase contributes to understanding the tool.

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 one-day read tool with rich annotations and a fully documented single parameter, the description is largely complete because it states the returned categories. A minor gap is that it does not mention behavior when no nutrition data exists for the date.

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 fully documented with format and timezone resolution. The description does not add any parameter meaning beyond the schema, so the baseline of 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?

The description names the resource (food log/nutrition) and scope (one day), and lists the returned content categories (goals, calories/nutrients, per-meal breakdown). It lacks an explicit retrieval verb and sibling differentiation, but no sibling is nutrition-focused, so the purpose is clear.

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

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

Usage is implied by the name and description as a daily nutrition lookup, but there is no explicit when-to-use, when-not-to-use, or alternative guidance. It is minimally adequate for a simple getter.

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?

The annotations already establish that this is a read-only, idempotent, non-destructive operation, so the safety profile is fully covered. The description adds only the domain content of the payload, with no mention of authentication, account scoping, caching, or what happens when a profile has not been configured.

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, front-loaded with what is returned and followed by the usage hint, with no filler. The 'etc.' in the parenthetical slightly weakens the enumeration, but the text is efficient overall.

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

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

With no output schema, the description carries the burden of describing return values, and it only partially does so via an open-ended list ending in 'etc.' For a zero-argument getter that is arguably sufficient, but the agent cannot fully anticipate the response shape, and no output schema exists to fill that 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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool applies. Nothing in the description misleads about inputs.

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 (user profile settings and heart-rate zones) and enumerates representative contents such as units, measurement system and birth year, so the agent knows exactly what it retrieves. It does not need to distinguish itself from siblings like get_hrv or get_sleep, which are clearly different resources, but it also makes no explicit contrast.

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 clause 'Useful context before interpreting training data' gives an implied when-to-use signal, which is more than nothing. However, it offers no exclusions, no ordering relative to sibling calls, and no statement about whether this must be fetched before other tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety bar is low. The description goes further by disclosing the shape of the payload (one compact object), the comparison windows used (previous 7 days; 28-day weekly average for load; 3 days of activities), and the wake-up-date filing convention — all behaviors an agent could not infer from 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?

Front-loaded with the use case, then the payload inventory, then the date caveat — a sensible ordering with no filler sentences. The middle enumeration is dense but every clause carries distinct information; it is long only because the return payload is broad.

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 characterize return values, and it does so field-group by field-group with their comparison baselines. Combined with the date semantics, an agent has everything needed to call this correctly 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?

With a single parameter at 100% schema coverage, the baseline is 3, but the description adds real meaning the schema cannot: sleep is keyed to the wake-up date, so 'today' retrieves last night. That resolves a genuinely ambiguous default, though it does not discuss time-zone edge cases beyond what the schema notes.

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 gives a concrete composite resource and enumerates its contents (sleep score/stages/HR/respiration, HRV vs baseline, resting HR, Body Battery, training load, recent activities). It also anchors the tool to the user questions it answers, which cleanly separates it from single-metric siblings like get_hrv, get_sleep, and get_body_battery.

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?

"Best first call for ..." is an explicit routing instruction with several example phrasings, plus a concrete date-selection rule ("use 'today' for last night"). It stops short of naming when to prefer the narrower sibling tools or when not to use this one, which keeps it just below 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context about the detail modes (compact = readable units matching the summaries shape; full = raw Garmin payload), but says nothing about behavior for missing nights, partial data, or unresolved dates.

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, front-loaded with the resource and scope, and the second sentence carries the actionable detail flag. It is slightly cryptic because 'same compact shape as get_sleep_summaries' only pays off if the agent knows that sibling's output.

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

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

For a simple two-parameter read tool with full schema coverage, complete annotations, and no output schema, the description covers scope, the key modifier, and the relationship to the summaries sibling. The main omission is what the response looks like concretely and how empty or partial nights surface.

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 parameters are already documented, including the anyOf pattern for date and the compact/full enum. The description reinforces the detail semantics ('complete record') without adding syntax, format, or edge-case behavior beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific resource and scope: one night's sleep, explicitly tied to the 'compact shape' used by get_sleep_summaries, which distinguishes it from the multi-night summary sibling. The verb is implied by the tool name rather than stated, and 'same compact shape as get_sleep_summaries' assumes the agent already knows that sibling.

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

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

It gives one clear usage rule: use detail='full' for Garmin's complete record. It also gestures at the sibling relationship via get_sleep_summaries, but never states the actual decision boundary (single night here vs date range there) or what to do when no sleep was recorded.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds behavior the annotations cannot: the row-per-night grain, the wake-date keying convention, local-time boundaries, the 92-day cap, and that detail='full' returns Garmin's raw records.

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 sibling routing, then the call mechanics — a sensible information hierarchy for a dense definition. It is a long semicolon-chained sentence, but nearly every clause carries field or routing information rather than filler.

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

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

There is no output schema, so the description carries the return-value burden — and it does so by naming the fields and units an agent needs to reason over results. Combined with the date-window limits and the detail toggle, an agent has everything required 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%, so the baseline is 3, but the description adds interpretive meaning: dates are keyed to the day the user woke up (clarifying how the range maps to rows) and it restates the period-vs-dates choice with concrete period names. The distinction between compact and full payloads is reinforced rather than merely repeated.

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 resource (night-by-night sleep over a range) with an exact grain: one compact row per night keyed to the wake-up date. It enumerates the returned fields (duration, stages, score, HR/stress/respiration, SpO2, sleep need vs baseline) and explicitly differentiates itself from get_sleep, get_readiness and summarize_wellness.

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

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

Gives explicit when-to-use routing: 'For last night alone use get_readiness or get_sleep; for trends over weeks or months use summarize_wellness.' It also states the operational rule — up to 92 days per call, pass a period or start_date/end_date — so an agent knows both scope and the alternative path.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds real context beyond that by disclosing the shape of the payload and what detail='full' unlocks (every reading plus altitude data), which matters since there is no output schema.

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

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

Two compact sentences, zero filler, with the metric and scope front-loaded and the detail-mode caveat immediately after.

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

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

With no output schema, the description carries the burden of describing return values and does so thoroughly, including detail mode. Only minor gaps remain, such as units and how the 7-day average behaves for a single-day request.

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 both parameters are already documented, giving a baseline of 3. The description does add meaning for detail='full' beyond the schema's terse 'Garmin's raw payload', but says nothing extra about the date parameter's accepted formats or time-zone resolution.

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 metric and scope ('SpO2 for one day') and enumerates the exact aggregates returned (average, lowest, sleep average, 7-day average, hourly averages). An agent can tell what it retrieves, though it never contrasts itself with overlapping siblings like get_sleep or get_daily_summaries.

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 by the metric name and the 'one day' scope; there is no explicit when-to-use versus alternatives such as get_sleep_summaries or get_daily_summaries, and no stated preconditions or date-range limits.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful behavioral detail: results are one row per day 'as Garmin returns it' (no aggregation or filling), and the 92-day span ceiling constrains how calls must be batched. Missing only whether empty days are omitted or error behavior beyond the cap.

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 return shape, then sibling disambiguation, then the span/parameter constraint. No filler or repeated schema text, and each clause carries new routing or behavioral 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 no output schema, the description supplies the return fields itself, and for a 3-parameter read-only metrics tool that plus the span limit and sibling routing is 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%, and the enum already lists the accepted period values, so the description's example values (last_7_days, last_30_days, this_month) are largely redundant. It reinforces the period-versus-dates mutual exclusivity and the 92-day cap that already appear in the schema, but adds no new syntax or semantics. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('day-by-day steps over a range') and immediately enumerates the returned columns (calendarDate, totalSteps, totalDistance, stepGoal), so the agent knows exactly what it gets. It explicitly names the two nearest siblings, get_daily_summaries and summarize_wellness, and the condition that separates them.

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

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

Gives explicit routing: use get_daily_summaries if you also need floors, calories, HR or stress; use summarize_wellness for weekly/monthly averages over longer spans. It also states the operating limit (max 92 days per call) and the two ways to specify the window (period vs start_date/end_date).

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 safety (readOnly, idempotent, non-destructive), so the description's added value is in return behavior: one row per day, overallStressLevel on Garmin's 0-100 scale, and the four duration fields measured in seconds. The 92-day cap and period-vs-date-range behavior are also disclosed. It stops short of describing ordering, empty-day handling, or missing-data behavior.

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

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

Front-loaded with the core purpose and return shape, then alternatives, then constraints — a sensible ordering. The field enumeration is a long run-on clause, but each element (units, scale, cap) carries actionable information rather than filler.

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

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

For a read-only, three-parameter tool with no output schema, the description supplies the return shape, units, value scale, range limits, and sibling routing. An agent has everything needed to invoke it correctly on the first attempt.

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

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

Schema description coverage is 100%, and the schema already documents the period enum semantics, the YYYY-MM-DD format, the default of end_date to start_date, and the 92-day max span. The description mostly restates this with example values and the period/start_date-end_date exclusivity, adding little meaning beyond the structured fields.

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

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

States a specific resource and granularity: 'day-by-day all-day stress over a range, one row per day.' It enumerates the returned fields and explicitly differentiates itself from summarize_wellness (trends/weekday) and get_sleep_summaries (stress during sleep), so an agent can pick it 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 explicit routing rules: use summarize_wellness for weeks/months or weekday analysis, and avg_stress in get_sleep_summaries for sleep stress. It also states the operational constraint (up to 92 days per call) and the two mutually exclusive ways to specify a range with concrete period examples.

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 it as a safe idempotent read. The description adds material behavior: raw gram units, the 92-day-per-call ceiling, the likelihood of empty results, and the previousDateWeight fallback that must be date-checked before being treated as current. That is precisely the kind of trap 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?

Front-loaded with what is returned and the unit convention, then the emptiness caveat, then the range mechanics. Dense but each sentence carries weight; the period examples are slightly redundant given the enum is fully enumerated in 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?

No output schema exists, so the description must explain the return shape, and it does: measurements as Garmin sends them, grams, plus the previousDateWeight edge case. Combined with the range limits, 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% and already documents the period enum, the 92-day max span, and 'use instead of start_date/end_date.' The description's period examples and 92-day note largely restate the schema, adding only the practical instruction to split long ranges into multiple calls.

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 exactly what is returned (weight and body composition measurements over a range), the data source (Garmin smart scale or manual Garmin Connect entries), and the unit convention (grams, 74000 = 74 kg). An agent can distinguish this from get_weight_goals or wellness siblings without opening the schema.

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

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

Gives explicit selection rules between period and start_date/end_date, tells the agent to make several calls for histories beyond 92 days, and warns that results are often empty. It does not name a sibling tool as an alternative, 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?

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds real value beyond them: the common empty {} return, the raw passthrough format, and the 92-day span cap. It does not describe pagination or error behavior, but for a read-only lookup that is a minor gap.

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

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

Three dense sentences, front-loaded with the resource and return shape, then the empty case, then the range constraint. The opening clause is slightly convoluted but nothing 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?

With no output schema, the description carries the burden of explaining the return value, and it does so by naming the goal range and the empty-object case. The 92-day limit and period/date alternatives are covered. Only error and edge-case behavior 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 coverage is 100%, so the baseline is 3. The description still adds the 92-day maximum span and concrete period examples (last_7_days, last_30_days, this_month), which reinforce the schema's own guidance rather than merely repeating it.

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

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

States a specific resource (the weight goal in effect over a range) plus what is returned (goal range, as Garmin sends it), and explicitly distinguishes itself from the sibling get_weight by framing the pairing. An agent can tell it apart from get_weight 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 clear context: use it alongside get_weight to track progress, and expect an empty object when no goal exists. It also explains the period-vs-start_date/end_date choice. It stops short of explicit when-not-to-use guidance, so it is not 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 (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add operational context — and it does: 'Often empty' sets return-volume expectations, 'returned as Garmin sends them' discloses raw passthrough with no normalization, and the 92-day cap constrains request size. It stops short of describing result shape or ordering.

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, zero filler, and the highest-value facts come first: what it is, how it differs from workouts, then the emptiness caveat and alternatives, then the range constraint. 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?

No output schema exists, so the description carries the return-value burden; 'returned as Garmin sends them' plus 'Often empty' is a reasonable disclosure for a passthrough read tool, and the sibling routing covers the main decision. A brief note on what a non-empty record contains 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 description coverage is 100%, and the schema already documents the enum values, the YYYY-MM-DD pattern, inclusive semantics, and the 92-day max span. The description's 'Up to 92 days per call: pass a period ... or start_date/end_date' restates the mutual exclusivity the schema already implies. Baseline 3 for a fully documented schema with no added format or precedence detail.

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

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

States a specific verb+resource (wellness activity summaries over a range) and immediately scopes it: 'all-day movement records kept apart from recorded workouts.' That contrast is exactly what an agent needs to distinguish this from the workout-oriented siblings, and it is reinforced by naming those siblings later.

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

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

Explicit routing in both directions: 'for daily movement use get_daily_summaries or get_steps, and for workouts search_activities or summarize_activities.' It also warns 'Often empty,' which is real selection guidance (an agent should prefer alternatives when it needs reliable daily data).

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds what those cannot: the default response shape, that 'full' is expensive so limit should be small, and that sport-specific extras are absent. It does not cover paging behaviour or what happens at limit boundaries, but that is minor given the annotation coverage.

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 the sibling routing, then implementation detail, then exclusions — a sensible order with no filler sentences. The compact-field enumeration is long but each field name is the actual answer to 'is my data here?', so it 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?

For a 20-parameter tool with no output schema, the description does the important work: it explains the return shape, warns about size, and points at the cheaper alternative for aggregation. What remains unspecified is largely covered by the rich schema descriptions.

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 90%, so most parameters are self-documenting. The description still carries the undocumented 'detail' parameter, enumerating exactly which fields compact returns and when to escalate to 'full', which is meaning the schema does not provide. Filters themselves are only listed by category rather than explained.

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

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

The opening sentence gives a specific verb and resource ('List individual recorded activities') plus the concrete downstream value (activity_id for get_activity / get_activity_analysis) and the filter families available. It explicitly distinguishes itself from summarize_activities, so an agent can choose between 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?

It states when NOT to use it ('for totals, averages or trends over weeks/months, use summarize_activities instead'), gives a graduated rule for detail='full' ('only when a field you need is missing, and with a small limit'), and closes off unsupported data (golf scorecards, shot data, dive logs). This is explicit routing guidance with alternatives named.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered; the description adds real operational context by disclosing that it fetches every matching activity and returns only aggregates, plus a hard 366-day range limit. It doesn't mention cost/latency of the full scan or what happens with zero matches, which would have pushed it higher.

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 qualifying purpose and then the return payload; the parenthetical examples and zone 2/80-20 hint all carry routing value. The dense metric enumeration is long but each item answers 'will this tool give me X', 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?

With 16 parameters and no output schema, the description compensates by enumerating the returned aggregate fields (count, distance in km and mi, moving time, elevation, weighted pace, HR zones), which is exactly the missing information. Combined with the 366-day bound and grouping semantics, an agent has enough to call and interpret it correctly.

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

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

Schema coverage is 94%, so the schema already explains nearly every parameter and the baseline applies. The description only implicitly clarifies that results are grouped per period and type, without touching the group_by enum values (week/month/weekday/total) or defaults, so it adds little beyond structured fields.

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

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

States a specific verb and resource ("activity totals and trends") and anchors it with concrete example questions ('how far did I run each month', 'has my pace improved'), which separates it from list-style siblings like search_activities. The explicit output enumeration (aggregates per period and type) makes the aggregation purpose 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?

The example questions give strong routing signals for when to pick this over raw-list tools, and "Best tool for..." frames the preferred choice for trend questions. It never explicitly names an alternative (e.g. search_activities or get_activity) or states when NOT to use it, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond that: it discloses that only per-period averages are returned, enumerates which metrics, notes min-max ranges and day counts where data is missing, caps range at 366 days, and says aggregation happens server-side. That is exactly the context an agent needs to set expectations and avoid misinterpreting output.

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 'best tool for X' claim and example queries, then the return contract, then the special group_by case, then constraints. Dense but every clause carries information; the parenthetical example queries make it longer than strictly minimal but they earn their place by disambiguating use cases.

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 full burden of describing return values — and it does, listing the metric set, averaging semantics, ranges, and missing-data day counts. For a 5-parameter aggregation tool with no required params, nothing an agent needs in order to call it 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 coverage is 80% so the baseline is 3, but the description adds real meaning: it explains what group_by='weekday' is for, enforces the 366-day range limit, and clarifies the period-vs-start_date/end_date relationship. It does not explain the 'total' group_by option or the include-array tradeoff beyond what the schema 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 verb+resource (summarize wellness trends) and pins scope to 'over weeks or months', with concrete example queries ('has my sleep improved', 'resting HR trend this year'). The per-period-average framing plus the metric list clearly separates it from single-metric siblings like get_steps, get_hrv, or get_sleep.

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 strong when-to-use signal via example phrasings and explicitly routes 'which days do I sleep worst / most stressed' to group_by='weekday'. Missing an explicit exclusion such as 'for a single day use get_daily_summaries instead', so the boundary with the raw-fetch siblings is implied rather than stated.

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