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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds substantial context beyond them: behavior differs when GARMIN_DOWNLOAD_DIR is set (file saved, path returned) versus inline base64 embedded resource, with a 3 MB size cap. That size limit and environment-dependent return mode are exactly the kind of operational detail an agent needs to plan around.

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 ordered by importance: what you get, how it is delivered, and when to use a smaller alternative. No redundancy with the title or annotations.

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 no output schema, the description covers the return modality, environment-dependent save path, size ceiling, and the cheaper sibling alternative. Nothing an agent needs to invoke or 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?

Only one parameter and schema coverage is 100%, with the schema itself explaining that activityId is the numeric ID returned by garmin_search_activities. The description adds no further parameter-level meaning, so the baseline 3 applies — the schema, not the description, carries the semantics.

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 — downloads the original device-recorded file for an activity — and clarifies the typical payload (ZIP containing .FIT with GPS, HR, power, cadence samples). It explicitly distinguishes itself from garmin_get_activity, so an agent can route 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 an explicit alternative with the condition that selects it: 'For summaries, splits or metrics, prefer garmin_get_activity: it is much smaller.' It also distinguishes the local-save vs inline-return cases, leaving no routing ambiguity.

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, so the safety profile is covered. The description adds genuine behavioral scope: what the payload contains, that dive/multisport blocks appear conditionally, and that sample-level data is excluded. It doesn't cover failure modes for invalid/nonexistent IDs, which keeps it below 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: the first front-loads the return contents, the second handles provenance and the sibling hand-off. Every clause carries information and nothing is repeated.

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 work by enumerating returned sections and their units (distance m, duration s, speeds m/s), which is what an agent needs to decide whether this tool answers its question. The sibling routing closes 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 single activityId parameter is fully typed and documented, so the baseline is 3. The description's note to source the ID from garmin_search_activities restates what the schema description already says, adding no new format or constraint information.

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 ('Get the full detail of one activity') plus the resource and enumerates exactly which fields come back (name, type, summary metrics, lap summaries, dive/multisport). It also distinguishes itself from two siblings by naming where the ID comes from and which tool to use for raw samples.

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 prerequisite ('Get the activityId from garmin_search_activities') and an explicit exclusion with the alternative ('Does not include per-second samples; use garmin_download_activity_file for the raw FIT data'). Both the when and the when-not are covered.

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: it enumerates the returned record shape and documents the empty-array outcome when the activity was not structured.

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, and the core purpose plus the return contents are front-loaded before the edge case. Nothing could be removed without losing 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 carries the return-value burden and does so reasonably by listing record fields and the empty case. For a one-parameter read tool this is nearly complete; only minor details like ordering or potential nulls 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 description coverage is 100% and the single activityId parameter is fully documented in the schema, including the cross-reference to garmin_search_activities. The description adds no additional parameter meaning, 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?

Specific verb 'List' and resource 'structured workouts that were followed during an activity', with the return payload sketched (workout name, sport, steps with targets, creation time). The sibling set is mostly wellness/summary endpoints, so this tool's distinct purpose is unmistakable.

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

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

The empty-array case implicitly tells the agent what a negative result means, but there is no explicit guidance on when to prefer this over garmin_get_activity or garmin_search_activities, nor any prerequisite note. Usage 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.

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 genuine context beyond that: the 31-day cap and the payload shape. However it says nothing about authentication scope, whether missing days are returned, or response size for a 31-day full series, which is the main risk an agent faces here.

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 front-loaded sentences with zero filler: what you get, the hard limit, then the parameter tip. The most decision-relevant facts (payload contents, 31-day cap) appear before the optional `chunks` guidance.

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 no-output-schema tool with fully documented parameters, the description covers payload contents and range limits adequately. It leaves unanswered how results are keyed per day, at what granularity the values array is sampled, and what happens for days with no data — minor but real gaps for a time-series endpoint.

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 the baseline is 3. The description adds only marginal semantic value: it restates the 31-day limit already in `endDate`'s schema and hints that `chunks` replaces full-series reads, but the schema already explains the chunk math (4 = every 6 hours) more precisely.

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 ('Get Body Battery') plus the payload contents: charged/drained totals, the `bodyBatteryValuesArray` time series, feedback events, and impacting activities. The 0–100 energy framing and named array make it unmistakable versus metric siblings like garmin_get_daily_summary 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 clear operating constraint (maximum range 31 days) and a concrete alternative mode of use: set `chunks` to get per-interval min/max 'instead of reading the full series.' It does not say when to prefer this over a sibling like garmin_get_daily_summary or what to do when the range exceeds 31 days, so it stops 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 cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds real value: the `{ data: [...] }` response envelope, one entry per day, the 365-day hard cap, and a warning that a year of data is very long. It stops short of anything about rate limits or error behavior, keeping it just under the top mark.

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

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

Three tight sentences: what it returns, the size/cap caveat, then the sibling pointer -- well front-loaded. Slight redundancy between 'Maximum range: 365 days' and 'a year of data is very long' costs it the top score.

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 both the response envelope and a practical sizing warning, and it documents the date-range constraint. An agent has everything needed to call it correctly and to decide against it in favor of the single-day sibling.

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' format, inclusivity, and the 365-day span limit are already documented in the schema. The description reinforces the range cap and the 'inclusive' semantics but adds little that isn't structured, 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?

Uses a specific verb plus resource ('Get daily wellness summaries') and enumerates the contained metrics (steps, calories, heart rate, Body Battery, floors), which leaves no ambiguity about what is returned. It also contrasts itself with the near-identical sibling garmin_get_daily_summary, so an agent can pick correctly without opening schemas.

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 explicit when-to-use guidance: prefer a few weeks or months per call unless the whole year is truly needed, and use garmin_get_daily_summary for a single day. Both the alternative tool and the condition selecting it are 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, so safety is covered; the description adds valuable scope information by enumerating exactly which data domains are aggregated, which substitutes for the missing output schema. It stops short of noting data-availability caveats (e.g. a day with no device sync) but is otherwise substantive.

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 a dense but scannable metric list, then the disambiguation sentence. The metric enumeration is long but earns its place given there is no 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 no output schema, the metric enumeration is exactly what an agent needs to know what a call returns, and the sibling routing covers the main ambiguity. Nothing essential for correct invocation 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?

Only one parameter, and the schema covers it at 100% including the YYYY-MM-DD pattern and local-calendar note. The description adds only 'for one day', which matches the schema without adding new format or timezone detail, 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 and resource ('complete wellness summary for one day') and enumerates the concrete metrics returned (kcal, steps, HR, stress, Body Battery, SpO2, respiration). An agent can distinguish this from garmin_get_sleep or garmin_get_steps 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?

Provides an explicit use-case cue ('Best single call for "how was my day?"') and routes the multi-day case to garmin_get_daily_summaries. It does not explicitly say when to prefer the granular siblings (e.g. garmin_get_stress, garmin_get_sleep) over this aggregate, so the guidance is clear 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 this as read-only, idempotent, and open-world. The description adds useful behavioral context by listing the exact output fields and components returned, though it does not discuss no-data 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?

The description is a single front-loaded sentence that names the action, date qualification, and return contents without 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 usefully enumerates the main return fields and components. Combined with fully documented input parameters, it gives the agent enough information to call and interpret the tool, though it omits empty-result behavior.

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 calendarDate and fullHistoryScan are already well documented. The description reinforces the date-based lookup but adds no additional parameter semantics 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 uses a specific verb and resource ('Get the latest Fitness Age') and enumerates the returned fields, making it clearly distinguishable from sibling wellness metrics like sleep, HRV, or 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?

It states the key usage context: retrieve the latest Fitness Age as of a given date. It does not explicitly name alternatives or when-not-to-use cases, but the metric-specific scope is clear enough for an agent to select it 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 readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds useful context beyond that: it discloses the large payload size, explains the `heartRateValues` time-series shape and its `heartRateValueDescriptors` column mapping, which an agent cannot infer from structured fields alone.

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

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

Front-loaded with what is returned, then the payload-size warning and alternative routing in the second sentence. The field enumeration is dense but each item earns its place; no filler sentences.

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 substantively (aggregate HR stats, alerts, time-series structure). Units (bpm) are only implied via the descriptor mention, a minor gap for a read-only single-parameter tool.

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

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

Schema coverage is 100% and the single `date` parameter is fully documented with format and timezone semantics in the schema. The description adds no input-side detail beyond what the schema already provides, so the 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 (get), resource (heart rate), and scope (one day), then enumerates the exact fields returned. This clearly separates it from sibling tools like garmin_get_heart_rate_zones or garmin_get_hrv without requiring the agent 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?

Explicitly routes the agent away from this tool for multi-day resting HR trends, naming garmin_get_daily_summaries as the alternative. It doesn't cover other plausible alternatives (e.g. heart rate zones) or when-not-to-use cases, but the key routing decision is 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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds useful content context (what configuration fields are returned), but omits the notable side effect implied by generateDefaults, which can create default zones when none exist — relevant behavior for an otherwise 'read-only' tool.

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

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

A single front-loaded sentence: purpose first, then a compact enumeration of returned fields. No filler or repetition.

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 return shape (training method, zone floors, max/resting/LTHR HRs), which is exactly what an agent needs. It only falls short on the generateDefaults side effect and multi-sport edge cases.

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% with a single, well-described parameter, so the schema carries the load. The description adds no extra parameter meaning, which is acceptable at this coverage level (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?

States a specific verb and resource ('Get the user's heart rate zone configuration') and further specifies the granularity ('one entry per sport'). This clearly separates it from siblings like garmin_get_heart_rate (measurements) or garmin_get_user_settings (general settings).

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 read-only getter intent is implied by the description, but there is no explicit when-to-use guidance, no named alternatives, and no mention of when zones might be absent or how generateDefaults interacts with usage. Minimum viable.

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 behavior, so the description's contribution is the prerequisite that a compatible watch must be worn overnight, plus disclosure of the returned data shape. That is meaningful context beyond what the annotations provide, though error behavior when no HRV is recorded is not covered.

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

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

One front-loaded sentence naming the resource and date scope, followed by the return-field enumeration and prerequisite. Dense but largely earning its place; the long parenthetical status list is somewhat bulky.

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: hrvSummary fields, status enumerations, hrvReadings in ms, and sleep window timestamps. Only the no-data/error case is unaddressed.

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

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

Schema coverage is 100% and the single parameter's date semantics ('morning after the night measured') are fully documented in the schema itself. The description adds only 'for one date' and no format or edge-case detail beyond the structured field, 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 ('Get overnight HRV') with a clear scope ('one date'), which implicitly differentiates it from the plural sibling garmin_get_hrv_summaries. An agent can tell what this returns 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?

Usage is implied by 'for one date' and the overnight-watch prerequisite, but there is no explicit when-to-use guidance and no named alternative such as garmin_get_hrv_summaries for multi-night data. The agent must infer the 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, so safety is covered; the description adds valuable output-shape context by specifying one record per day and which fields are included and excluded. It doesn't mention date-range limits, pagination, or response size, which would matter for a ranged 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?

A single compact sentence pair with the resource and granularity front-loaded, followed by the field list and the use case. Every clause carries information; nothing is redundant with 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 usefully compensates by listing the returned metrics and clarifying what is omitted. Parameters are fully documented in the schema, so the only remaining gap is operational detail such as range limits or maximum span.

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 fromDate/toDate already document format, inclusivity, and local-calendar semantics. The description only restates that a date range is required, adding no syntax or boundary guidance 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 names a specific verb (Get), resource (HRV daily summary), and granularity (one per day over a date range), then enumerates the returned fields (weeklyAvg, lastNightAvg, baseline, status, feedback). The clause 'without the 5-minute readings' implicitly separates it from the detailed garmin_get_hrv tool, so an agent can pick between them 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?

'Use for HRV trends and recovery analysis' gives clear positive guidance on the scenario this tool serves, and the exclusion of 5-minute readings scopes it. It stops short of explicitly naming garmin_get_hrv as the alternative for intraday readings, so the when-not is inferred 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 readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real context: the 31-day maximum and the fact that sweatLossInML is estimated from activities rather than logged. It does not describe ordering or pagination behavior, but for a bounded date-range read that is minor.

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 core purpose, and the field enumeration earns its space because there is no output schema. The field list is dense but not padded.

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 clarifying the two non-obvious ones (consumed value, estimated sweat loss). The range cap and data-availability caveat round it out; only timezone/ordering details are 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 both parameters are fully documented there, including inclusive bounds and local-calendar formatting. The description only restates the 31-day cap, adding nothing about startDate/endDate semantics 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 and resource ("Get logged water intake per day") and enumerates the returned fields, so its hydration-specific scope is unmistakable against siblings like garmin_get_nutrition_log or garmin_get_daily_summary.

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 precondition ("Only has data if the user logs hydration in Garmin Connect") and a hard range limit, which tells the agent when results will be empty and how to bound date ranges. It does not, however, name alternative tools for related nutrition/wellness 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 establish that this is a read-only, idempotent, non-destructive operation, so the description does not need to restate safety. It adds useful behavioral context by describing what the response contains, including daily log entries, cycle summary data, pregnancy weight goals, and optional baby movement 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?

The description is a single front-loaded sentence that moves from purpose to returned content with little wasted text. It is slightly dense, but the structure makes the main use case clear 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?

There is no output schema, so the description usefully outlines the main returned sections and notes pregnancy-specific optional data. Combined with fully documented parameters and safety annotations, this is complete enough for selection and invocation, though it does not discuss missing-data behavior, permissions, or privacy considerations.

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 five parameters are already documented in the schema. The description reinforces the meaning of optional baby movement data and cycle data but does not add much detail about todayDate, calendarDate, reducedResponse, or includeAnalysis beyond what the schema provides. 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?

The description states a specific resource and scope: a detailed view of one menstrual-cycle day, including daily log, cycle summary, and pregnancy-tracking data. The 'one day' scope implicitly distinguishes it from the sibling summary tool, so an agent can tell what it returns 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?

The description implies usage by framing it as a single-day detailed view and noting pregnancy-tracking content, but it does not explicitly say when to use this versus garmin_get_menstrual_cycle_summary or other wellness tools. The context is clear enough to infer the main use case, but no alternatives or exclusions are 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, so the bar is lower. The description adds genuine context beyond them: a data-availability precondition (cycle must be tracked in Garmin Connect) and conditional output (pregnancy info only 'when pregnancy tracking is on'), both of which affect interpretation of results.

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 domain ('Women's health:') and the action, then moves through return fields to the data-availability caveat. It is slightly list-heavy but every clause carries content; 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?

With no output schema, the description correctly compensates by enumerating the returned fields, including the conditional pregnancy data. The main omission is sibling differentiation against garmin_get_menstrual_cycle_day, which leaves an agent to guess between two closely named tools.

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 parameter is fully documented with format and local-calendar semantics. The description restates the key idea ('the cycle that contains a date') but adds no syntax or edge-case detail 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?

The description names a specific verb and resource ('get the menstrual cycle that contains a date') and enumerates the returned content (phase, fertile window, ovulation date, pregnancy info). It is clear what the tool retrieves, but it never distinguishes itself from the sibling garmin_get_menstrual_cycle_day, which an agent must choose between.

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?

Implicit usage is derivable from 'get the menstrual cycle that contains a date', and the prerequisite 'Only has data if the user tracks their cycle in Garmin Connect' is stated. However, there is no guidance on when to pick this versus garmin_get_menstrual_cycle_day, and no exclusions or fallback behavior.

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, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the data-completeness caveat about the user needing to log food, plus the scope of returned content, which helps the agent decide whether a null-ish result is an error or expected.

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

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

A single front-loaded sentence with the resource and scope first, followed by the enumerated payload and one caveat sentence. The parenthetical field list ('protein, carbs, fat, fiber…') and meal enumeration are slightly dense but each element conveys real payload information, so 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 describing return values, and it does so by naming the major payload sections an agent would act on. It stops short of explaining response shape or how mealDetails/meal IDs relate, but for a read-only single-day fetch 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 coverage is 100%, so every parameter (date format, mealId, the three include* toggles and their defaults) is already fully documented in the schema. The description only loosely gestures at parameters by mentioning goals and meal details; it adds no syntax or usage nuance 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?

Opens with a specific verb and resource ('Get the user's food log for one day') and then enumerates exactly what is returned: goals, nutrient totals, logged foods with serving sizes, and meal-by-meal breakdown. No sibling tool in the set covers nutrition, so the scope is unambiguously distinct from the sleep, steps, hydration, and weight tools.

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

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

The description gives clear operating context, including the key precondition that data only exists if the user logs food in Garmin Connect, which tells the agent how to interpret an empty response. It does not explicitly route the agent away from alternatives (e.g., whether the daily summary also carries nutrition), but no real competing sibling exists here.

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 genuine behavioral context beyond that: the exact fields returned, that durations are in seconds, and the night-boundary semantics. It stops short of noting data availability caveats (e.g., watch not worn) or how missing metrics appear, 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 verb, resource and scope; the alternative is placed at the end where it belongs. The long field enumeration is lengthy but each item is a returned metric, which is load-bearing information given there is no 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?

For a one-parameter read tool with no output schema, the description covers the date semantics, units, and a near-complete inventory of return fields, plus sibling routing. A minor gap is the absence of any note about sparse or unavailable data on nights the device wasn't worn.

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 `date` parameter, so baseline would be 3. The description earns above baseline by restating the semantic interpretation ('the night ending on that morning') that the schema phrase 'date of the morning you woke up' could otherwise be misread.

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 ('Get sleep data for one calendar date') and immediately disambiguates the time window with 'the night ending on that morning.' It also names the sibling that handles the multi-night case, so an agent can distinguish it from garmin_get_sleep_summaries without reading 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?

Explicitly routes the agent: single night here, 'For several nights use garmin_get_sleep_summaries.' The parenthetical about which night the date refers to removes the most likely usage mistake (off-by-one-night).

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 useful behavior: the field-level contents of each record, the units (seconds), and the hard 31-day request ceiling — the latter partially duplicating the schema's endDate note.

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?

Purpose is front-loaded in the first clause, the field list is dense but scannable, and the closing constraint sentence is short. No filler or restated 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, enumerating returned fields and units is exactly the right compensation, and annotations cover safety. Minor gaps remain: behavior for nights with no recorded sleep, and whether the 31-day limit is enforced as an error or truncation.

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 are well documented with format, inclusivity, and the 31-day limit. The description adds no parameter-level meaning beyond repeating the range cap; 'durations are in seconds' concerns return values, not 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?

States a specific verb and resource with scope: 'one sleep summary per night for a date range', and enumerates the returned fields. It implicitly differentiates from the single-night sibling garmin_get_sleep via 'per night for a date range', but never names that sibling explicitly.

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

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

Usage is implied by the range framing and the 31-day cap, so an agent can infer this is the batch version. However, it never says when to prefer this over garmin_get_sleep or how to handle ranges longer than 31 days (split vs. error).

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, so the safety profile is covered. The description adds value beyond that by disclosing a hardware prerequisite (Pulse Ox-enabled watch) and by enumerating the concrete data families returned, including altitude acclimation data — context an agent cannot get from 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?

One front-loaded sentence that states the resource and metric list first, then the hardware prerequisite. The field enumeration is long but each item is informative for a tool with no output schema; there is no filler or repetition.

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 parameter, rich annotations, and no output schema, the description carries the return-value burden and does so thoroughly via the metric list plus the hardware precondition. Minor gaps remain around empty-data behavior and timezone edge cases, but nothing essential to correct invocation 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 single calendarDate parameter is fully documented with format and local-calendar semantics, so the baseline is 3. The description's 'for one day' aligns with the parameter but adds no syntax, timezone, or boundary 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?

It names a specific verb ('Get'), a specific resource (Pulse Ox / SpO2 in %), and an explicit scope ('for one day'). The enumeration of returned metrics makes it immediately distinguishable from siblings like garmin_get_heart_rate, garmin_get_hrv, or garmin_get_stress 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?

Usage is implied by the narrow scope ('for one day') and the prerequisite 'Requires a watch with Pulse Ox enabled' gives a real gating condition. However, it never states when to prefer this over adjacent wellness tools (heart rate, HRV, sleep) or what happens if the device lacks Pulse Ox, leaving the agent to infer 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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile needs no restating. The description adds real behavioral context beyond them: the 28-day cap that forces chunking and the per-day result granularity. It stops short of noting pagination, auth requirements, or data freshness/rate limits, which would be needed for 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?

A single tightly-packed sentence that front-loads purpose, then the per-day/unit detail, then the constraint and alternative. No wasted clauses, though the density makes it slightly harder to scan than two short sentences would be.

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

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

No output schema exists, and the description compensates by naming the returned fields (calendarDate, totalSteps, totalDistance in meters, stepGoal). Combined with the range limit and sibling routing, an agent has everything needed to call this correctly without trial and error.

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%: both startDate and endDate already document inclusive endpoints, the YYYY-MM-DD pattern, local-calendar semantics, and the 28-day span limit. The description's range guidance largely echoes the schema's endDate text, adding little parameter meaning beyond it — 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 ('Get daily step totals') with explicit granularity ('one entry per day'), enumerated return fields, and a named sibling it differs from. An agent can distinguish it from garmin_get_daily_summaries without inspecting 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 an explicit operational rule ('Maximum range: 28 days per request; split longer periods') and a concrete routed alternative with its own limit ('garmin_get_daily_summaries (up to 365 days), which also includes steps'). The condition that selects the sibling is stated, not 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, idempotentHint, and non-destructive, so safety is covered; the description adds real value by disclosing the return shape (one entry per day, calendarDate plus values map), the units of each duration field in seconds, the 0–100 scale, the HRV derivation, and the 28-day cap. Only error behavior and empty/no-data handling are left unstated.

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

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

A single dense sentence that front-loads the resource and result shape before the constraint. It is long but every clause carries information; only the 28-day limit 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 takes on the burden of explaining the return value and does so concretely (field names, units, ranges). What remains missing – pagination behavior beyond the 28-day cap, empty-day handling, and any auth/permission notes given openWorldHint=true – is minor but not trivial.

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% – both startDate and endDate are already documented as inclusive, YYYY-MM-DD, user-local, and bounded by 28 days. The description restates the 28-day maximum, which is duplicative rather than additive, 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 verb and resource ('Get daily stress statistics for a date range') and immediately describes the shape of the result, so an agent knows what comes back. The resource (stress) is lexically distinct from nearby siblings like garmin_get_hrv or garmin_get_body_battery, but the description never explicitly contrasts them, so it sits just below 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?

There is no explicit guidance on when to call this versus alternatives in a crowded sibling set (hrv, hrv_summaries, daily_summary, body_battery all overlap in wellness territory). The 28-day limit is stated, but as a constraint, not a usage 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the concrete payload contents and positioning the call as a prerequisite for time-zone- and unit-sensitive queries. It does not mention auth requirements or whether all fields are always populated.

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, followed by a dense but purposeful field enumeration and one actionable usage sentence. The long comma list of settings is slightly heavy, but since there is no output schema it is doing necessary work rather than padding.

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

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

With no output schema, the description compensates by naming the returned settings fields, which is exactly what an agent needs to decide whether to call it and how to use the result. Minor gaps remain around failure modes and guarantee of field presence, but nothing essential is missing for a zero-arg read.

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 gap to close; baseline for 0 params is 4. The description correctly spends its space on return-value scope instead of inventing argument 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?

Uses a specific verb+resource ('Get the user's Garmin Connect settings') and then enumerates the concrete fields returned, so an agent knows exactly what comes back. It is clearly distinct from every sibling, which all retrieve activity or wellness metrics rather than account-level configuration.

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 directs the agent to 'Call this first to learn the user's time zone ... and preferred units', giving a concrete ordering rule and rationale tied to interpreting 'today'. It does not state when-not to use it or name any alternative, so it stops short of full routing 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: units in GRAMS with a worked example (75000 = 75 kg), percentage fields, epoch-millisecond timestamps, and that weightDelta is change since the previous weigh-in. It stops short of return ordering or how empty ranges behave, but the added value is substantial.

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?

Purpose is front-loaded in the opening clause and the alternative-tool routing is placed last, which is the right order. The field enumeration is long but each item earns its place by telling the agent what comes back; the sentence is dense rather than padded, though it could have been split for readability.

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 is the only place return values can be described — and it does so thoroughly: the full field list, units for each measurement class, and the temporal format of timestamps. With the two date parameters covered by schema and the safety profile covered by annotations, nothing essential is missing.

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

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

Schema coverage is 100% and the schema already documents both startDate and endDate including format, inclusivity and local-calendar semantics. The description only implies the date range generally and adds no syntax, boundary, or default information beyond the schema. Baseline 3 applies when 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?

States a specific verb+resource+granularity: 'every individual weigh-in in a date range', and explicitly broadens the source ('Index scales, other smart scales or manual entries'). It also names the sibling it is not (garmin_get_weight_summary), so an agent can distinguish it 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?

The final sentence gives an explicit routing rule: 'For one value per day plus the range average use garmin_get_weight_summary.' Combined with 'every individual weigh-in', the when-to-use condition versus the alternative is unambiguous, including the cardinality distinction (many vs one per 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 cover read-only, idempotent and non-destructive semantics, so the description adds real value: it discloses the two result collections (userGoals, userGoalRanges), the unit of measurement (grams, not the user's display unit), and the category vocabulary (MANUAL, PREGNANCY). It does not discuss empty-range behavior or pagination, 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?

A single front-loaded sentence with no filler, and the key concept (goals in effect during a range) comes first. The parenthetical enumeration of return fields is dense but each item 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?

With no output schema, the description usefully sketches the return shape, units and category values, which is the right use of the space. Reasonably complete for a simple two-parameter read; missing only edge-case behavior for empty or unbounded goal periods.

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 required date parameters are fully documented there, so the schema does the heavy lifting. The phrase 'in effect during a date range' adds a hint that the range acts as an overlap filter rather than an exact-match filter, but the description does not spell out that boundary behavior.

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

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

States a specific verb+resource (get weight goals) scoped to a date range, and the name plus description separate it from garmin_get_weight_entries and garmin_get_weight_summary by returning goal definitions rather than measurements. It does not explicitly say how it differs from those siblings, so it stops short of 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?

Usage is only implied: the description says it returns goals 'in effect during a date range', which suggests calling it when goal context (target weight, tracking period) is needed. There is no explicit when-to-use guidance, no statement of when to prefer weight_entries or weight_summary instead.

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), so the description adds meaningful context on top: the unit conventions (grams, so 75000 = 75 kg), that bodyFat/bodyWater are percentages, and that timestamps are epoch milliseconds. Those details prevent the most likely misreadings, though nothing is said about missing data, empty ranges, 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?

A single sentence that is front-loaded with the action and then packed with return-value facts; each clause (field list, gram units, percentage fields, epoch timestamps) carries real information. It is dense rather than wasteful, though splitting the units note into its own sentence would improve scanability.

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 full burden of return-value documentation and does so: it names the payload fields, their units, and the boundary behavior outside the range. An agent can interpret the response correctly without additional context.

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 all three parameters are already documented in the schema, making 3 the baseline. The description restates includeAll's effect on dailyWeightSummaries but adds no new semantics beyond what the schema already says; it does not, for example, explain interaction with the before/after lookups.

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 names a specific verb and resource ('Get a weight summary for a date range') and enumerates exactly what comes back (dailyWeightSummaries, totalAverage, previousDateWeight/nextDateWeight). The summary-vs-raw distinction from garmin_get_weight_entries is only implied, not stated, so sibling differentiation is left to the agent.

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

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

There is no explicit when-to-use or when-not guidance and no mention of alternatives such as garmin_get_weight_entries or garmin_get_weight_goals. Usage is only implied by the date-range scoping and the summary framing.

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 readOnly, idempotent, non-destructive behavior, so the description's added value is scope and payload disclosure: the returned fields and the inclusive date semantics. It does not discuss pagination, result limits, or auth for a potentially large date range, 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 the resource and scope, followed by the exclusion and alternative. Every clause carries information an agent needs; nothing is redundant or padded.

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 enumerating the returned fields (name, type, notes, timestamps, summary values, time in zones), and annotations cover the safety profile. For a two-parameter read tool, nothing essential to correct invocation 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%, with both dates documented for format, inclusiveness, and local-calendar semantics. The description's "Both dates are inclusive" reinforces the schema but adds no new parameter meaning, which matches the baseline 3 when the schema carries the burden.

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 ("Get wellness activities") with concrete examples (breathwork, meditation, relaxation) and an explicit scope boundary: non-fitness sessions recorded on the device. It also names the sibling to use for fitness 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?

Explicitly says what this tool covers and what it does not ("Fitness activities such as runs or rides are not here"), then names the alternative, garmin_search_activities. Both the inclusion and exclusion conditions are stated, not inferred.

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 needs no restating. The description adds genuinely new behavioral context: newest-first default ordering, AND-combination of filters, and pagination mechanics. It stops short of noting result caps or whether sorting applies before or after filtering.

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 workflow routing, then the return-field inventory. The long field list is lengthy but earns its place because there is no output schema. Minor redundancy in restating the default sort that the schema also documents.

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 32-parameter tool with no output schema, the description supplies exactly what is missing: the shape of the returned summaries, default ordering, filter-combination logic, pagination, and the follow-up tools for detail. 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 100%, so 3 is the floor, but the description contributes semantics the schema lacks: that filters are ANDed, that results are newest-first by default, and that pagination is start/limit-based. The listed return fields help the agent reason about which filters (e.g. averageHR, avgPower via requiredField) will actually match.

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 ('Search and list the user's recorded activities') and enumerates the activity families covered. It explicitly positions itself against siblings by naming garmin_get_activity and garmin_download_activity_file as the next steps, so an agent can distinguish it without reading 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?

States a clear workflow: 'Use this first to find activity IDs, then call garmin_get_activity for splits and full detail, or garmin_download_activity_file for the original FIT file.' It also explains filter composition (all optional, combined with AND) and directs pagination via `start`/`limit`.

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