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

No annotations are provided, so the description carries full behavioral burden. It reveals the returned fields, which is useful, but omits pagination behavior (default limit=20 is in schema only), whether results are sorted, permission scoping, and rate limits. For a read-list tool with no annotations at all, this is thin.

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 front-loaded sentences with zero waste: purpose first, return fields second. Efficient, but the return-field list is a bare enumeration rather than a structured breakdown and slightly inflates length for a simple list tool.

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

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

An output schema exists, so explaining return values is optional and the field enumeration is redundant-but-harmless. However, with zero annotations and 0% schema coverage, the description leaves pagination, date format, and activity_type value space undocumented, which is a real gap for a 4-param tool in a crowded sibling set.

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

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

Schema description coverage is 0% across all 4 parameters, so the description must compensate. It names 'type and date range' filters, loosely mapping to activity_type, start_date, and end_date, but supplies no format details (e.g., ISO dates), no enum values for activity_type, and never mentions the limit parameter.

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 ('List activities') with scope qualifiers (optional filters by type and date range). Clearly distinguishable from garmin_activity_detail, garmin_trends, and garmin_week_summary by its listed-record purpose. Missing explicit sibling differentiation, but the verb+resource is precise.

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 through 'optional filters by type and date range', giving a soft context, but never states when to use this tool versus alternatives like garmin_activity_detail, garmin_trends, or garmin_query. No exclusions or alternative-routing guidance is provided.

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?

There are no annotations, so the description carries the behavioral burden. It discloses the return composition ('summary plus splits, HR zones, weather, and exercise sets') and a conditional availability caveat ('if available'), but does not explicitly state read-only behavior, side effects, or permission requirements.

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 short, front-loaded with the core purpose, then parameter usage, then return composition. Every sentence contributes useful information with 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?

An output schema exists, so return values need not be detailed, yet the description helpfully previews them. It is nearly complete for a two-parameter detail tool, though it does not explain how to obtain an activity_id or address edge cases like both parameters being supplied.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by explaining both parameters: activity_id selects a specific activity, and last=True retrieves the most recent activity. It does not clarify ID format or what happens if both are provided, but it adds substantial meaning beyond the bare integer and boolean fields.

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

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

The description states a clear verb ('deep-dive') and resource ('a single activity'), which distinguishes it from list-oriented siblings like garmin_activities. It does not explicitly name an alternative sibling, so it falls short of the highest bar for sibling differentiation.

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 tells the agent how to invoke the tool ('Pass activity_id, or set last=True'), but gives no guidance on when to prefer it over alternatives such as garmin_activities or garmin_activity_trackpoints. Usage is implied by the 'single activity' scope rather than explicitly 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?

No annotations, so the description carries the full burden: it discloses the ~1/sec sampling rate, resulting volume (a 1-hour activity ~3600 points), pagination mechanics, and that the response includes total_count. This is strong disclosure of size/performance traits, though it says nothing about auth requirements or rate limits.

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 payload contents, then behavior, then use-case routing. Four short sentences, each earning its place; only minor redundancy between the field list and the 'best for' examples.

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

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

An output schema exists, so return values need not be restated, and the description covers everything else an agent needs: what is returned, how large it gets, how to page, and when to pick a lighter 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 0%, so the description must compensate. It explains limit/offset as the paging mechanism but gives no format, defaults (500/0), bounds, or meaning for activity_id beyond the implicit name. Partial but not full compensation for the coverage gap.

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 ('GPS trackpoints for an activity') and enumerates the fields returned (lat/lon, altitude, distance, speed, HR, cadence, power, temperature) in chronological order. It distinguishes itself from garmin_activity_detail without the agent needing to open 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?

Provides an explicit 'Best for:' list (elevation profile, HR drift, GPS track inspection, pacing, climb segmentation) and names the alternative with the condition that selects it ('For aggregate stats ... prefer garmin_activity_detail — much smaller output'). When-to-use and when-to-use-something-else are both 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?

No annotations are provided, so the description must disclose behavior. It implies a read-only listing but says nothing about caching, freshness, permissions, or any other behavioral trait. With no annotations, this is a notable gap.

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

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

A single, front-loaded sentence that conveys the core purpose without any waste.

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

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

An output schema exists, so return value details need not be explained. However, as a no-annotation, no-parameter reference tool, the description omits when it is useful relative to siblings, leaving an agent to infer its role.

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

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

The tool takes zero parameters, so there is nothing to document. The baseline of 4 applies as the description appropriately does not invent parameter details.

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 ('activity type definitions') and its content ('IDs and parent categories'), making the purpose clear. It doesn't explicitly distinguish itself from siblings like garmin_schema or garmin_activities, but the resource is specific enough.

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 indication of when or why to call this tool versus alternatives such as garmin_schema or garmin_activities. The description only says what it returns, not when it is useful (e.g., for resolving activity type IDs).

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?

No annotations are provided, so the description carries the behavioral burden. It signals a read-only retrieval by describing returned content, and the presence of an output schema covers return-value structure. It doesn't confirm the operation is a safe read or mention pagination or scope limits, leaving mild gaps.

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 lines are front-loaded with the core content and earn their place by enumerating examples of what counts as a badge. There is minimal waste, though the final line 'Shows progression over time' is somewhat 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 parameterless read tool with an output schema defining the return shape, the description is nearly sufficient. It explains what badges represent and examples, missing only a note on read-only nature or scope, which the output schema largely covers.

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 are zero parameters, so the baseline is 4. Nothing needs explaining, and the description correctly doesn't invent parameter details.

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 ('Earned badges and achievements with dates') and adds categories like distance PRs and streaks. It's clearly about a read of badge/achievement data, but it doesn't distinguish from the closest sibling, garmin_records, which likely also surfaces PRs. The verb is implied (retrieve/list), not stated.

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 when-to-use guidance and no mention of alternatives. With garmin_records and garmin_challenges present as potential overlaps, the agent gets no help deciding which tool to call for milestone 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?

With no annotations, the description carries the full burden and partially meets it: it discloses a hardware prerequisite, that data only exists 'if tracked', and that outliers are flagged using AHA thresholds (>140/90 mmHg). That flagging rule is genuinely useful behavioral context beyond the schema. It stops short of covering auth needs, empty-result handling, or time-window 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?

Two short sentences, front-loaded with what the tool returns and then the prerequisites and flagging behavior. No filler or restated boilerplate; every clause carries 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?

An output schema exists, so return structure need not be explained, and the description covers the key behavioral facts (prerequisite, conditional availability, outlier flagging) plus the data returned. The one meaningful gap is that the 'days' window parameter is undocumented in both schema and description.

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

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

The single parameter 'days' (default 90) has 0% schema description coverage, and the description never mentions it at all. The agent gets no confirmation of what the timeframe controls or its limits, so the description fails to compensate for the schema gap. Nothing beyond the raw field name is added.

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

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

The description names a specific resource (blood pressure) and enumerates the exact readings returned (systolic/diastolic/pulse), so an agent knows precisely what data this yields. It is effectively the only blood-pressure tool among the siblings, so differentiation is implicit rather than stated. The 'if tracked' qualifier adds useful scope without muddying the purpose.

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 a prerequisite ('requires a compatible Garmin blood pressure monitor') and a conditionality hint ('if tracked'), which is adjacent to usage guidance. However, it never states when to choose this over related siblings like garmin_health_summary or garmin_heart_rate, and names no alternatives or exclusions. This is prerequisite disclosure, not usage 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?

With no annotations, the description carries the full behavioral burden. It does disclose the analytical enrichment (overnight charge vs daytime drain, wake-up level, deep-sleep correlation), which is genuine behavioral context, but it omits data freshness, permissions, and how the correlation is computed.

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 purpose is front-loaded in the first clause, with supporting detail following. It is short and wastes little, though much of the body is spent enumerating return values that the output schema already covers.

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

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

An output schema exists, so return values need not be explained, yet the description devotes most of its length to them while omitting usage context and the `days` parameter. Adequate but with clear gaps for a metric-retrieval 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?

The single `days` parameter (default 14) has 0% schema description coverage and is never mentioned in the description. Since there is one real parameter rather than zero, the baseline-4 rule does not apply and the description fails to compensate for the documentation gap.

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

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

The description names a specific resource (Body Battery) and its analytical framing (charge efficiency and drain analysis), so an agent can tell it retrieves a specific wellness metric. It does not, however, differentiate itself from adjacent metrics like garmin_recovery, garmin_sleep, or garmin_stress, which also touch overnight charging and drain concepts.

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 reach for this tool versus alternatives, nor any prerequisites or exclusions. The agent is left to infer usage purely from the metric name among ~47 siblings.

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?

No annotations are provided, so the description carries the full behavioral burden, and it adds almost nothing: it doesn't say what time window is returned, whether data requires a synced device or account, or how freshness is handled. The presence of an output schema offsets the need to describe return values, but behavioral context is otherwise missing.

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, which is appropriately sized for a no-arg reader. It is a noun phrase rather than a full clause, so it reads slightly as a label than an instruction.

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

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

With no parameters and an output schema, the description needn't explain the return payload, so it is close to sufficient. However, for a 'history' tool with no parameters, the agent has no idea what period or granularity is covered, which is a meaningful omission.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The only missed opportunity is that a param-less history tool could clarify its default range.

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 specific resource — weight, BMI, and body composition history — plus trend analysis, so an agent knows what data comes back. It does not state an explicit verb or differentiate itself from overlapping siblings such as garmin_trends, garmin_health_summary, or garmin_wellness_activity, which all plausibly surface similar longitudinal data.

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 garmin_trends, garmin_health_summary, or the other metric-specific tools. With ~50 siblings in the namespace, the absence of a routing hint is a real gap.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the conditional 'consumed (if logged)' availability and that data is drawn from two sources (daily_summary plus the calories table), which is genuine behavioral context. It says nothing about permissions, time-zone handling, or the aggregation window.

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 metric breakdown and followed by a brief data-source note. No filler, though the second sentence is arguably optional given the 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?

The output schema covers return values, so the description needn't explain them. However, for a tool exposing only a 'days' window, the description never clarifies the time range or how the daily breakdown behaves across multiple days, leaving a real gap for a 1-param 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?

The single 'days' parameter (default 14) has 0% schema description coverage and is never mentioned in the description. The description says 'Daily' with no indication that a configurable multi-day window exists, so it fails to compensate for the schema gap.

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

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

States a specific verb+resource ('Daily calorie breakdown') and enumerates the exact metrics returned (total, active, BMR, consumed). It clearly distinguishes itself from unlisted calorie-related siblings, though it doesn't explicitly differentiate from overlapping summaries like garmin_health_summary or garmin_today.

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 use this tool versus alternatives such as garmin_health_summary, garmin_today, or garmin_week_summary, which likely also surface calorie data. Usage can only be inferred from the metric list.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that both active and completed challenges are returned, which is a scope trait beyond the schema, but it says nothing about read-only status, authentication/privacy scope (own challenges vs. global), or result size limits.

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 phrase with no filler. It is efficient, though the terseness borders on under-specification rather than pure concision.

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

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

An output schema exists, so return values need not be described, and a zero-parameter tool is inherently simple. Still, the description omits whose challenges are returned and how the result set is bounded, which an agent would benefit from knowing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 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 the resource (Garmin Connect challenges) and scopes it to active and completed, so an agent knows what data it fetches. However, it is a bare noun phrase with no verb and no differentiation from similar siblings such as garmin_badges or garmin_goals, leaving the agent to infer the distinction.

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 indication of prerequisites, and no named alternative. The agent must infer that this is the right tool for a challenges query purely 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?

No annotations exist, so the description carries full behavioral burden, yet it only discloses the return shape ('deltas and percentage changes'). It does not confirm this is a read-only operation, nor mention permissions, rate limits, or any constraints. Since an output schema already exists, restating the return content adds little.

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

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

Three short sentences with the core purpose front-loaded and no filler. Efficient, though the third sentence partly duplicates what the output schema already conveys.

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 comparison tool with an output schema, the definition is close to complete, but it omits the two things an agent most needs: the date format for four required string params and the distinction from garmin_trends. With no annotations to fall back on, these gaps matter.

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

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

Schema coverage is 0% and the four date parameters carry no format specification in either schema or description. The phrase 'two date ranges' confirms the intent of the start/end pairs, but nothing explains the expected date string format (e.g. ISO vs epoch), leaving a real gap for this all-required parameter set.

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 ('compare') and resource ('two date ranges across all health metrics'), so the agent understands exactly what it does. It does not differentiate from siblings like garmin_trends or garmin_week_summary, which appear to cover overlapping time-comparison territory.

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?

'Useful for week-over-week, month-over-month, or year-over-year analysis' implies the intended context, so usage is inferable rather than stated. There is no explicit when-not guidance and no mention of the obvious alternative (garmin_trends) that an agent would have to choose between.

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?

No annotations are provided, so the description carries the full burden, yet it only states the data category. It says nothing about how many days are returned, ordering, pagination, auth requirements, or any behavioral limits beyond the example types.

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 with no filler; every clause earns its place by naming the resource and giving examples.

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

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

An output schema exists, so return values need not be described, and the tool is simple with one optional parameter. However, with no annotations and zero parameter documentation, the description should have covered the 'days' window to be fully actionable.

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

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

The single parameter 'days' has 0% schema description coverage (only a default of 7), and the description never mentions it. An agent cannot learn from either source what 'days' controls or its valid range.

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

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

Names the resource ('Daily events detected by your Garmin') and clarifies it with concrete examples (stress spikes, body battery events), so an agent knows it returns a curated event list rather than raw metrics. It does not distinguish itself from overlapping siblings like garmin_stress or garmin_body_battery, which the examples partially collide with.

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 guidance and no mention of alternatives, despite close siblings (garmin_stress, garmin_body_battery, garmin_today) that an agent could confuse it with. Usage is only implied by the 'daily events' 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?

No annotations are supplied, so the description carries the full behavioral burden, and it discloses almost nothing: no indication that this is a read-only operation, no auth/account-scope requirements, no note on whether it reflects a live Garmin Connect sync or cached data, no pagination or empty-state behavior. For a zero-parameter tool the risk surface is small, but the disclosure gap is still real.

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 key noun front-loaded. It is efficient, though the sentence fragment style means it reads as a label rather than a usable instruction.

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

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

An output schema exists, so return values need not be explained and there are no parameters to cover, which makes the definition minimally complete. What is missing is the surrounding context an agent needs to choose this tool over its many siblings - the description stops at describing the payload rather than the action.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the description misleads about inputs.

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

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

The description names the resource (connected Garmin devices) and what each entry contains (type and last sync time), which is more than a tautology. However it is a noun phrase with no verb - it never says whether the tool lists, retrieves or syncs devices - and it does nothing to distinguish itself from adjacent configuration-style siblings such as garmin_gear or garmin_user_profile.

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 call this tool, what question it answers, or how it relates to any of the ~46 sibling tools. An agent must infer usage entirely from the name and one-line summary.

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?

No annotations are provided, so the description carries the full burden, yet it discloses nothing about behavior beyond the returned data shape. It omits whether authentication is required, how the 'days' window affects results, and whether data is cached or rate-limited.

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 wasted words, and the core content (endurance score, VO2max, classification, trend) is front-loaded. Brevity here shades into under-specification rather than being genuinely efficient.

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

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

An output schema exists, so return values need not be explained, and the tool is a simple single-parameter read. However, the 'days' parameter semantics and the overlap with garmin_vo2max remain unresolved, leaving a modest gap for an agent choosing between 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?

The single 'days' parameter has 0% schema description coverage, and the description never mentions it, so neither source explains that it controls the lookback window (defaulting to 30). With one undocumented parameter, the description fails to compensate for the schema gap.

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

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

The description names a specific resource (endurance score) and the data it returns (VO2max with classification and trend), so an agent knows what it fetches. It does not differentiate from sibling garmin_vo2max, which likely surfaces overlapping VO2max data, leaving ambiguity about which to call.

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 the alternative garmin_vo2max for VO2max-only needs, and no condition that selects this tool. The only signal is the tool name itself.

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?

No annotations are provided, so the description carries the full behavioral burden. It adds useful interpretation of the widening/narrowing gap and states the aggregation period, but it does not disclose read-only safety, data availability, time-range constraints, or other operational 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 front-loaded, compact, and every sentence adds value. It defines the metric, the aggregation, and the interpretation without unnecessary 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?

The tool is simple with one optional parameter and an output schema, so the description does not need to explain return values. It covers the metric meaning, aggregation options, and interpretation, though it omits when to prefer this tool over adjacent fitness metrics.

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

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

Schema description coverage is 0%, so the description must compensate for the single period parameter. It does so by stating that results can be aggregated by week or month, though it does not mention the schema default of month.

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

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

The description states a specific verb and metric: it shows fitness age vs chronological age trajectory, aggregated by week or month. It clearly identifies the resource, but it does not explicitly distinguish this tool from sibling Garmin metric tools such as garmin_vo2max or garmin_training_status.

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 explains how to interpret the metric, which implies it is a query tool, but it does not say when to use this tool versus garmin_vo2max, garmin_training_status, or other fitness-related siblings. There are no explicit when-to-use or when-not-to-use guidelines.

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?

No annotations are provided, so the description carries the full burden. It discloses only that output is daily and includes an ascent/descent breakdown; it says nothing about the default lookback window behavior, data freshness, or whether values are totals vs per-day, and never confirms the read-only nature of the 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?

A single compact sentence with the metric front-loaded and no filler. It is efficient, though its brevity is partly the source of the missing parameter and usage guidance rather than deliberate economy.

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

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

An output schema exists, so return-value explanation is not needed, and the metric itself is simple. However, with no annotations and an undocumented 'days' argument, the definition is thin for even a simple tool — the agent lacks the query-window and usage context it needs.

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 sole parameter 'days' has 0% schema description coverage and is not mentioned in the description at all; 'Daily' implies a granularity but does not explain what the days argument controls. With one undocumented parameter and no compensating text, the description leaves the agent guessing about the query window.

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 (floors climbed) and adds scope (daily, vs goal, ascent/descent breakdown), which distinguishes it from adjacent metrics like garmin_steps or garmin_hill_score. It never uses a verb, but the noun phrase is unambiguous about what data the tool returns.

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, when not to, or how it differs from the many similar metric siblings (garmin_steps, garmin_hill_score, garmin_goals). The agent must infer the use case entirely from the metric 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?

With no annotations, the description carries the full behavioral burden. It implies a read-only lookup and mentions usage stats, but says nothing about scope (all gear vs. filtered), whether gear must be registered in Garmin first, or any auth/rate considerations.

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 tight sentence with the resource and examples front-loaded and no filler. It is appropriately sized, if a touch thin.

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 zero-parameter retrieval tool with an output schema covering return values, the description is mostly adequate. However, it leaves the scope of 'tracked gear' and the nature of 'usage stats' unexplained, which a short retrieval tool could easily have clarified.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter detail is needed or missing.

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 (gear/equipment) with concrete examples (shoes, bikes) and notes the payload (usage stats). An agent can tell it returns tracked equipment data. It stops short of differentiating from neighbors like garmin_devices, but the resource is unambiguous.

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

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

The description offers no when-to-use guidance, no conditions, and no mention of alternatives such as garmin_devices or garmin_activities. The agent must infer appropriate usage entirely.

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

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

With no annotations, the description carries the full behavioral burden, yet it only implies a read by saying 'current progress'. It does not say whether goals are user-scoped, whether completed/expired goals are excluded, or whether any auth is needed. Minimal disclosure for a zero-annotation 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 short sentence is appropriately sized for a no-parameter tool and wastes no words. However, it is a bare noun phrase rather than a front-loaded statement of action, so brevity here reflects under-specification as much as economy.

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

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

An output schema exists, so return values need not be spelled out, and with zero parameters the surface area is small. Still, the description omits any indication of scope (single user, time window, active-only filtering) that an agent would need to trust the result.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics for the description to clarify or omit.

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 names the resource ('active fitness goals') and what is returned ('their current progress'), but has no verb and never states that this is a retrieval operation. Against a sibling list full of similarly named Garmin data endpoints, an agent can infer the domain but gets no explicit action.

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 statement, no mention of alternatives such as garmin_challenges or garmin_training_status, and no prerequisites or date-scoping note. The description offers no guidance beyond the label itself.

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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states what is measured but doesn't mention authentication needs, rate limits, data latency, or any operational constraints. For a read-only tool, the description could at least confirm it's a read operation and note that results depend on the user having performed recent snapshots.

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 concise sentences that front-load the core purpose. No wasted words; every sentence adds useful information about what the tool returns and where the data comes from.

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?

Given the tool has no parameters, no annotations, and an output schema exists (so return format need not be described), the description provides sufficient context for an agent to understand what the tool delivers. It could be improved by mentioning when to prefer it over individual metric tools, but overall it's complete for a zero-parameter data retrieval 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?

The tool takes zero parameters, so parameter semantics are not a concern. The description appropriately focuses on output content instead. Baseline 4 applies for zero-parameter tools.

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 states it returns on-demand Health Snapshot readings (2-minute wrist measurements) capturing HR, HRV, SpO2, stress, and respiration. It distinguishes itself from the many individual metric tools (garmin_hrv, garmin_spo2, garmin_heart_rate, etc.) by noting the simultaneous capture of all these metrics. However, it doesn't explicitly name which siblings are alternatives.

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 noting these are 'manual measurements taken via the watch's Health Snapshot feature,' which suggests when such data exists. However, it provides no explicit guidance on when to choose this tool versus garmin_health_summary or individual metric tools, nor does it mention limitations 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose meaningful traits: the output consists of averages over a range and aggregates multiple source tables (daily_summary, sleep), which tells the agent this is a read/aggregation operation. However, it never confirms read-only safety, date format expectations, or any limits.

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, front-loaded sentences that drop straight into scope and then defaults with no filler. The only blemish is the unresolved template placeholder '*days* days', which reads as an artifact rather than intent.

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 read aggregation with an output schema, so return-value detail is not strictly required, and the description does cover the range/default mechanics. What is missing and materially useful is differentiation from the many overlapping summary siblings, plus basic date-format expectations.

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

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

Schema description coverage is 0% and the parameter titles are bare ('Days', 'End Date', 'Start Date'), so the description must compensate and partly does: it explains that omitting the dates falls back to the most recent 'days' window (default 7 per schema). It still omits date format, range bounds, and whether the three parameters interact in other ways.

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 action ('Health overview for a date range') and enumerates the metrics returned (steps, HR, stress, body battery, SpO2, respiration, calories, sleep, training readiness). This is far more concrete than a tautology, but it never distinguishes itself from close siblings such as garmin_health_snapshot, garmin_week_summary, or garmin_today.

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 and no named alternatives, despite a crowded sibling set containing overlapping health-summary tools. The only conditional given ('if start_date/end_date are omitted...') concerns parameter defaults rather than tool 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?

With no annotations, the description carries full behavioral burden and does disclose non-obvious traits: it returns daily RHR plus a rolling 7-day average and flags days exceeding the rolling average by >5 bpm, with interpretation of those flags. It omits the standard traits (read-only nature, permissions, rate limits), but the analytical behavior and detection threshold are genuinely useful 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?

Three tight sentences, front-loaded with the core purpose, then the return shape, then the anomaly logic. No filler or restatement of the name; each sentence adds 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?

For a single-parameter read tool with an output schema, the description covers purpose, return contents, and the anomaly heuristic, which is nearly everything needed to call it. The only gap is the undocumented 'days' parameter, which the output schema does not compensate for.

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?

One parameter ('days') exists with 0% schema description coverage and a default of 30, so the description is the only place semantics could be supplied. The description never mentions the configurable time window, so an agent cannot tell that the lookback period is adjustable or what unit it uses.

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 ('Resting heart rate') and specific analyses ('trend analysis and anomaly detection'), so the agent knows exactly what data it produces. However, it does not differentiate from close siblings like garmin_hrv, garmin_recovery, or garmin_health_summary, so an agent comparing H/R-related tools gets no routing signal.

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 a use case (spotting illness/overtraining from the anomaly flags) but never states when to call this versus garmin_hrv, garmin_recovery, or garmin_trends. No explicit when/when-not guidance or prerequisites are given, 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure and delivers almost nothing. It does not state whether this is a read-only computed metric, what data window is used by default, whether authentication/sync is required, or whether values are cached or computed on the fly. The only behavioral hint is the sub-score decomposition.

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 short, front-loaded sentence with no filler, which is structurally clean. But given the complete absence of annotations and the undocumented days parameter, the brevity reads as under-specification rather than efficient conciseness.

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

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

An output schema exists, so return values need not be described. Still, with no annotations at all, an undefined days parameter, and no routing guidance among ~50 sibling tools, the definition is not sufficient for an agent to invoke this correctly with confidence.

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 a single 'days' parameter with a default of 30 and 0% schema description coverage, so neither the schema nor the description explains what the window means or how it affects the score. The description does not mention the parameter at all, leaving the semantics entirely undocumented.

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 Garmin metric ('hill score') and clarifies it decomposes into endurance and strength sub-scores, which adds a bit beyond the tool name. However, there is no verb and nothing distinguishes it from closely related siblings like garmin_endurance_score, garmin_vo2max, or garmin_race_predictions. The purpose is inferable but not sharp.

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 on when to use this tool versus the many other score/summary siblings (garmin_endurance_score, garmin_training_status, garmin_fitness_age). There are no exclusions, no prerequisites, and no mention of the time window implied by the days parameter. The agent must guess from the name alone.

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

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

With no annotations, the description carries the full behavioral burden. It discloses what the tool returns (baseline range, balanced/unbalanced streak, trend, above/below baseline), which is useful output behavior. It does not describe permissions, data freshness, read-only nature, or other operational traits, so it remains only partially complete.

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 short, front-loaded, and every sentence earns its place. It first names and contextualizes the resource, then explains the specific value over raw HRV numbers without 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?

For a simple one-parameter read tool with an existing output schema, the description covers the main purpose and output semantics well. It still omits any explanation of the 'days' parameter and gives no operational context, so an agent lacks a complete picture of how to invoke it meaningfully.

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

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

The single parameter 'days' has 0% schema description coverage and is never mentioned in the description. The schema supplies a name, integer type, and default of 30, but neither the schema nor the description explains whether it is a lookback window, a comparison window, or how it affects the returned baseline and trend calculations. The description therefore does not compensate for the coverage gap.

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 the specific resource (HRV) and spells out the distinctive outputs: personal baseline range, consecutive BALANCED/UNBALANCED days, trend direction, and above/below-baseline status. It distinguishes itself from raw HRV numbers, but does not name specific sibling tools such as garmin_heart_rate or garmin_recovery, so sibling differentiation remains 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?

The contrast with 'raw HRV numbers' implies this tool should be used when clinical interpretation and baselines matter rather than raw values. However, there is no explicit when-to-use guidance, no exclusions, and no named alternative tool among the many Garmin siblings, leaving usage context 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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about read-only semantics, whether zones are Garmin defaults or user-customized, or whether the result is per-activity-type. 'Configured in your Garmin profile' gestures at static configuration but does not confirm it.

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, appropriately front-loaded. It loses a point only because the sentence fragment lacks a verb, making it read as a label rather than an instruction.

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 simple (0 params, output schema present so return shape need not be explained), but with no annotations the description should still confirm the read-only nature and whether the zones are defaults or user-set. It is minimally adequate rather than 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?

The input schema has zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No misleading parameter hints are present.

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

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

The description names a specific resource (heart rate zone definitions) and scopes it to the user's Garmin profile, which implicitly distinguishes it from garmin_heart_rate (measured data) and garmin_lactate_threshold. However, it is a bare noun phrase with no verb, and it never names the sibling it is not, so an agent must infer the read-fetch nature.

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 tool versus garmin_heart_rate, garmin_vo2max or garmin_lactate_threshold, and no stated prerequisites or coverage notes. The agent must derive usage entirely from the tool name and the presence of siblings.

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?

No annotations are provided, so the description carries the full burden. It adds meaningful behavioral context by explaining that the goal is calculated from activity, weather, and body weight and that under-hydration days are flagged, which helps interpret output. However it says nothing about auth requirements, data availability, or the meaning of the 'flags' output beyond the analysis itself.

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

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

Front-loaded with the core statement ('Daily hydration intake vs goals'), followed by a compact explanation of the comparison logic. Every sentence earns its place; 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?

An output schema exists, so return values need not be described. For a read-only data query the description covers purpose and analysis adequately. The main gap is the undocumented time-range parameter, but overall it is complete enough to call the 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?

The single parameter (days, default 30) has 0% schema description coverage, and the description does not mention it at all. It never clarifies what the time window means, acceptable range, or that the default is 30 days. The word 'Daily' hints at granularity but does not document the parameter.

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 (daily hydration intake) and the analysis performed (compares intake against Garmin's calculated goal, flags under-hydration days). An agent can distinguish it from generic siblings like garmin_goals or garmin_health_summary. It lacks an explicit sibling differentiation statement, but the resource is unambiguous.

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

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

The description never states when to use this tool versus alternatives such as garmin_goals or garmin_health_summary. Usage is only implied by the resource it describes. No prerequisites, no exclusions, no 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?

With no annotations, the description carries the burden but does add real domain behavior: vigorous minutes count double per WHO guidelines, and it reports goal attainment. It does not disclose data source, freshness, or permissions, but the metric semantics it explains are genuinely useful context.

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

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

Three short sentences, front-loaded with the tool's purpose, with no filler. Efficient and readable, though the second sentence's parenthetical could be integrated more tightly.

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

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

An output schema exists, so return values need not be explained, and the metric semantics are covered. However, the unexplained 'days' parameter and absence of usage context leave gaps for a tool in a very large sibling set.

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 lone parameter 'days' (default 30) is not mentioned in the description and has 0% schema description coverage. There is even a mild tension between the description's 'weekly' framing and a 'days' window parameter, which the description does not reconcile.

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 (intensity minutes) and its key metric (weekly totals vs WHO's 150 min/week), which clearly separates it from siblings like garmin_steps or garmin_calories. It lacks an explicit action verb, but the read-only nature and subject matter are unambiguous.

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

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

There is no guidance on when to use this versus alternatives such as garmin_week_summary, garmin_trends, or garmin_training_load. No prerequisites or context for choosing this tool are provided.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It describes the data returned but says nothing about read-only nature, authentication requirements, data freshness, or any limitations. The output schema exists, but the description adds no behavioral traits beyond the raw data definition.

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

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

The description is three short sentences, front-loaded with the key information about what is returned, followed by a concise definition and use case. Every sentence is brief and contributes context without 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 read-only tool with no parameters and an output schema, the description is nearly complete. It conveys what the tool returns and its purpose. The only gap is guidance on when to prefer it over related metrics, but that is a minor omission given the tool's specificity.

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 are no parameters, so the schema itself is trivial and complete. The description does not need to add parameter semantics, and the baseline for zero parameters is 4.

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 states the resource (lactate threshold pace and heart rate) and adds a scope qualifier ('by sport'). It distinguishes from siblings like garmin_hr_zones or garmin_vo2max by focusing on lactate threshold, but it lacks an explicit verb such as 'Get' or 'Retrieve', keeping it from a perfect score.

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 an implied use case ('Used to set training zones and pace targets for races'), which tells the agent why the data is relevant. However, it does not state when to use this tool versus alternatives like garmin_hr_zones or garmin_training_status, nor does it offer any 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?

With no annotations, the description carries the full behavioral burden. It doesn't say whether the data is read-only (implied), what time window is used, whether results are cached or rate-limited, or what the focus_status values mean. It states what is reported but nothing about behavior or constraints.

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 short and front-loaded, leading with the primary measure. It is slightly redundant in restating the zone breakdown in a second sentence, but it remains efficient.

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?

Since an output schema exists, the description needn't explain return values, and it correctly avoids that. However, for a no-annotation tool, it leaves the time window, data source, and interpretation of focus_status unaddressed, which is a gap for an analytics 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?

There is a single 'days' parameter (default 28) with 0% schema description coverage, so the description could have clarified it but does not. With one parameter and zero coverage, the description adds no meaning beyond the schema; baseline 3 is appropriate.

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

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

Names the specific measure (training load distribution) and enumerates the zones it reports, so the purpose is clear. It does not, however, differentiate itself from the closely related sibling garmin_training_load, which an agent could easily confuse it with.

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 such as garmin_training_load or garmin_training_status. The reader must infer the use case purely from the noun phrase describing the output.

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

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

With no annotations, the description carries the behavioral disclosure burden and does well: it states that the database is opened in SQLite read-only mode at the engine level, so writes, ATTACH, and schema changes are impossible regardless of SQL content. It also states the result row cap and default. It does not cover error behavior or auth requirements, but the key safety constraints are clearly disclosed.

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

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

The description is three short sentences, front-loads the core purpose, and then adds only the safety and row-cap details needed to use the tool correctly. There is 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?

The output schema exists, so return-value explanation is not required, and the read-only behavior is well covered. However, for a generic SQL query tool with no annotations and 0% parameter schema coverage, the description should probably point to the schema or table/column reference, especially given the many topic-specific sibling 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 description coverage is 0% for two parameters. The description adds meaning for 'limit' by saying results are capped at *limit* rows with a default of 1000, but it provides no detail about the required 'sql' parameter beyond calling it a SELECT query. With 0% schema coverage, more compensation was needed for the main parameter.

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

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

The description states a specific verb and resource: run a SELECT query against the Garmin database. It also scopes the operation as read-only, but it does not explicitly differentiate this generic query tool from the many metric-specific sibling 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 the many specific Garmin tools such as garmin_activities or garmin_sleep. It implies ad-hoc querying by saying 'Run a read-only SELECT query,' but gives no explicit guidance or alternatives.

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

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

With no annotations provided, the description carries the full burden. It usefully discloses an interpretive trait: rising prediction times mean declining fitness and falling means improving, which prevents an agent from misreading the trend. However, it says nothing about auth, rate limits, or how the 'days' window affects results, leaving meaningful gaps for an unannotated 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?

Three short, front-loaded lines with no wasted words; the resource is stated first and the trend interpretation follows. Structure is efficient though the line breaks are slightly fragmented.

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

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

An output schema exists, so return-value explanation is unnecessary and the description reasonably focuses on purpose and trend interpretation. But with no annotations and an undocumented parameter, the definition leaves the agent without when-to-use or parameter 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 description coverage is 0% for the single 'days' parameter, so the description must compensate, but it never mentions the parameter. The phrase 'daily predictions' hints at a time series but does not explain that 'days' controls the lookback window or its default of 30.

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 (predicted race finish times) and enumerates the distances covered (5K, 10K, half marathon, marathon), which is concrete and distinct from most siblings. It does not explicitly differentiate from adjacent tools like garmin_records, garmin_vo2max, or garmin_trends, but the resource is specific enough that an agent can identify it.

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 purpose (retrieve fitness-based race time predictions), but there is no explicit when-to-use guidance, no prerequisites, and no named alternatives. An agent can infer intent but gets no routing help.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it only restates the data returned ('activity details and dates') — content the output schema already defines. It says nothing about read-only semantics, authentication/account requirements, data freshness, or whether records are user-scoped, all of which an agent would want to know before calling.

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 that identifies the resource and its payload with no filler. It is efficient, though it is lean to the point of omitting any usage or scope context.

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 zero-parameter tool with an output schema, the description covers the essentials (what the records are and that they include dates/details) and the schema handles return structure. However, it omits scope and freshness context — e.g., whether PRs are all-time or per-activity-type — that would make the definition fully self-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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics to clarify and no ambiguity the description could resolve.

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 concrete resource ('personal records (PRs)') and the enrichment it carries ('activity details and dates'), so an agent knows exactly what data comes back. The verb is only implied ('All ... records'), and it does not explicitly distinguish itself from siblings like garmin_activities or garmin_goals, but the resource is specific enough to identify.

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 call this versus alternatives such as garmin_activities or garmin_goals, nor any prerequisite (e.g., sync freshness) or scope caveat (all-time vs. recent). The agent must infer usage entirely from the resource 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?

With no annotations, the description carries the full burden and does disclose the operative behavior: it filters to activities above a load threshold and reports RHR/HRV on subsequent days to build a recovery curve. It does not mention auth needs, rate limits, or how the output scales with the window, but the core mechanics are revealed.

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, followed by mechanism and then differentiation. Efficient overall, though the marketing line 'This is unique' leans on self-promotion rather than additional routing 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?

An output schema exists so return format need not be explained, and the purpose/mechanism are covered. However, for a parameterized tool with no annotations, the entirely undocumented days_after parameter leaves a real gap in an otherwise complete definition.

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

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

Schema coverage is 0% and the single parameter days_after has no description. The text refers to 'the following days' but never maps this to days_after, its default of 3, or the units/limits, so the description fails to compensate for the undocumented parameter.

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

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

The description states a specific verb and resource ('analyze how your body recovers after hard training sessions') and even specifies the computation (RHR and HRV for days following activities with training_load > 80). The closing claim of uniqueness tells the agent this is not subsumed by siblings like garmin_hrv or garmin_training_load.

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 use case (post-hard-training recovery) and states the internal threshold (training_load > 80), but gives no explicit when-to-use vs when-not guidance and does not name an alternative tool to prefer for adjacent needs. Usage is left to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it never states that this is a read-only operation, whether it needs account auth, or any rate-limit/freshness behavior. The reference-range and interpretation content is domain context, not operational behavior.

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

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

Front-loads the returned metric in the first sentence, then adds compact clinical context. Three short sentences with little waste, though the interpretive sentence is slightly tangential to invocation.

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

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

An output schema exists, so return-format details are covered and the description needn't explain them. For a simple read tool this is nearly adequate, but the lone 'days' parameter is undocumented in both schema and description, leaving the time dimension unexplained.

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 one parameter (days, default 14) at 0% schema description coverage, and the description never mentions it or explains that it controls the lookback window. The single parameter's meaning must be inferred, so the description fails to compensate for the coverage gap.

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: 'Waking respiration rate with min/max range.' An agent knows it returns respiration data with a range. However, it gives no differentiation from the many other Garmin health-metric siblings (garmin_hrv, garmin_stress, garmin_spo2, garmin_heart_rate).

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 and no mention of alternatives among siblings. The clinical interpretation ('elevated respiration at rest can indicate illness, stress...') tells the agent how to read the value, not when to call this tool rather than garmin_hrv or garmin_health_summary.

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

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

With no annotations, the description carries the full burden, and it does disclose the key branching behavior — the default call omits column lists and returns only row counts plus the names of empty tables, while a tables argument narrows output to just those tables' columns. It does not mention read-only status, auth, or limits, but those are minor for a schema 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?

Front-loaded with the core capability, then two tight sentences covering each mode with zero filler. Every sentence earns its place and the example is embedded efficiently.

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 introspection tool with an output schema present, nothing an agent needs is missing: both calling modes, the parameter format, and the default behavior are all 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 0% — the lone 'tables' parameter has no schema description — so the description must compensate, which it does: it specifies a comma-separated list format, gives the concrete example "sleep,stress", and explains the empty/default 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 and resource: 'Show table columns and row counts' — a schema/introspection capability that is self-evidently distinct from the data-fetching siblings (garmin_sleep, garmin_query, etc.). It does not, however, explicitly name or contrast itself with any sibling, so an agent must infer the distinction.

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?

Clearly distinguishes the two invocation modes: called without *tables* it returns an index; with a comma-separated list it returns columns for those tables. This tells the agent how to drive the tool, though it never names alternatives (e.g., that this is a discovery aid for garmin_query) or states 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses return granularity ('each night individually, not averages'), which is real behavioral context beyond the schema, but says nothing about permissions, rate limits, data availability windows, or pagination. Output schema coverage means return values need not be re-explained.

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 primary capability and followed by the one distinguishing behavior (per-night granularity). No filler; every sentence carries signal.

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

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

An output schema exists, so return values need not be documented. The description covers purpose and return granularity adequately, but leaves the two input parameters completely unspecified, which is a meaningful gap for a range-query tool.

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

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

Schema description coverage is 0% for two parameters (days, start_date), and the description never mentions either. It neither explains the default window nor the interaction between days and start_date, so it fails to compensate for the schema gap.

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 (sleep) and enumerates its contents (stages, SpO2, stress, Garmin feedback) with the granularity (per-night rather than averages). It is clear what the tool returns but gives no explicit differentiation from siblings like garmin_spo2, garmin_stress, or garmin_hrv, which cover overlapping 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?

The phrase 'for pattern analysis' implies a usage context (trend/pattern work over multiple nights), which is a weak pointer. There is no explicit when-to-use guidance and no named alternative or exclusion criteria versus the many other Garmin health tools.

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

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

No annotations are provided, so the description carries the full burden. It does disclose useful behavior beyond the schema: the clinical thresholds applied (95% average, 80% nocturnal low) and that it merges daily_summary and a dedicated spo2 table. It does not state auth/permission needs or whether the threshold flagging alters the returned data versus adding annotations.

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

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

Three short sentences, front-loaded with the primary purpose, with threshold detail following. No filler, though the final sentence about data sources is somewhat redundant given an output schema exists.

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

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

An output schema exists so return values need not be explained, and the description covers what the tool analyzes. However, the lone days parameter is left unexplained, which is a real gap for an agent deciding how to invoke it.

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

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

There is one parameter (days, default 14) and schema description coverage is 0%, so the description should compensate but instead never mentions the parameter or its time-window meaning. Because there is one undocumented parameter rather than zero, this falls below the 3 baseline.

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 states a specific resource (Blood oxygen / SpO2) and a specific analytical behavior (clinical threshold analysis), so an agent knows exactly what this returns. It does not name sibling tools to route away from, but the purpose is unmistakable against the many garmin_* health 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?

Usage is implied by the topic (retrieve SpO2 data with concern flagging), but there is no explicit when-to-use or when-not guidance relative to alternatives like garmin_health_summary or garmin_health_snapshot. Nothing tells the agent which tool to prefer for oxygen data versus a general health pull.

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

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

With no annotations, the description carries the full burden, but it does confirm this is a read-only daily-metric summary and discloses the derived outputs (percentage of goal, longest streak). It says nothing about pagination, timezone handling, or behavior when no goal is set, which is a real gap for a metric 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?

Two short sentences, front-loaded with the core resource and followed by the derived metrics. No filler, no repetition of the tool name.

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

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

An output schema exists so return values needn't be explained, and the description covers the essential outputs (daily steps, goal percentage, streak). The only missing piece is guidance on the undocumented 'days' parameter and usage 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 0% for the single 'days' parameter, so the description must compensate. It implies a day-range scan but never states the parameter name, its default of 14, or acceptable bounds, leaving that entirely to the schema title.

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

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

States a specific metric (daily step count) plus the derived analytics it returns (goal attainment, streaks). It is clearly distinct from siblings like garmin_activities or garmin_intensity_minutes, though it does not explicitly name a differentiating alternative the way a 5 would.

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 when-to-use guidance, no mention of the default 14-day window in prose, and no routing to alternatives such as garmin_trends or garmin_today. The agent must infer usage 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 are absent, so the description carries the full burden. It implies a read-only aggregation ('shows how many hours per day') and the output content, but says nothing about the default 14-day window, data freshness, or any limits. Because an output schema exists, the explicit list of returned fields is largely redundant with structured 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?

Short and front-loaded: the zone breakdown leads, and the supporting sentence adds scope detail without padding. The line breaks are cosmetic but harmless; no sentence is wasted beyond the redundant return-value recap.

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

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

For a simple one-parameter read tool with an output schema, the definition is minimally adequate: the agent knows what data comes back. It falls short on the undocumented `days` parameter and on any usage context relative to the many sibling wellness 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?

The single `days` parameter has 0% schema description coverage, so the description must compensate — and it does not. 'Per day' hints at daily granularity but the parameter's meaning, its default of 14, and valid ranges are never explained.

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

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

The description gives a specific verb-free but clear resource statement — stress data with a time-in-zone (low/medium/high) breakdown — which distinguishes it from siblings like garmin_heart_rate or garmin_body_battery. However, it never names or contrasts against those siblings, so the differentiation is implicit rather than explicit.

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

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

There is no guidance on when to use this tool versus garmin_today, garmin_health_summary, garmin_recovery, or other wellness tools. No prerequisites, no exclusions, no alternative named. The agent must infer usage entirely from the title.

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

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

With no annotations, the description carries full burden and does well: it discloses the background execution (~2 minutes), that the first call returns status 'started', and the required follow-up call, explaining the timeout rationale. It omits edge cases like concurrent-sync behavior or failure states, keeping it short of 5.

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

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

Front-loaded with the core action, then behavior, then use cases. Every sentence adds value, though the parenthetical about Claude Desktop timeouts is slightly verbose for the space it occupies.

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

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

An output schema exists so return values need no explanation; the description covers purpose, timing, the parameter, and invocation triggers. It is complete enough for correct use, with only minor gaps around error/concurrency handling.

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

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

The single parameter has 0% schema description coverage, so the description must compensate, and it does: 'Set refresh=False to just check the current state and last sync result without triggering a new sync' fully explains the flag's 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 ('Sync the latest data from Garmin Connect'), and the async-refresh behavior makes it clearly distinct from the read-only siblings (garmin_query, garmin_activities, etc.) that only fetch already-synced data.

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 this when:' list with three concrete triggers (just finished a run/ride, want today's health data loaded, data looks outdated) and clarifies the refresh=False mode. It stops short of naming alternatives or stating when NOT to use it, but the context is clear.

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?

No annotations are supplied, so the description carries the full behavioral burden. It discloses the composition of the snapshot, which is useful, but says nothing about that it is a read-only aggregate, whether it hits live API versus cache, latency, auth requirements, or rate limits. Adequate but with clear gaps for a tool with zero annotation coverage.

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

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

Two sentences, both earning their place: the first defines contents, the second defines role and call priority. Front-loaded with the payload summary, zero 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?

An output schema exists, so the description is not obliged to describe return values, and it correctly focuses on scope and role instead. It is nearly complete for a zero-param aggregate, with the only residual gap being the absence of any behavioral/operational detail (cache vs live, permissions) that no annotation supplies.

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

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

The tool takes zero parameters, so there is no parameter semantics to document. Baseline of 4 applies; the description correctly does not invent or misdescribe any 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?

Specific verb-and-resource framing ('Complete snapshot of today's health') with an explicit enumeration of the six data categories it returns (daily summary, sleep, training readiness, HRV, body battery, latest activity). That is enough to distinguish it as an aggregate rollup. It does not, however, explicitly contrast itself with near-neighbour siblings like garmin_health_summary or garmin_health_snapshot, whose names imply overlapping scope.

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

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

Gives clear usage direction: 'Ideal as conversation context — call this first to ground any health question.' That tells the agent both when to reach for it (session grounding / open-ended health questions) and its priority relative to other tools. It stops short of naming an alternative or an exclusion (e.g. when to prefer a focused tool like garmin_hrv or garmin_sleep 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?

With no annotations, the description carries the full behavioral burden; it usefully explains the semantics of each computed metric (42-day vs 7-day EWMA, TSB = CTL - ATL), which is genuine added context. It does not disclose permissions, cost, computation windows relative to 'now', or caching behavior, so the mutation/IO profile is only partially 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?

Front-loaded purpose sentence followed by a tight bulleted list; no filler prose. Slight redundancy in enumerating returns, since an output schema already exists and covers them.

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

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

An output schema exists, so the return-value list is largely duplicative, while the description omits the more valuable missing piece: how this differs from its many training-related siblings. Complete enough to call, but not complete for selection in a crowded tool space.

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 has nothing to document and the baseline is 4. The description correctly implies the computation is derived from stored activity history with no caller-supplied filters.

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 ('compute ... training periodization metrics from activity history') and names the metric family (CTL/ATL/TSB), which distinguishes it reasonably from generic status tools. However, it never explicitly contrasts with close siblings like garmin_training_status or garmin_load_focus, so a borderline case remains.

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 when-to-use guidance at all, and no mention of alternatives despite several overlapping siblings (garmin_training_status, garmin_load_focus, garmin_trends). The agent must infer the selection condition from the metric names alone.

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

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

With no annotations, the description carries the full burden. It discloses what the tool returns (daily classifications, status counts, transitions), which is useful behavioral context, but it does not explicitly state that this is a read-only operation or mention any auth, rate-limit, or safety considerations.

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 front-loaded with the core purpose and remains reasonably tight. Each sentence contributes something, though the parenthetical examples and breakdown detail could be trimmed slightly.

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

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

The tool is simple and an output schema exists, so return values need not be explained. However, the description omits the optional 'days' parameter and there are no annotations to cover safety or behavior, leaving a clear gap for correct parameterized use.

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

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

Schema description coverage is 0% and the description never mentions the 'days' parameter or what it controls. The name and default are self-evident, but the description adds no semantic meaning beyond the raw schema.

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

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

The description states a specific resource (training status history) with the possible values and explains that it shows daily Garmin classifications, breakdowns, and transitions. It is clear on its own but does not explicitly differentiate itself from relevant siblings such as garmin_training_load or garmin_recovery.

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 offers a use case ('spotting detraining before it deepens'), which implies when the tool is useful, but it does not state when to choose this over alternatives or include any exclusions. The guidance is implied rather than explicit.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it only describes what data is returned. It does not disclose the default time window, how many periods are returned, whether data must be synced first, or any auth/rate-limit behavior, leaving significant gaps for a data-retrieval 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?

The core purpose is front-loaded in the first sentence, followed by the metric enumeration and the period values. The metric list is long but necessary since it is not in the schema; otherwise there is no wasted prose.

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

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

With an output schema present, return-value details need not be explained, and the parameter values are covered. However, the tool has no date-range parameter, so the description should clarify what time window the trend covers by default, which it omits.

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

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

Schema description coverage is 0%, but the description compensates strongly: it enumerates all valid metric values (a full enumeration absent from the schema) and specifies the acceptable 'period' values ('week' or 'month'). This adds real semantic meaning beyond the bare string-typed parameters.

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

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

The description states a specific verb and resource ('Return trend data for a metric aggregated by week or month') and enumerates the supported metrics, so the agent knows exactly what it produces. It does not, however, explicitly differentiate itself from the many metric-specific siblings (garmin_steps, garmin_stress, garmin_hrv), which is left to inference.

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

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

Usage is only implied by the phrase 'aggregated by week or month', suggesting this is the tool for rolled-up trends rather than raw daily data. There is no explicit when-to-use, when-not-to-use, or named alternative even though dozens of per-metric siblings exist that an agent could confuse it with.

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

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

With no annotations, the description carries the full behavioral burden, yet it says nothing about whether the call is read-only, whether it requires authentication/consent, or what scope of profile data is returned. Because there are zero parameters, the risk of a destructive action is low, but the omission of any behavioral context is still a gap.

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

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

A single, waste-free sentence that front-loads the resource. It is appropriately sized but arguably under-specified rather than genuinely concise, which keeps it out of the top band.

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

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

An output schema exists, so the description need not explain return values, and the tool's zero-parameter simplicity limits what must be covered. Still, given the crowded sibling namespace, the absence of any routing or usage cue leaves the definition only minimally 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?

The tool takes no parameters and schema description coverage is 100%, so there is nothing for the description to clarify. Baseline of 4 applies for a zero-parameter tool.

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

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

The description names the resource ('User profile and settings') and locates it in Garmin Connect, which distinguishes it from siblings like garmin_devices, garmin_goals, or garmin_hr_zones. However, it supplies no verb or action, so an agent must infer that this is a retrieval tool rather than a settings-mutation tool. Purpose is implied but not stated.

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 indication of when to call this tool, what triggers it, or how it differs in use from the many other Garmin data tools. No alternatives are named despite ~48 sibling tools. The agent is left to infer usage 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?

No annotations are present, so the description carries the full burden. It discloses that results are merged from activity-level estimates and a standalone VO2max table, which is useful provenance. It does not state read-only/safety profile, recency, sync requirements, or any operational limits, so transparency remains incomplete.

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 brief and front-loads the resource, but the second sentence largely restates the first instead of adding new detail. It could be reduced to one sentence with the provenance 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?

For a zero-parameter read tool with an output schema, the description identifies the metric and data provenance sufficiently to call the tool. It still omits any routing guidance relative to sibling health metrics and says nothing about operational behavior, leaving some contextual gaps.

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 are zero parameters, so the schema has no parameter semantics to explain; baseline is 4. The description does not need to compensate for missing parameter documentation.

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

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

States the resource (VO2max estimates) and the two data sources (activity-level and standalone table), so an agent knows it returns VO2max data rather than general activity details. It does not explicitly name a verb like retrieve/list or contrast with siblings such as garmin_fitness_age, but the metric is distinctive.

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 when-to-use guidance, no exclusions, and no mention of alternatives among the many Garmin sibling tools. The agent must infer that this is the VO2max-specific tool from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the exact metric set and the goal-comparison framing, but says nothing about data freshness/sync requirements, permissions, or that the time window is fixed (no range override).

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 waste; the core scope (current week, totals vs goals) is front-loaded and the second sentence only adds the metric enumeration that the reader needs.

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

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

With an output schema present and no parameters, the description need not explain return values, and it covers scope and metric coverage adequately. The remaining gap is routing context - nothing tells the agent why to pick this over garmin_today, garmin_health_summary, or garmin_trends.

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, which is the baseline-4 case. The description correctly implies no inputs are needed by scoping everything to the current week, and adds nothing misleading about parameterization.

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

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

States a specific resource and scope: the current week's health totals versus goals, with a per-day breakdown, and enumerates the four metrics covered. It is clearly distinguishable from daily tools like garmin_today by its weekly rollup framing, but it never explicitly names or contrasts a 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 by the 'current week' scope - an agent can infer this is the weekly rollup tool. There is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as garmin_today, garmin_trends, or the per-metric tools (garmin_steps, garmin_floors, garmin_calories).

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?

No annotations, so the description carries the full burden. It discloses the payload contents (start/end times, activity type) which is useful behavioral context, but says nothing about auth needs, rate limits, or default time window behavior. Partial disclosure against full burden.

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 resource definition, and no filler. The second sentence is slightly redundant on the separation point but still 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?

An output schema exists so return value structure need not be explained, and the tool is simple (1 param). However the undocumented 'days' parameter and the absence of any usage routing leave gaps for an agent with many overlapping activity siblings.

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

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

The single parameter 'days' has 0% schema description coverage and no default is explained as a lookback window. The description never mentions time-range scoping at all, so it fails to compensate for the undocumented parameter.

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 sessions) with concrete examples (yoga, breathwork) and explicitly distinguishes these non-sport sessions from regular activities. This gives good differentiation from siblings like garmin_activities, though it does not name them directly.

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 clause 'tracked separately from regular activities' implies when this tool applies versus the general activity tools, but no explicit when-to-use condition or named alternative is given. Usage is inferable rather than instructed.

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

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

With no annotations supplied, the description carries the full behavioral burden. It does disclose the two categories of data returned (saved workouts and scheduled dates), which is meaningful context. But it never states that this is a read-only, side-effect-free operation, nor anything about date scoping, pagination, or auth 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?

Three short lines, front-loaded with what the resource is, then what it returns, then why it matters. The first line slightly overlaps with the second (library/schedule vs saved workouts/dates), a minor redundancy rather than bloat.

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

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

An output schema exists, so return structure need not be explained, and there are no parameters to cover. The description adequately answers what the tool is and what it returns; only the safety/behavioral profile (read-only, no side effects) is missing, which no annotations supply.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. The description correctly implies the tool is unfiltered, which is consistent with the empty 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 gives a specific verb+resource: it returns saved workouts (training plans, custom workouts) plus scheduled workout dates. That is far more informative than the title alone. It does not, however, explicitly distinguish itself from adjacent siblings like garmin_training_load or garmin_today, so an agent must infer the boundary.

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 offers an implied use case ('useful for understanding planned vs executed training') but gives no explicit when-to-use rule, no exclusions, and no named alternative for planned-workout questions versus executed-activity questions. The framing is helpful but leaves selection to inference.

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