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 genuinely non-schema behavior: the whitelist of acceptable service prefixes, which prevents calls outside the supported API surface. It does not describe error behavior for a rejected prefix or rate/response characteristics.

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 and the when-to-use rule, followed by the prefix whitelist and one example. The long prefix enumeration is dense but operational rather than filler; nothing else 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?

No output schema, so the agent gets no return-shape information beyond the example path, and error/pagination behavior is unstated. For an open-world raw passthrough that is largely inherent, and the critical missing piece — which paths are legal — is fully covered.

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% (baseline 3), and the description goes beyond it by constraining `path` to a specific set of service prefixes and supplying a worked example, which the schema's generic "API path beginning with /" does not convey. The `params` object stays undocumented in both places, leaving query-parameter semantics to be discovered from Garmin docs.

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 ("Call any documented Personal API endpoint directly") and immediately differentiates itself from the 22 siblings as the fallback "for data the other tools don't cover." The example endpoint makes the shape concrete, so an agent can tell when this generic tool applies versus garmin_get_sleep, garmin_get_hrv, etc.

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 inclusion rule (only for data the named sibling tools don't cover) plus a hard precondition: the path must begin with one of 14 enumerated service prefixes. It stops short of naming which sibling covers which domain, so the agent must still infer when a specific tool exists before falling back 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 flag a non-read-only, idempotent, non-destructive, open-world write. The description adds genuine value by disclosing exactly what is written (Garmin's ZIP containing the .fit) and that it lands on the local filesystem, plus that the saved path is returned. It does not address overwrite behavior or whether the target folder must already exist.

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: what is saved and where first, then the downstream use case, then the return value. No filler and nothing buried.

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

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

For a two-parameter tool with full schema coverage and annotations carrying the safety profile, the description covers purpose, output ('returns the saved path'), and motivation. Minor gaps remain around overwrite/file-exists and folder-creation 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% — both directory (with its default) and activity_id (with its source, garmin_list_activities) are documented in the schema. The description only reinforces that the file goes to a folder, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The verb (saves) and resource (an activity's original file, i.e. the ZIP containing the .fit) are stated specifically, and the destination ('a folder on this computer') is explicit. It implicitly distinguishes itself from data-returning siblings like garmin_get_activity by emphasizing the *original file*, though no sibling is named.

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

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

Usage context is clear: use it when the file must be imported into another tool such as Runalyze or Golden Cheetah. It does not state when to prefer a sibling (e.g. garmin_get_activity for parsed data) or name any exclusion, so it stops short of the 5 bar.

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 fully covered. The description adds one piece of real context — that values are Garmin's *computed* summary rather than raw sensor streams — but says nothing about auth needs, rate limits, or behavior for missing/invalid activity IDs. That is adequate but not rich, given the lower bar set by 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?

Two sentences, zero filler, with the scope/value statement front-loaded and the sibling routing immediately after. 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?

For a simple single-ID read tool with full annotation coverage and a field list that effectively previews the return payload, nothing critical is missing. Only absent piece is behavior on invalid/unknown activity IDs in the absence of an output schema.

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

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

Schema description coverage is 100% and both parameters are documented there, including where activity_id comes from and what response_format values mean. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('computed summary for one activity') and enumerates the returned fields (distance, durations, pace/speed, HR, cadence, elevation, training effect, calories). It explicitly distinguishes itself from the closest sibling, garmin_get_activity_splits, so an agent can pick the right tool without opening either schema.

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

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

The second sentence names the alternative for per-km splits and the condition that selects it, which is exactly the kind of routing guidance needed among the many garmin_get_* siblings. It stops short of saying when NOT to use this tool at all (e.g., raw FIT data vs summary) but the essential fork is 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 cover safety (readOnly, idempotent, non-destructive), so the description's real contribution is the how: it fetches the original .FIT, interpolates at boundaries, excludes pauses, and defaults to 1 km. It omits any note about download cost/latency for fetching a full FIT file, keeping 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 tight paragraphs: the first front-loads what is computed and its defaults, the second front-loads when to reach for it. 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?

There is no output schema, and the description compensates by enumerating the returned content (splits, HR, cadence, climb, laps, pacing verdict). Combined with the stated applicability constraints, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds interpretive meaning: the default split is 1 km and splits are interpolated at boundaries with pauses excluded, which affects how split_meters should be chosen. That is genuinely beyond the schema text.

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+resource: downloads the original .FIT and computes exact distance splits with named sub-outputs (per-split HR, cadence, climb, device laps, pacing verdict). This clearly separates it from garmin_get_activity and garmin_get_performance_metrics even without naming 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 concrete triggering questions ('how was my pacing', 'did I go out too fast', 'compare km 1 to km 5') and states the applicable population (GPS or footpod activities from a Garmin device). It doesn't explicitly name a sibling alternative to prefer for adjacent needs, so it stops 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 as a safe, read-only, idempotent operation, and the description adds meaningful behavioral context by stating that long ranges are automatically chunked and capped at 366 days. It also enumerates the returned per-day values, though it does not discuss error handling or timezone 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 two tight sentences. It front-loads the resource and returned metrics, then immediately states the important long-range behavior, with no redundant wording.

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

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

For a simple two-parameter read tool with full schema coverage and safety annotations, the description covers the key return fields and the automatic chunking limit. It could be slightly more complete with explicit timezone or invalid-range behavior, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so both start_date and end_date are already well documented in the schema. The description adds no parameter-specific syntax or constraints beyond what the schema provides, making the baseline score 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 clearly identifies the resource as Body Battery and specifies the per-day metrics returned: charged, drained, highest, and lowest values. It is distinguishable from siblings like stress or sleep by resource, though it lacks an explicit retrieval verb and does not explicitly contrast itself with adjacent wellness 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 does not say when to use this tool versus alternatives such as garmin_get_daily_summaries, garmin_get_stress, or garmin_get_day. Usage is only implied by the Body Battery resource name, with no exclusions or selection 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, openWorld), and the description adds genuinely new behavior: long ranges are chunked automatically and capped at 366 days. It doesn't say what happens for days with no device data or how gaps appear in the result, which would be the next useful disclosure.

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 paragraphs: the returned field list first, then the range/chunking caveat. Every sentence carries information an agent needs, and no schema or annotation content is restated.

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 takes on the burden of enumerating return fields, which it does thoroughly. Remaining gaps are minor: no units, no indication of whether results are an array of per-day objects, and no note on how missing/incomplete days 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 coverage is 100% — both start_date and end_date are documented with formats and defaults — so the description needn't repeat them. The only added signal is the implicit ~366-day span limit on the date range, which is weakly stated ("Long ranges are fetched in chunks automatically") and doesn't clarify whether the cap is an error boundary or a truncation.

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 precisely what it returns — per-day totals for a named list of metrics (steps, distance, calories, HR, stress, intensity minutes, floors, Body Battery) — and frames itself as the multi-day/trend tool. It is clearly distinguishable from single-metric siblings like garmin_get_steps or garmin_get_stress, though it never names the closest sibling, garmin_get_day, so the single-day-vs-range boundary is only implied.

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 tool for trends across weeks" gives a clear selection condition for the range-based use case, and the 366-day chunking note sets expectations for large spans. It stops short of explicit alternatives (no "for a single day use garmin_get_day" guidance) or exclusions, so the agent must infer the boundary with garmin_get_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, non-destructive safety, so the bar is lower; the description adds the non-obvious behavioral trait that sections with no Garmin data are omitted rather than erroring. It also implicitly reveals the composite return payload, which matters given there is no output schema. It does not mention latency or payload size for a multi-section aggregate call.

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

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

Three short sentences, zero filler: contents first, use case second, edge-case behavior last. Front-loaded with what the agent needs to decide whether to call it.

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

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

With no output schema, the description carries the burden of describing the return value, and it does so by enumerating the response sections to a useful level of detail plus the omission rule. Missing only minor operational details such as payload size or whether sections are nested keys.

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 already documents accepted formats ('today', 'yesterday', 'N days ago') plus local-time semantics. The description adds nothing about the date argument beyond 'for one day', 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 with scope: 'Everything for one day in one call', then enumerates the exact sections returned (daily summary, sleep, HRV, Body Battery, activities). This clearly separates it from the granular siblings like garmin_get_sleep or garmin_get_hrv, which each cover one of those sections.

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 positions itself as the 'Best first call' for recovery and yesterday-review questions, which is real routing guidance in a 20+ sibling family. It stops short of naming which sibling to use when the agent only needs one section, so the when-not case 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the response includes the estimate's inputs, which is mild return-content context, but it says nothing about data availability (what happens if no estimate exists for a date) or default behavior.

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

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

A single front-loaded sentence with no filler, but it is arguably too terse for a domain concept ('fitness age' and what the inputs are) that could bear one clarifying clause.

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 optional-parameter read tool with no output schema, the description is minimally adequate, but it leaves the return shape vague ('its inputs' is undefined) and gives no fallback semantics for dates with insufficient data.

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 relative expressions, so the schema carries the load. The description's 'for a date' merely echoes that scope without adding interpretation, 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 resource — Garmin's fitness age estimate — plus its contributing inputs, with a scope of 'for a date'. An agent can distinguish it from siblings like garmin_get_performance_metrics or garmin_get_profile, though no sibling is named 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?

There is no when-to-use guidance, no mention of prerequisites (e.g. needing sufficient recent activity data for an estimate to exist), and no routing to alternatives such as garmin_get_performance_metrics for other derived metrics. Usage is only implied by the tool name.

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 readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful content context (resting HR value plus intraday samples) but says nothing about sample granularity, units, timezone, or behavior for dates with no 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?

A single short sentence with no filler, and the scope ('one day's') is front-loaded. It is arguably too terse for a data-retrieval tool, 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 is the only place to learn what comes back, and it only gestures at the return shape ('all-day heart-rate samples') without stating sample interval, units, or ordering. For a simple read-only getter with a fully documented parameter this is adequate but not complete.

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

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

Schema description coverage is 100%, and the single date parameter already documents the YYYY-MM-DD format and the 'today'/'yesterday'/'N days ago' shortcuts. The description's 'one day's' reinforces single-date semantics but adds no format or default 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?

States a specific resource and scope: one day's resting HR plus all-day samples. That is more precise than the title alone and lets an agent tell it apart from garmin_get_hrv or garmin_get_stress, though it never names those siblings or clarifies overlap with garmin_get_day.

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

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

There is no when-to-use or when-not guidance, and no mention of alternatives such as garmin_get_hrv or garmin_get_day, which may also surface heart-rate data. Usage is only inferable from the resource name and the 'one day' scope.

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 bar is lower. The description still adds non-obvious operating context: long ranges are auto-chunked and capped at 366 days, which an agent needs to know before requesting wide spans.

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 payload contents, then the one operational caveat about chunking. No redundant restatement of the tool name or schema.

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

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

With no output schema, the description usefully enumerates the returned metric fields and the chunking/cap behavior. Minor gap: it does not state units or what 'baseline range' looks like, 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%, so start_date/end_date formats and defaults are fully documented in the schema. The description adds only the max-span constraint (366 days), which is a marginal but real contribution — baseline 3 applies.

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

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

States a specific resource (per-night HRV) and enumerates exactly what is returned: last-night average, weekly average, baseline range and status. It is clearly distinguishable from siblings like garmin_get_sleep or garmin_get_stress by resource, though it never names an alternative 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 described payload — an agent can infer it should call this when it needs HRV status — but there is no explicit when-to-use/when-not guidance or comparison to garmin_get_heart_rate or garmin_get_performance_metrics.

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 elsewhere. The description adds genuinely new behavioral facts: results are per-day and long ranges are chunked automatically with a 366-day ceiling, which tells the agent it can request wide ranges without manual pagination.

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, the payload described first and the chunking caveat second. Nothing is padded, though the fragmentation into a separate sentence for chunking is slightly staccato.

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 states the returned unit (per-day intake) and the accompanying goal, plus the range limit that governs the required parameters. That is sufficient for an agent to call it correctly; only the concrete return shape is left unstated.

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

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

Schema coverage is 100% and both parameters are documented with accepted date formats, so the description need not repeat them. It contributes indirectly by clarifying that returned data is per-day and by implying a 366-day span ceiling, but adds no format or default 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?

States a specific resource and metric: per-day logged water intake plus the goal. An agent can tell this is the hydration getter rather than a generic wellness call. It never names the nearest sibling (garmin_get_nutrition, garmin_get_daily_summaries), so the boundary is left implicit.

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 rather than stated — you reach for it when you want water intake data. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative such as garmin_get_nutrition if that tool also carries hydration fields.

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 description need not repeat safety properties. It adds only that results are scoped to one day's logged entries; it says nothing about whether unlogged days return empty results or how entries are grouped (meals vs totals).

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 sentence with no waste, resource and time scope front-loaded. Nothing redundant with the schema 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, annotation-backed read tool with a fully described schema, the definition is largely sufficient. The only real gap is that no output schema exists and the description does not hint at the shape of the returned food/macro data.

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 documented with format and relative-date forms, so the description carries no additional burden. Baseline 3 is appropriate here.

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 Connect nutrition log) and a verb-like scope (foods and macros logged for one day). It reads clearly against siblings like garmin_get_hydration or garmin_get_weight, though it never explicitly distinguishes itself from 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?

The intent is implied by name and description — retrieve nutrition entries for a single day — but there is no explicit statement of when to use this versus, say, garmin_get_daily_summaries or garmin_get_hydration, and no exclusions or prerequisites.

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 safety, but the description adds substantial extra context: data is decoded from original .FIT files because the Personal API has no VO2 max endpoint, each activity costs one file download, and Garmin only updates VO2 max on qualifying runs and power-meter rides. That is exactly the cost and data-freshness information an agent needs.

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

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

Front-loads what the tool returns, then the data-source rationale, then two compact intent-to-parameter examples and a cost caveat. Every sentence carries information an agent would otherwise have to guess.

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?

Though there is no output schema, the description enumerates the returned fields (rounded and precise VO2 max, new readings, per-activity rows) and explains the cost model and update cadence. Nothing essential for correct invocation appears 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 adds real meaning by tying last_n to per-activity file-download cost and recommending small values, which the schema does not convey. It says less about activity_type and response_format, but those are already documented in the schema.

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

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

States precisely what it returns: current VO2 max (rounded plus precise value), new VO2 max readings in the window, and per-activity aerobic/anaerobic training effect, recovery time and performance condition. This clearly separates it from siblings like garmin_get_fitness_age and garmin_get_activity, which do not expose these metrics.

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?

Maps natural-language intents to concrete parameters ("what's my VO2 max?" -> last_n=20, "how hard was today's workout?" -> last_n=1) and warns to keep last_n small unless a trend is requested. It does not explicitly say when to prefer garmin_get_activity over this tool, which keeps it from a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuine context beyond that: it discloses that lactate threshold is only present 'where set' (partial-field behavior) and that this is the intended first call for interpreting other data. It does not describe the shape of zones or unit conventions, so not a 5.

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

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

Two sentences: the first front-loads what comes back, the second front-loads when to call it. No filler, no restatement 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 and no parameters, the description carries the burden of telling the agent what it receives, and it does so at field level plus the zones payload. It stops short of explaining how zones/units are represented, which would matter for downstream interpretation, but the essentials are present.

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 the schema imposes nothing to document; baseline is 4. The description's field enumeration is informational about the return payload rather than about parameters, which is appropriate here.

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 user's Garmin profile settings) and enumerates the fields returned — units, weight, height, birth year, lactate threshold — plus heart-rate zones. No sibling tool covers profile settings, so an agent can distinguish it from the wellness/activity siblings purely from the description.

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?

"Call this first when you need zones or units to interpret other data" gives an explicit trigger condition and a sequencing rule relative to the rest of the toolset. There is no explicit 'do not use when' clause or named alternative, 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 readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral facts: long ranges are fetched in chunks automatically and the ceiling is 366 days, which tells the agent about latency and range limits it 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?

Two sentences, zero filler. The returned fields are stated first and the operational caveat (chunking, 366-day max) follows, so the most decision-relevant information is front-loaded.

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

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

With no output schema, the description responsibly enumerates the returned data (duration, stage breakdown, score, timing). Combined with the range-limit note and full schema coverage, an agent has enough to call it correctly; only the sibling differentiation gap keeps it from a 5.

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 accepted date formats and inclusive end_date defaults. The description only adds the 366-day range cap, which is a limit rather than a parameter semantic; baseline 3 applies when the schema carries the load.

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 specific resource ('per-night sleep') plus the exact metrics returned (duration, sleep stages, score, timing), which is far more informative than the bare title 'Sleep'. However, it never mentions the sibling garmin_get_sleep_detail, so an agent has no stated basis for choosing between two sleep-related 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 date-range nature implies when the tool applies, and the note about chunked fetching of long ranges gives useful operational context. But there is no explicit when-to-use or when-to-prefer-an-alternative guidance, particularly against garmin_get_sleep_detail, which is the most likely confusion point.

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 the safety profile is covered. The description adds the returned data components but does not disclose data latency, availability, or failure behavior; with annotations present, this is adequate but not rich.

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

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

It is a single front-loaded sentence with no wasted words. The key purpose and returned components appear 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?

No output schema exists, and the description usefully enumerates the key returned data (stages, score breakdown, respiration, SpO2, HR). For a one-parameter read tool with annotations, this is nearly complete, though it could explicitly contrast itself with garmin_get_sleep.

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

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

There is only one parameter, date, and schema description coverage is 100%, so the schema already documents format, examples, and default. The description does not add any parameter-specific meaning beyond the schema.

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

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

It names a specific resource and enumerates the full sleep components returned. The phrase "in full" hints that it is the detailed counterpart to sibling garmin_get_sleep, but it does not name 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?

The description implies usage when full overnight detail is needed, but it gives no explicit when-to-use/when-not-to-use guidance. It also does not mention the obvious alternative, garmin_get_sleep, for summary-level sleep 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered elsewhere. The description adds no behavior beyond that — it does not say what happens for a date with no readings, whether data is device-dependent, or what 'acclimation' means as a returned concept.

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 sentence is short and front-loaded with no wasted clauses, but its brevity comes from omission rather than economy — one fragment is doing the work of a full definition, and the term 'acclimation' is left unexplained.

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?

This is a simple read with one optional, well-documented parameter, but there is no output schema, so the description should indicate what 'readings and acclimation' actually returns (fields, units, granularity). As written, an agent cannot anticipate the response shape or interpret the undefined 'acclimation' metric.

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 relative-date syntax, so the baseline is 3. The description adds nothing about the date parameter, which is acceptable here since the schema carries the full 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?

The phrase "One day's SpO2 readings and acclimation" names the resource (SpO2) and bounds the scope to a single day, so an agent knows roughly what it retrieves. But it is essentially a restatement of the tool name in noun form, with no verb and no differentiation from metric siblings like garmin_get_heart_rate or garmin_get_stress beyond the metric noun itself.

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

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

There is no guidance on when to call this versus the other per-metric wellness tools, no mention of prerequisites (device must support Pulse Ox), and no note that the date defaults to today. The agent must infer all routing from the tool name.

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 confirm this is a safe, read-only, idempotent operation. The description adds useful behavioral context by disclosing automatic chunking for long ranges and a 366-day cap, which is not represented in the schema.

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

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

Two short sentences, front-loaded with the core purpose and followed by an important operational constraint. No wasted text.

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 metric tool with full parameter documentation and annotations, this is nearly complete. It covers purpose and range behavior, though sibling differentiation and output shape remain lightly specified.

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 date parameters are already well documented. The description adds a meaningful constraint beyond the schema: long ranges are chunked automatically and capped at 366 days.

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

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

The description clearly identifies the resource and metric: per-day step totals and goals. It does not explicitly distinguish this from closely related siblings such as garmin_get_daily_summaries, so it falls 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?

It implies the tool is for step data but gives no explicit guidance on when to use it instead of related tools like garmin_get_daily_summaries or garmin_get_day. No exclusions or alternatives are mentioned.

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 and open-world behavior, so the description's job is to add beyond that — and it does, disclosing automatic chunking for long ranges and a 366-day ceiling. That is meaningful operational context an agent would otherwise have to discover by trial.

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

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

Two sentences, zero waste, and the core purpose is front-loaded before the operational caveat. Nothing repeats the schema or the 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 read-only, fully-documented, two-parameter tool this is close to adequate, but with no output schema the description never says what a result entry looks like — granularity (daily average vs intraday samples), units, or scale of stress values. Those are the gaps an agent would hit on first call.

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 parameters fully documented including formats and the end_date default, so the schema carries the burden. The description adds only the outer range limit (366 days), which is a real constraint but does not enrich individual parameter 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?

The description names the resource precisely — per-day all-day stress levels — so an agent knows exactly what data comes back. It offers no differentiation from similar-looking siblings such as garmin_get_day or garmin_get_daily_summaries, which may also surface stress, 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?

There is no statement of when to use this tool versus alternatives like garmin_get_day or garmin_get_daily_summaries, and no exclusions or prerequisites. Usage is only implied by the presence of a date-range parameter.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description's job is to add context — and it does: it discloses the unit convention (Garmin reports grams, divide by 1000) and the automatic chunking with a 366-day cap. Those are non-obvious traits an agent could not get from annotations or schema.

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

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

Two sentences: the first delivers scope, output fields and the critical unit conversion; the second delivers the range constraint. Nothing is redundant and the key caveat is front-loaded.

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

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

With no output schema, the description compensates by naming the returned metrics and warning about gram units, which is what an agent most needs to interpret results. Ordering, pagination shape and what happens on days without a weigh-in are left unstated, keeping it just short of fully complete.

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

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

Schema description coverage is 100%, so the schema already explains inclusive date bounds and accepted formats ('today', 'N days ago'). The description adds only the long-range chunking/366-day constraint, 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 resource (every weigh-in in the range) and enumerates the metrics returned (BMI, body fat, muscle mass, water), which clearly separates it from siblings like garmin_get_weight_goals or garmin_get_day. It never names a sibling explicitly, so it is clear but not sibling-routing.

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 bulk/cut progress' gives one concrete use case, which implies the context for calling it. There is no guidance on when to prefer this over garmin_get_day or garmin_get_weight_goals, and no exclusions.

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

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

The description adds real information beyond the annotations: ranges are fetched in chunks automatically and are capped at 366 days. That chunking and cap behavior is not visible in the schema or the readOnly/idempotent hints, and it directly affects how a large range request will behave. It does not describe the shape of a goal record, 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 short sentences with no filler, and the scoping constraint is front-loaded ahead of the chunking note. The first sentence is a fragment rather than a full statement, which slightly weakens the structure.

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

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

The tool is a simple two-parameter read with no output schema, so the description should mention what a weight goal contains. Instead it never says whether goals are target weights, dates, or progress figures, so an agent cannot tell what the response holds.

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 start_date and end_date formats and defaults spelled out, so the schema carries the parameter burden. The description adds only the range cap, not parameter-level meaning, 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 is a noun phrase, 'Weight goals in effect during the range,' that largely restates the name and title. The addition of 'in effect during the range' does specify the temporal scope, but there is no verb and no differentiation from the sibling garmin_get_weight, which an agent could easily confuse with this.

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

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

No guidance is given about when to use this tool instead of garmin_get_weight or any other sibling. The agent must infer that this returns goal targets rather than measured weights, entirely from the name.

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 safety. The description adds real value beyond them: automatic chunked fetching and a 366-day cap, which tells the agent how long-range calls behave. Return shape is unspecified, 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?

Two tight sentences, purpose front-loaded, with the chunking caveat second. 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?

For a simple two-parameter read with full schema coverage and complete safety annotations, the description gives everything needed to call it correctly. Only the return payload shape is left implicit, which is minor given no output schema.

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 start_date and end_date formats/defaults are fully documented in the schema. The description only alludes to a 'range' without adding syntax beyond that; baseline 3 fits.

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 ('Wellness activity summaries') with concrete examples (breathwork, relaxation sessions) and scope ('for the range'). This distinguishes it reasonably well from step/sleep/stress siblings, though it doesn't explicitly name a contrasting 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?

Usage is only implied via 'for the range'; there is no statement of when to prefer this over garmin_get_day or garmin_get_daily_summaries. The chunking note is helpful operational context but not selection 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 the safe read-only, idempotent, non-destructive profile, so the description adds the ordering guarantee ('newest first') and the summary field set that comes back. It does not spell out paging behavior beyond the schema's offset, but the ordering and content disclosure are meaningful additions.

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 scope sentence is front-loaded, followed by two compact examples and one routing hint; every sentence carries information an agent needs to call the tool or find the sibling. Nothing is redundant with the schema.

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

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

Six optional parameters, a 100% description-covered schema and annotations that cover the safety profile mean the description only needed to add ordering, output shape and sibling routing — which it does. With no output schema, listing the returned fields compensates well.

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 100% schema description coverage the baseline is 3, but the description goes beyond the schema by showing how parameters combine for a realistic query (start_date + activity_type, limit=5). It gives practical meaning to activity_type and start_date rather than restating their definitions.

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

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

The first sentence names a specific verb ('List') and resource ('recorded activities'), states ordering ('newest first'), and enumerates the key returned fields (distance, time, pace, heart rate, training effect, training load). This clearly distinguishes it from garmin_get_activity (single activity) and garmin_get_activity_splits.

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 worked examples that map natural-language requests ('my runs this month', 'last 5 activities') to concrete parameter values, and explicitly routes the agent to garmin_get_activity_splits when per-km splits are wanted. The alternative tool and the condition selecting it are both named.

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