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 operation but does not state that it is read-only, what happens if the activityId is invalid, or any size/pagination behavior for the heavier includes like details. For a data-fetch tool this leaves notable 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?

Two short sentences with no filler. The resource and selector are front-loaded, and the include options follow immediately, making it easy to scan.

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

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

For a two-parameter getter with no output schema, the description covers the purpose and the include enum reasonably well. It still omits usage context (when to call this vs list_activities) and any behavioral caveats, so it is adequate but not fully complete.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning by listing the include options and clarifying that 'details' means GPS/HR/power streams, which is not explicit in the enum alone. This is genuine added semantic value over the schema.

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

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

The description states a specific resource ('a single activity') and identifies the key selector ('by activityId'), so the agent can tell it retrieves one activity record. It does not explicitly contrast with list_activities or the other get_* siblings, but the singular scope is clear 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 when-to-use guidance or alternatives are given. The schema note '(from list_activities)' hints at provenance, but the description never says when this tool is preferable to list_activities or how to obtain an activityId. Usage is only implied.

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

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

With no annotations and no output schema, the description carries the full behavioral burden, yet it discloses nothing about authentication, rate limits, data freshness, units, or what a partial or empty response looks like. The only behavioral hint is that multiple metrics can be requested at once, which is already evident from the array schema.

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

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

Front-loaded and short, which is good, but the long enumeration of all fourteen metric names duplicates the schema verbatim and consumes most of the description's length without adding information. Structure is fine; content density is low.

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 multi-metric aggregation tool with no annotations and no output schema, the description should at least hint at the return shape, units, or timezone handling. It provides none of that, leaving the agent unable to anticipate what each metric key contains.

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

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

Schema description coverage is 100%, including the date format/pattern and the metrics enum and defaults, so the schema already fully documents both parameters. The description merely re-lists the enum members rather than adding meaning such as units, granularity, or how metrics interact. Baseline 3 applies.

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

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

States a clear verb-resource pairing: returning daily wellness metrics for a given date. An agent can distinguish this from siblings like get_training, get_weight, and get_activity, which cover different data domains. It stops short of explicitly naming what it is not, so a 5 is not warranted.

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 the many similar-looking siblings (get_fitness, get_activity, get_steps_history), nor any stated prerequisites or exclusions. The only selection advice offered is about picking metric values, which is parameter-level, not tool-level.

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 must carry the burden. It indicates a read-only retrieval of device information, but does not disclose any potential limitations, authentication requirements, or response size 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?

A single sentence that is clear, direct, and contains no unnecessary words. Every element conveys meaning.

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 zero parameters and no output schema, the description adequately covers the tool's purpose and expected return fields. It could be improved by mentioning the scope (all paired devices) and potential limitations.

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?

No parameters exist, so schema coverage is 100%. The description adds value by listing the output fields (model, firmware, last sync), which is helpful for the agent. Baseline for 0 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?

Clearly states the tool returns Garmin devices paired to the account, with specific fields (model, firmware, last sync). This distinguishes it from sibling tools like get_weight or get_user_profile which focus on different 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?

The description implies usage when a list of paired devices is needed, but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria.

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 burden. It does disclose a genuine behavioral trait: four metrics are date-agnostic (startDate/endDate are ignored for them) while the other four honor the range. It says nothing about permissions, return shape, or whether mixed metric groups are supported in a single 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?

Two tight clauses, front-loaded with the resource then the grouping rule. Little waste, though the parenthetical grouping is dense and slightly awkward to parse on first read.

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

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

For a 3-parameter read tool with no output schema and no annotations, the description covers metric selection well but leaves open whether date-agnostic and range-based metrics can be requested together, and gives no hint of return structure. Adequate but with visible 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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the enum listing: it annotates which enum values are latest-only versus date-range-scoped, and clarifies that startDate/endDate only matter for half the metrics. That is information the schema enum does not convey.

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

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

The description names the resource (fitness/performance metrics) and the selection mechanism (the `metrics` array), which is more specific than the bare name. It does not differentiate from siblings such as get_training or get_daily_health, which could plausibly overlap with performance data, so it stops short of a 5.

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

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

It implies when each metric applies by splitting them into date-agnostic (latest only) and range-based groups, which is a useful selection rule. However, it offers no explicit when-to-use vs when-not-to-use guidance and never mentions alternatives or overlap with get_training/get_daily_health.

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 but discloses almost nothing: no read-only confirmation beyond the 'get' prefix, no pagination behavior, no default ordering, and no note on what an empty result means. For a zero-annotation tool this is a substantial 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 short sentence with the resource front-loaded and no wasted words. It is efficient, though the terseness borders on under-specification rather than optimal brevity.

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

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

For a two-parameter, zero-required-parameter read tool with fully documented schema and no output schema, the description is minimally sufficient. It omits any note on default behavior or return semantics, which keeps it at a bare-adequate level.

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

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

Schema description coverage is 100%, so both the limit (1-50, default 30) and status enum are fully documented in the schema. The description only restates the status values and adds nothing about the limit or default behavior, so the baseline 3 applies.

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

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

The description names the resource (goals) and the filtering dimension (status with enumerated values), so an agent knows this is a goal-retrieval tool. It does not explicitly state a verb like 'list/retrieve' or call out its distinctness from the health/fitness siblings, but the resource is unique enough to be 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 tool versus alternatives, no prerequisites, and no mention of the sibling tools. The status filter is the only implied usage signal, and it is not framed as a decision point.

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

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

No annotations, so the description carries the full burden. It discloses the default-month behavior but nothing about return format, whether the calendar is sparse or filled, auth needs, or pagination. 'Calendar' hints at structure but is not elaborated.

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

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

Single short sentence, front-loaded with the resource and default. Efficient, though the slash phrasing is slightly terse.

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?

Adequate for a 2-param read whose schema is fully covered, but with no annotations and no output schema, the description leaves the return shape and sibling differentiation to inference.

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

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

Schema coverage is 100%, so both year and month are fully documented with types, bounds, and defaults. The description only restates the default-month behavior already present in the schema.

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

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

States a specific verb/resource relationship: retrieving scheduled workouts as a calendar for a month. It's distinguishable from get_workouts (likely completed sessions) by the 'scheduled' qualifier, though it doesn't explicitly name the contrast.

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

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

No indication of when to use this vs get_workouts or get_training. The calendar/month framing implies a schedule view, but no exclusions or alternatives are named.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals a Garmin-specific 28-day cap for daily granularity and states default date ranges, but omits return format, pagination, and any auth or rate-limit 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?

Two short sentences, front-loaded with the core purpose and then the key granularity constraint and default. Every sentence carries useful information and there is no filler.

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

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

For a simple read tool with three optional parameters, no annotations, and no output schema, the description covers the main behavior, defaults, and a critical timeout-like cap. It could mention the return shape, but it is otherwise complete enough to call correctly.

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

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

Schema description coverage is 100%, so the baseline would be 3. The description adds one meaningful constraint not present in the schema: daily granularity caps the span at 28 days. The default values it restates are largely redundant with the schema.

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

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

The description states a clear resource and scope: step totals over a date range, with daily or weekly granularity. It does not explicitly differentiate itself from siblings like get_daily_health or get_training, but the purpose is understandable without further 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?

It explains granularity options and defaults, but gives no guidance on when to use this tool versus sibling tools such as get_daily_health or get_training. There are no prerequisites or when-not-to-use conditions.

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 beyond the basic scope. It does not state that this is a non-mutating read, whether authentication or a connected device is required, what happens when no data exists for the date, or how much data is returned per metric.

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

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

Two short sentences, front-loaded with the resource and scope before the parameter hint. The only redundancy is restating the metric enum values that the schema already lists.

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

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

For a two-parameter, all-optional read tool with full schema coverage, the description is adequate but thin. With no output schema and no annotations, it should say more about the shape of the returned data per metric and the no-data case.

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

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

Schema description coverage is 100% and both parameters are fully documented in the schema, including defaults and the date pattern, so the baseline of 3 applies. The description's enumeration of metric values duplicates the enum already present in the schema rather than adding new meaning.

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

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

The description names a concrete resource ('training metrics') and scopes it to a date, then enumerates the available metric kinds, so an agent knows exactly what comes back. The verb is implicit in the 'get_' name, and it draws no boundary against near-siblings like get_fitness or get_daily_health, which is what keeps it from a 5.

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

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

There is no statement of when to reach for this tool versus get_fitness, get_daily_health, or get_activity. 'Pick via `metrics`' is parameter guidance, not usage guidance, and no prerequisites or exclusions are given.

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

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

No annotations are present, so the description carries full burden. It hints at a read operation but does not confirm safety or disclose any prerequisites, error conditions, or side effects. The behavioral traits are inadequately communicated.

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 one sentence, efficiently conveying the purpose without redundancy. It uses a list format with examples for clarity, and every word serves a purpose.

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

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

With no output schema, the description partially compensates by listing example data categories. However, it could be more explicit about the full return structure. Given the tool's simplicity and sibling diversity, this is nearly adequate.

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 baseline is 4. The description adds value by listing the categories of data returned (units, preferences, activity level), which helps the agent understand the output content.

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 tool retrieves user profile and settings including units, preferences, and activity level. It is specific and distinguishes itself from sibling tools like whoami (basic identity) and get_weight (specific metric).

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 for getting profile/settings data but does not explicitly state when to use this tool versus alternatives like get_daily_health or get_training. No exclusion criteria or alternative suggestions 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 provided, the description carries the full disclosure burden. It does reveal useful behavior: the default window (~4 weeks) and the effect of include_raw (individual weigh-ins included). It omits auth/permission requirements and any note on data granularity or pagination limits, so it is only partially transparent.

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: resource and metrics first, then the optional flag, then the default window. Every sentence carries information and nothing is padded.

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

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

For a simple read tool with zero required params, full schema coverage and no output schema, the description covers the resource, the returned metrics, the flag behavior and the default range. Only minor gaps remain, such as no mention of the date format or whether ranges are inclusive, both of which the schema largely handles.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, including the same default values quoted in the description. The description essentially restates the include_raw and default-range semantics, adding no format or constraint detail beyond the structured fields.

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

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

The description names a specific resource and enumerates the exact metrics returned (weight, BMI, body-fat %) plus the raw-entry option, so an agent can distinguish it from siblings like get_daily_health or get_activity. It stops short of explicitly naming which sibling to use for other health metrics, so it earns a 4 rather than a 5.

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

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

Usage is implied by the resource and the stated default range ('last ~4 weeks'), which tells the agent this is the weight-tracking read. There is no explicit when-to-use versus when-not-to-use guidance or reference to an alternative tool for related body metrics.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it says nothing about read-only behavior, pagination, default page size, or ordering. Only a weak implication that this is a read operation can be inferred from the phrase 'saved workouts'.

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 brief, but the brevity is under-specification rather than conciseness - a single nominal fragment with no verb and no front-loaded actionable information. Nothing is wasted, but almost nothing is delivered either.

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 annotations, no output schema, and a bare noun phrase, the definition is inadequate for an agent to confidently invoke the tool. It should at minimum state that it lists workouts for the authenticated user and describe pagination behavior.

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

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

Schema description coverage is 100% and the single 'limit' parameter is fully documented in the schema with range and default. The description adds nothing about parameters, so the baseline of 3 applies.

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

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

The fragment 'Saved workouts on the account' identifies the resource and the qualifier 'saved' loosely distinguishes it from the sibling get_scheduled_workouts. However it contains no verb at all, so the agent must infer that this is a retrieval/list operation, leaving the purpose only implied.

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

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

There is no when-to-use guidance, no conditions, and no mention of alternatives among the many siblings (get_scheduled_workouts, get_training, list_activities). The agent receives nothing to route on.

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 burden. It usefully discloses the default no-date behavior (returns most recent) and the limit=1 shortcut, which is real behavioral value. But it says nothing about auth/permissions, pagination, ordering, or how many results come back by default beyond the schema's stated default.

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

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

Two tight sentences with the default-case behavior front-loaded before the ranged/filtered case. No filler, though the parenthetical examples for type are partly redundant with the schema's own 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?

With no output schema and no annotations, this description is nearly sufficient: it covers invocation modes (default vs ranged vs filtered) and the key shortcut. The remaining gap is only return-shape and ordering, which is a modest omission for a list tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds intent for how parameters combine (dates and/or type filter the range) and a concrete limit=1 use case, which is slightly beyond the schema, but format/default details remain the schema's job.

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') and immediately scopes behavior by date/type, which distinguishes it from the singular get_activity sibling in practice. However, it never explicitly names get_activity or get_steps_history as alternatives, so sibling differentiation is inferential rather than 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?

Gives clear conditional guidance: omit dates for the most recent activities, use limit=1 for the last activity, pass startDate/endDate and/or type for a ranged/filtered query. Missing is any 'do not use this when...' or pointer to the detail tool get_activity for a single record.

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 provided. Description discloses read-only nature and return fields, but does not mention error behavior, authentication requirements, or what happens if not connected.

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

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

Single clear sentence with no unnecessary words. Efficient and front-loaded.

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

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

Adequate for a simple parameterless tool. Additional details about error handling could improve, but current description is sufficient for 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?

No parameters exist, schema coverage is 100%. Description confirms no input needed, adding minimal value beyond schema but sufficient.

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?

Clearly states it checks Garmin connection and returns account profile (display name, full name). Distinct from sibling tools that focus on specific data (weight, fitness, etc.).

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

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

Implies usage for verifying connection and basic profile, but does not explicitly guide when to use over get_user_profile (which might overlap). No exclusions provided.

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