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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Activities within a date range,' which does not explain behavior such as whether the date range is inclusive, how the activity_type filter behaves, how results are ordered, or whether the returned list is paginated. No contradictions exist, but the description is too 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?

The description is a single short sentence with no filler. It is front-loaded with the core concept, though it errs on the side of under-specification rather than verbosity.

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 schema is rich and there is an output schema, so the description does not need to explain return values or all parameter details. However, given the large sibling set (including garmin_recent_activities), the description should have provided more context on when this date-range tool is the right choice. It is minimally adequate but not complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter meaning, but the schema already documents start_date, end_date (with default 'today'), and activity_type as a 'Garmin type key filter'. Thus the description does not need to compensate.

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 (activities) and the scope (within a date range), which is enough for an agent to get the basic idea. However, it lacks a verb like 'list' or 'fetch' and does not explicitly distinguish itself from siblings like garmin_recent_activities or garmin_activity.

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 usage guidance is provided. The description does not say when to use this tool versus garmin_recent_activities (which may be more appropriate for recent activities) or garmin_activity (for a single activity). There are no exclusions or conditions 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?

With no annotations provided, the description carries the burden of disclosing behavior. It does so by specifying that the tool returns full detail and explicitly calls out running dynamics and strength sets, which tells the agent what specialized data to expect. It does not mention potential limitations or side effects, but as a read-oriented detail tool, none are critical.

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

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

The description is a single, front-loaded sentence with no filler. The core purpose appears first, followed by the key differentiators, making it easy for an agent to parse quickly.

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 definition is complete for the core use case: the description covers what the tool does, the schema documents parameters and the source of activity_id, and an output schema exists to define return values. However, given the large sibling set, an explicit pointer to alternatives like garmin_recent_activities or garmin_strength_sets would improve completeness.

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 already provides complete descriptions for both parameters, so the description adds little beyond what is structured. The mention of strength sets loosely aligns with include_sets, but it does not elaborate on parameter semantics. Baseline of 3 is appropriate given 100% schema coverage.

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 (one activity) and the scope (full detail), and the mention of running dynamics and strength sets distinguishes it from list-style sibling tools like garmin_recent_activities. Even without an explicit verb, the intent is unambiguous and contextually specific.

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 one activity' establishes clear context: this is the detail-retrieval tool for a single activity, as opposed to list or summary tools. It does not explicitly name alternatives or exclusions, but the schema hint that activity_id comes from garmin_recent_activities adds a practical usage linkage.

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 disclosure burden, but it only lists output categories. It does not describe read-only safety, how date defaults are applied, or behavior on days without data. The 'per day' clause gives some granularity, but most behavioral traits are absent.

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

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

The description is a single, telegraphic sentence with no filler, and it front-loads the metric and the key aggregates. It is compact for a simple date-range tool, though slightly noun-phrase-like rather than an explicit 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?

For a simple read-only metric tool, the schema covers parameters and the output schema covers return shape, so the description is mostly sufficient for invocation. However, missing usage guidance and behavioral context prevent it from being fully self-contained.

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 date parameters are already documented with format and default behavior in the schema. The description adds no new parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description names the specific resource, Body Battery, and enumerates the reported metrics: charged/drained plus high/low/latest per day. This clearly distinguishes it from sibling tools that cover other metrics like sleep, HRV, or stress. It lacks an explicit verb such as 'retrieve', but the meaning 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?

No guidance is provided about when to use this tool versus the many garmin_* siblings. The only cue is the tool name and metric name, forcing the agent to infer use cases. There is no when-not, alternative mention, or selection condition.

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 never explicitly states that this is a read-only list/retrieval operation, nor does it mention authentication, caching, or side effects. The noun-phrase form leaves the actual behavior inferred rather than 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?

One short sentence with no filler; the resource is named first and the purpose is appended compactly. Every word 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?

The output schema and zero parameters cover the return contract, and the push-context is helpful. However, with no annotations the absence of an explicit statement of what the tool actually does (retrieves/lists) leaves a real gap for an agent deciding whether invocation has side effects.

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 has zero parameters and the schema is empty, so there are no parameter semantics to document; the baseline for a 0-parameter tool is 4. The description adds relevant real-world meaning by explaining that the IDs are prerequisites for pushing a workout.

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 resource is named specifically: registered Garmin devices and their IDs, which clearly sets it apart from the many Garmin metrics/workout siblings. It lacks an explicit action verb like 'list' or 'get', so it does not fully meet the 5-level standard.

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 parenthetical '(needed to push a workout)' gives a clear use case: call this when you need a Garmin device ID for a push operation. It does not name alternatives or state when not to use it, but the intended context is evident.

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

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

With no annotations, the description carries the behavioral burden; 'all ... categories' does convey a complete, non-filtered lookup and implies a read-only operation. However, it stops short of explicitly stating that it is a static/list operation or disclosing any constraints, so there is a clear transparency 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?

The description is extremely short and front-loads the key scope with no filler. It is a fragment rather than a complete sentence, but it is appropriately minimal for a zero-argument category lookup.

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 zero-parameter schema and the presence of an output schema, the description is nearly complete for invoking the tool. It lacks only an explicit read-only statement and usage differentiation; otherwise an agent has enough to call 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?

The input schema has zero parameters, so the baseline is 4. The description correctly has no parameter information to add, and there are no undocumented arguments.

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 identifies the resource ('Garmin strength exercise categories') and scope ('all'), making it clear this is a category-list lookup and distinct from sibling tools like garmin_search_exercises or garmin_exercise_history. It earns a 4 rather than a 5 because it is a noun phrase without an explicit verb such as 'returns' or 'lists'.

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 alternatives such as garmin_search_exercises or garmin_resolve_exercise. The use case is only implied by the name and the word 'categories'.

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 transparency burden. It signals a read-only historical lookup by saying 'previous performance' and 'recent strength sessions,' but it does not disclose any limits, error behavior, or whether results are per-set or per-session. There is no contradiction, but details are minimal.

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 12-word sentence places the core result and scope first and the use case last. No wasted words.

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 historical lookup with a complete input schema and an output schema, the description gives enough to choose and invoke the tool. It could be more complete on grouping or units, but those are likely covered by the output schema.

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

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

Schema description coverage is 100%, so the schema already documents exercise, limit, and lookback_days. The description only adds the context 'one exercise' and 'recent sessions,' which is useful but does not materially extend 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 identifies the resource precisely ('one exercise across recent strength sessions') and the implied action is retrieving previous performance. It differentiates from siblings like search_exercises and strength_sets by scope, though it lacks an explicit verb such as '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?

The parenthetical '(for progression)' communicates a use case, but the description does not state when not to use it or name alternatives such as garmin_strength_sets for current session details. Guidance is present but only lightly 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?

With no annotations provided, the description carries the full burden of explaining behavior, but it only lists data fields. It does not disclose whether the 7-day average is based on the requested date, whether historical data is available, or any caveats about data availability or timezone handling.

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

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

The description is a single concise sentence that front-loads the core data content without filler or redundancy. Every word contributes to understanding what the tool returns.

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 an output schema and one optional parameter, the description conveys the main output fields. However, it omits important context such as how the 7-day average relates to the date parameter and provides no usage guidance relative to 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 100%, with the single 'date' parameter already documented as 'ISO date YYYY-MM-DD; defaults to today.' The tool description adds no parameter-specific detail, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource (heart rate) and the specific data returned (daily resting, min, max, and 7-day resting average), which distinguishes it from sibling tools like garmin_hrv or garmin_stress. It lacks an explicit verb like 'get' or 'retrieve', but the noun-phrase description 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 gives no guidance on when to use this tool versus alternatives such as garmin_today or garmin_hr_zones. There are no stated exclusions or conditions, so an agent must infer usage purely 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 burden of explaining behavior. It names the returned data categories, which implies a read-only retrieval of HRV metrics, but it does not disclose what happens for missing dates, how date affects weekly/baseline values, or timezone 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 a single, front-loaded sentence with no filler. Every phrase contributes meaning, identifying the metric and its key output components.

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-optional-parameter read tool with an output schema present, this description is largely sufficient. It names the metric categories, and the schema covers the date parameter. The only notable gap is lack of usage guidance, but that is addressed under usage_guidelines.

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 date parameter already includes format and default behavior in the schema. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies HRV as the resource and lists the exact fields returned: overnight status, last-night average, weekly average, and personal baseline. It distinguishes garmin_hrv from sibling tools like garmin_heart_rate or garmin_stress, though it lacks an explicit action verb like 'retrieves'.

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, nor any exclusions or conditions. An agent must infer from the tool name that this is only for HRV data and not for related metrics like recovery or training readiness.

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 disclosing behavioral traits. It only states what the zones are and that they come from Garmin, without saying whether the call is read-only, what happens if no zones are configured, or whether any side effects exist. The agent must infer a harmless getter from the tool name.

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 exactly two sentences with no filler. The core resource definition is front-loaded, and the preference rule is a single concise sentence that earns its place.

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

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

For a zero-parameter lookup with an output schema, the description covers the source, the sport-specific scope, and the key usage rule. It is largely complete, though it could optionally note the possibility that the user has no Garmin-configured zones.

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 is empty and description coverage is trivially 100%, so there are no parameter semantics to clarify. This fits the 0-param baseline of 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 identifies the resource as the user's Garmin-configured heart-rate zones and explicitly mentions sport-specific profiles, which distinguishes it from generic heart-rate or calculation-based tools. It lacks an explicit verb like 'retrieves', but the noun phrase plus the tool name makes the retrieval operation 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?

The instruction 'Always prefer these over calculating zones from age or max HR' explicitly tells the agent to choose this tool whenever zone thresholds are needed rather than deriving them from formulas. It provides a clear exclusion but does not enumerate sibling-tool alternatives for other heart-rate data needs.

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 carry the behavioral disclosure burden. It lists returned metrics but does not state that the operation is read-only, whether results vary by date, what 'where available' means in practice, or any other behavioral traits. The implied read-only nature is not explicitly stated.

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

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

The description is a single, tightly packed sentence that front-loads the key content. There is no filler or repetitive information, and every word contributes to the tool's 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?

For a simple one-parameter tool with a full output schema, the description conveys the essential metric categories. The vagueness of 'where available' is a minor gap, but the output schema and 100% parameter documentation cover most of what an agent 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 schema fully documents the single date parameter with a default and format, so the description does not need to repeat it. The description adds no extra meaning about how the date affects the returned metrics, but 100% schema coverage keeps this at the 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 names specific resources—VO2 max, lactate threshold, endurance/hill score, race predictions—making the tool's purpose clear and distinguishing it from siblings focused on sleep, heart rate, stress, etc. It lacks an explicit verb like 'retrieves' or 'returns', but the noun phrase is still informative and not a tautology.

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

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

No guidance is given on when to choose this tool over related siblings such as garmin_training_status or garmin_recovery. The phrase 'where available' hints at data limitations but does not provide decision rules 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 clearly discloses that the tool does not upload or persist anything ('WITHOUT uploading it') and asserts safety ('Always safe'), which is essential behavioral context for a preview 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 entire description is one focused sentence that front-loads the action and safety guarantee, then states the intended use. Every word earns its place 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?

For a preview tool with an output schema and fully documented parameters, the description provides the essential safety, purpose, and usage context. The 'verify structure first' guidance completes the picture for correct invocation.

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

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

Schema description coverage is 100%, and the schema already documents all three parameters, including the exercise block format. The description adds little parameter-specific detail, but the baseline of 3 is appropriate because the schema handles parameter semantics.

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

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

The description states a specific verb and resource: 'Build and show a strength workout'. It also explicitly differentiates from upload operations with 'WITHOUT uploading it', making the tool's role clear among its siblings.

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

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

The description gives clear guidance on when to use this tool: 'use this to verify structure first'. It implies this is a pre-upload validation step, though it does not explicitly name the alternative upload or save tool.

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. It does convey that output is summary-level, recent activity data, which implies a read-only listing operation. It does not describe ordering guarantees, empty-result behavior, or whether activity_type filters before/after applying the limit, but the simple read-only nature and output schema reduce the risk.

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 short, front-loaded sentence with no wasted words. Both 'most recent' and 'compact summaries' add meaningful scoping, and it does not repeat the tool name or restate schema fields.

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 input schema fully documents the two parameters, and an output schema exists, so return-value details do not need to be spelled out. The main gap is lack of guidance for choosing this over the many activity-related siblings, but for a simple list tool the core information is present.

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

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

Schema description coverage is 100%: both limit and activity_type already have descriptive text, including defaults, range, and an example type key. The tool description adds no parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the resource ('most recent activities') and the output form ('compact summaries'), so an agent can tell this returns a list of recent activity summaries. It lacks an explicit verb like 'retrieve' or 'list' and does not explicitly distinguish it from garmin_activities_by_date or garmin_activity, but the meaning 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?

Usage is only implied: 'most recent activities' suggests this tool is for quickly viewing recent activity summaries. However, it never tells the agent when to prefer this over garmin_activities_by_date, garmin_activity, or garmin_today, nor does it state any exclusions. With many siblings, more explicit routing would 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 burden. It discloses the composite, aggregating nature via 'Composite recovery view' and lists the included metrics, which implies a read-only operation. However, it does not address data availability, potential nulls, or how the date parameter affects the view.

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

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

The description is a single compact sentence that front-loads the core concept and then lists the specific metrics. Every word contributes, with no redundancy or 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 tool with one optional parameter and an output schema present, the description provides enough core content by naming the composite view and its components. It lacks guidance on sibling tool relationships, but the output schema presumably covers return structure, so the definition is largely 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 for the single 'date' parameter is 100% and its description already specifies the ISO format and default. The tool description adds no parameter-level meaning, so the baseline score of 3 applies.

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

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

The description identifies the resource as a 'composite recovery view' and enumerates five specific metrics (sleep score, HRV status, resting HR, Body Battery, stress), making it clear what the tool returns. It differentiates from individual-metric sibling tools, though it lacks an explicit verb like 'retrieves' or '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?

The word 'composite' implies using this tool when multiple recovery metrics are needed at once, but no explicit guidance is given about when to choose this over alternatives like garmin_today or garmin_training_readiness. There are no exclusions or direct comparisons.

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 discloses the primary behavior and the fuzzy-miss behavior ('with suggestions on a miss'), which is material. It does not state read-only status explicitly, but the resolve/lookup framing makes side effects unlikely and the description adds value beyond the schema.

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

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

A single sentence that front-loads the verb and resource, then adds a concise edge-case note. Every element earns its place 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?

For a one-parameter tool with an output schema, the description covers the essential purpose and edge-case behavior. The only notable gap is the lack of explicit comparison with sibling tools, but the description is otherwise sufficient for an agent to call it correctly.

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

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

The single parameter has 100% schema description coverage with an example ('Barbell Bench Press'), so the schema already documents the parameter fully. The description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Resolve') with a specific resource ('exercise name to its Garmin category/exercise pair'), which clearly identifies the tool's intent and sets it apart from sibling search/category tools. The mention of 'suggestions on a miss' adds a distinguishing behavioral detail.

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 context (normalizing an exercise name into a Garmin category/exercise pair), but it does not explicitly state when to choose this over garmin_search_exercises or garmin_exercise_categories, nor any exclusion conditions. This is adequate but leaves selection guidance 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 exist, so the description carries the full burden. It reveals no behavioral details: no mention of read-only behavior, no defaults beyond the schema's parameter defaults, no note about response shape, calendar scope, or how scheduled workouts differ from regular workouts. The schema already documents the date defaults, so the description adds no behavioral 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?

The description is extremely short—one sentence—so it is concise, but it is underspecified rather than efficiently informative. It front-loads the resource but spends no words on action or context, so the brevity is not fully earned.

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 tool with no annotations and many closely related siblings, the description is incomplete. It does not clarify what 'scheduled' means, whether it returns a list or a summary, how it differs from garmin_workouts or garmin_today, or what an agent should expect in the output. The output schema exists, but the tool's purpose and selection criteria remain ambiguous.

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

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

Schema coverage is 100%, so the schema fully explains the two parameters and their defaults. The description adds no additional meaning about date filters or their interaction, but with full schema coverage the baseline of 3 is appropriate.

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

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

The description states a result ('Workouts scheduled on the Garmin calendar') but lacks a verb specifying what the tool does with them—retrieve, list, fetch. The phrasing identifies the resource but not an explicit action, so it is a noun phrase rather than a clear verb+resource description.

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

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

No guidance is given about when to use this tool versus siblings such as garmin_workouts, garmin_today, or garmin_activities_by_date. The description does not state any context, exclusions, or alternatives, so the agent must guess which tool fits a request.

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 full behavioral burden. It only states the search operation and does not disclose output format, error handling, whether results include both categories and exercises, pagination details, or any other behavioral traits. This is a notable gap 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?

The description is a single sentence with no redundant words. It front-loads the core purpose and is easily parseable by an agent. Every word earns its place.

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

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

For a simple search tool with fully documented schema and an output schema present, the short description is mostly adequate. However, the lack of usage differentiation from siblings and absent behavioral details mean an agent cannot fully judge when to use it or what to expect from results.

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

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

Schema description coverage is 100%, with both parameters clearly described in the schema ('term' provides examples, 'limit' defines max results and constraints). The tool description adds no extra parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb 'Search' with a specific resource, 'Garmin's strength exercise catalog', and clearly states the goal of finding 'valid category/exercise identifiers'. This makes the tool's purpose clear, though it does not explicitly differentiate it from sibling tools like garmin_exercise_categories or garmin_resolve_exercise.

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: use this tool when needing to search for valid exercise/category identifiers. However, it provides no explicit guidance about when to prefer this tool over siblings, when not to use it, or how it fits into a larger workflow with related 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 must carry the burden of behavioral disclosure. It describes a non-mutating retrieval of sleep data, which is appropriate, but it does not mention permissions, side effects, or what happens when no data exists for the requested date. The output schema covers return structure, but behavioral details beyond simple retrieval are sparse.

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

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

The description is a single, compact sentence that front-loads the resource and key metrics with no filler or repetition. Every word contributes to identifying what the tool returns and for what time period.

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 one optional parameter and an existing output schema, this description is nearly sufficient. It names the core data available and the per-night scope; the only minor gap is not spelling out that 'date' defaults to today, though the input schema already communicates that. Overall, an agent can select and invoke this tool 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%: the only parameter, 'date', is already documented as an ISO date defaulting to today. The description adds that results cover 'one night', which aligns naturally with the date parameter but does not introduce new semantic detail. This matches the baseline expectation when the schema already handles 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?

The description clearly names the resource (sleep) and lists specific metrics (score, stages, SpO2, respiration, overnight HRV), while 'for one night' bounds the scope. It lacks an explicit verb like 'retrieve' or 'get', but the noun-phrase structure still conveys a read operation and distinguishes this tool from siblings such as garmin_hrv or 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?

The temporal scope ('for one night') and metric list imply when to use the tool, and the title 'garmin_sleep' makes the domain obvious. However, there is no explicit guidance about when to prefer this over related Garmin tools, nor any stated exclusions or alternative options. Context is clear but largely inferred.

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

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

With no annotations, the description carries the behavioral transparency burden. It does communicate that the activity must be a completed strength activity, which is a meaningful constraint beyond the schema. However, it does not explicitly state that the operation is read-only, nor what happens for missing or invalid activity IDs. This is adequate for a simple getter but not richly 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?

The description is extremely compact: one clause with no filler or repetition. It front-loads the core content and includes the key prerequisite 'completed strength activity.' Every word contributes 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?

For a single-parameter tool with complete schema coverage and an output schema, the mechanical invocation details are essentially covered. The main gap is selection context: there is no guidance on when to choose this tool over related activity/history siblings, which is important given the large sibling list.

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 parameter activity_id is already described as 'Garmin activity id of a strength session.' The tool description adds the 'completed' nuance and clarifies the returned set-level fields, but it does not meaningfully expand the parameter's semantics beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool's output: per-set exercise, reps, weight, duration, and rest for a completed strength activity. This resource is distinct from sibling tools like garmin_activity or garmin_exercise_history. However, it is a noun phrase rather than an explicit verb+resource statement, so a direct 'returns/retrieves' is missing.

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

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

No guidance is given about when to use this tool versus alternatives such as garmin_activity, garmin_exercise_history, or garmin_preview_strength_workout. There are no explicit conditions, exclusions, or references to sibling tools, so an agent must infer when set-level strength detail is needed.

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 behavioral burden. It discloses the output content and the all-day scope, but does not explain behavior around missing data, timezone handling, or how stress levels are computed. The presence of an output schema covers return structure, so the description adds some but not deep behavioral 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?

The description is a single compact sentence with no filler. The key phrase 'All-day stress' is front-loaded, and every word contributes 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?

For a simple one-parameter tool with an output schema, the description covers the core output and is largely complete. It would benefit from a usage note, but nothing critical is missing for making a correct call.

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

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

The schema already describes the date parameter fully, including ISO format and default behavior. The description adds no additional parameter semantics, so the baseline score of 3 applies due to 100% schema description coverage.

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

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

The description clearly identifies the resource ('All-day stress') and the specific aggregate values returned: average, max, and minutes per stress level. It lacks an explicit verb, but the meaning is unambiguous and distinct from sibling tools, even without naming an alternative.

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

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

No guidance is given for when to use this tool versus alternatives like garmin_today, garmin_recovery, or garmin_heart_rate. The date parameter implies a daily query, but the description never states the intended use case or 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 burden, and it does convey that the tool summarizes seven health metrics for a day, which implies a read-only retrieval operation. It does not disclose caveats such as data availability, sync requirements, timezone handling, or explicit side-effect-free behavior beyond what the schema states.

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 summary line with a metric list; zero filler. The format is easy to scan and every phrase 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?

For a tool with one optional parameter and an output schema, the description plus schema is nearly complete for correct invocation. It fully covers what data the summary contains, though it would be slightly stronger with an explicit read-only statement and a routing note separating it from sibling metric 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 only parameter (date) has 100% schema coverage with an ISO format and a default-to-today description, so the schema already handles parameter semantics. The description adds no date behavior of its own, but it does not need to.

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 daily summary resource and enumerates the included metrics (steps, calories, intensity minutes, resting HR, stress, Body Battery), so an agent can recognize the aggregate nature. It lacks an explicit verb like 'retrieve' and does not directly contrast with single-metric siblings, which prevents 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?

The phrase 'Daily summary' implies this is the tool for a composite same-day overview, and the sibling list shows single-metric alternatives, but the description gives no explicit 'use this instead of garmin_stress' guidance and states no exclusions. The agent must infer when this tool should win over 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does state that the tool exposes a readiness score/level with sleep, HRV, recovery-time, and load inputs, which gives a reasonable sense of the returned data. However, it does not disclose score ranges, units, date behavior, or whether this is purely a read operation, though the resource name strongly implies retrieval.

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

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

The description is a single, short, front-loaded sentence fragment that names the core deliverable and its key inputs without redundancy. Every word contributes to the tool's meaning, and there is no filler or repetition.

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

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

Given the low complexity—one optional parameter, high schema coverage, and an output schema—the description is serviceable for basic selection and invocation. It explains what the readiness metric consists of, but it lacks explicit usage guidance and behavioral caveats that would fully orient an agent, especially with several closely related sibling tools available.

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 schema already provides 100% coverage for the single optional date parameter with an ISO format description and a default of today. The tool description adds no additional meaning about the parameter, so the schema carries the load; the baseline score of 3 is appropriate.

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

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

The description identifies a specific resource—Training Readiness score/level—and names its component inputs (sleep, HRV, recovery-time, load), which helps distinguish it from sibling tools like garmin_sleep and garmin_hrv. However, it lacks an explicit action verb such as 'retrieve' or 'return,' so it stops short of a fully specified purpose statement.

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 provides no explicit guidance about when to use this tool versus alternatives such as garmin_sleep, garmin_hrv, or garmin_today. It implies that this tool covers a composite readiness view, but it never states conditions or exclusions, leaving the agent to infer the selection logic.

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 burden of behavioral disclosure. It lists the data fields but does not explicitly state that it retrieves/returns data or how the optional date affects the result. It is not misleading, and for a read-only status tool the risk is low, but behavior remains mostly implied.

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

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

The description is a compact phrase with no filler; every listed metric is relevant and informative. It could be improved by adding a verb and making it a complete sentence, but the structure is 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?

With a single optional parameter, full schema coverage, and an output schema present, the description does not need to be long. It provides enough distinct information for an agent to select this tool among the Garmin siblings. An explicit verb and usage note would make it fully self-contained, but the current level is 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?

The only parameter, date, is already fully documented in the schema with ISO date format and a default of today. The description adds no parameter-level detail, and with 100% schema coverage, the baseline of 3 applies.

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

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

The description identifies a specific domain and lists distinctive metrics (acute/chronic load, ACWR, load focus, VO2 max) that clearly separate it from sibling Garmin tools like garmin_recovery or garmin_performance_metrics. It lacks an explicit verb such as 'retrieves' or 'returns', but the intended purpose is still 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 metric names imply this tool is for training status and load-related queries, giving some usage guidance. However, there is no explicit when-to-use / when-not-to-use guidance and no mention of alternatives, so the agent must infer the boundary against the many sibling 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 present, so the description carries full behavioral burden. It conveys that the tool returns a detailed read-only view rather than a list, and 'step-by-step' signals the granularity of the data. It does not disclose additional behavior such as authentication needs, error cases, or whether unsaved/planned workouts are accepted.

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 entire description is one short, front-loaded sentence with no filler. It states the key differentiating detail ('step-by-step') and the resource ('one saved workout') 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 detail tool with an output schema present, the description is mostly sufficient. It falls slightly short of fully resolving how the agent obtains workout_id or distinguishes this from scheduled or activity-level detail, but the scope is clear enough for correct selection.

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

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

Schema coverage is 100%, with workout_id described as 'Garmin workout id.' The description adds no further meaning beyond the schema, and the schema already sufficiently documents the single parameter. The baseline of 3 is appropriate because the schema carries the load.

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

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

The description identifies the resource as 'one saved workout' and specifies the output granularity as 'full step-by-step detail', making it distinct from the plural list tool garmin_workouts. It lacks an explicit verb such as 'retrieve' or 'get', but the resource and scope are clear.

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

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

There is no explicit when-to-use guidance or mention of alternatives. The phrase 'one saved workout' implies this tool is for a single workout versus garmin_workouts, but the description does not tell the agent when to choose this over garmin_activity or garmin_scheduled_workouts. Usage is implied rather than stated.

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

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

With no annotations, the description carries the behavioral burden. 'List' communicates a read-only operation and the library scope is clear, but the description does not mention pagination behavior, ordering, or whether summaries rather than full workout details are returned. The limit parameter and output schema partially compensate.

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 concise sentence that immediately states the tool's purpose. There is no filler, repetition, or unnecessary detail.

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

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

For a one-parameter list tool with an output schema, the essential invocation information is present. The main gap is not explicitly distinguishing this from garmin_workout and garmin_scheduled_workouts, but the name and the 'saved workouts' wording are sufficient for a correct call.

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

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

The schema fully describes the single parameter: limit has a default, min/max, and explanation. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource, 'List saved workouts in the Garmin workout library,' making the main function clear. It does not explicitly differentiate from siblings like garmin_workout or garmin_scheduled_workouts, but the 'saved' qualifier helps narrow the 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?

The description implies this tool is for retrieving saved workouts rather than scheduled ones or individual workout details. However, it provides no explicit when-to-use or when-not-to-use guidance and does not name alternative sibling 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?

With no annotations provided, the description carries the full burden. It conveys that the tool is informational and focused on capabilities and limitations, which implies a read-only reference behavior. It does not explicitly state side effects, return behavior, or safety, but for a zero-parameter reference tool this is less critical.

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

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

The description is a single compact sentence with no filler or repetition. It front-loads the main subject and then adds the limitation aspect. It is slightly abstract because it lacks a verb, but it remains appropriately sized for a simple reference tool.

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

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

For a zero-parameter tool with an output schema, the description is largely complete: it identifies the subject matter and the key limitation angle. It could be stronger by explicitly linking to use cases like workout creation or preview, but nothing essential about how to call it is missing.

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

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

The tool has zero parameters and schema description coverage is 100%, so the baseline is 4. The description adds useful context by mentioning 'programming rule' limitations, which helps the agent understand what kind of knowledge the tool provides even though no parameters need explanation.

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

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

The description clearly identifies the tool as an informational reference for Garmin workout step formats and their expressive limitations. It is distinct from sibling tools like garmin_workouts or garmin_workout, but it lacks an explicit verb such as 'returns' or 'lists,' so it stops short of a fully explicit operation statement.

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 that this tool should be consulted to understand what Garmin's workout model can and cannot represent, especially around programming rules. However, it does not explicitly state when to use it versus alternatives, nor does it mention scenarios such as validating a workout plan before creation.

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