Server Quality Checklist

Tool Scores

• health_get_ecgA
  4.2/5.0
  Behavior3/5

  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 some behavioral details such as the waveform's size and the need for scaling and sampling rate, and that waveform samples may be null. However, it lacks information about cache behavior details (e.g., when live is false), potential errors, or rate limits, leaving a moderate gap.

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

  Conciseness5/5

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

  The description is well-structured with a brief overview, clear usage guidance, a compact Args section, and a return summary. Each sentence adds value and the description is front-loaded with the purpose, making it efficient and easy to parse.

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

  Completeness4/5

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

  The tool has 4 parameters, no annotations, but an output schema that details the return structure. The description explains the purpose, usage, and key parameters; the output schema covers return values. It lacks some behavioral details (e.g., cache semantics, error cases), but it is sufficient for a health data retrieval tool, but not perfect.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It does explain start_date and end_date formats and defaults, and describes the live and include_waveform parameters' effects. However, it omits the sampling_hz and scaling_factor fields from the parameter list (though they appear in the output), and doesn't provide full detail on date range conventions, so it partially compensates but not completely.

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

  Purpose5/5

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

  The description clearly states the tool retrieves ECG readings from a watch, specifying the metric (single-lead trace, rhythm classification) and the main use case (heart rhythm or AFib checks). It also distinguishes itself from health_get_heart_rate, a sibling tool, by explicit contrast, making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool: for questions about heart rhythm or AFib checks, and when not to use it: for resting rate over time, for which health_get_heart_rate is recommended. This provides clear, actionable usage guidance and directly names the alternative, exceeding the minimum.

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

• health_get_breathing_rateA
  4.3/5.0
  Behavior4/5

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

  Discloses caching behavior (returns from cache, auto-syncs if stale) and output format (one entry per night), which are important behavioral details not available in annotations (none provided).

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

  Conciseness4/5

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

  The description is concise and well-structured, though it repeats parameter details that could be considered redundant. Overall, it is clear and not overly verbose.

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

  Completeness5/5

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

  Provides comprehensive context: purpose, parameter details, output structure, caching, and even a clinical note. Given no annotations or schema descriptions, it fully equips the model to use the tool correctly.

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

  Parameters5/5

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

  Each parameter (start_date, end_date, live) is fully explained with format, default, and semantic meaning, compensating for the lack of schema descriptions.

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

  Purpose5/5

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

  Clearly states it retrieves nightly breathing rate (avg breaths per minute during sleep), with a specific verb and resource. Distinguishes from sibling tools by the metric.

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

  Usage Guidelines3/5

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

  Provides a use case (illness/recovery signal) but does not explicitly mention when to use this tool instead of alternatives or when not to use it. The guidance is implicit rather than explicit.

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

• health_get_cardio_fitnessA
  4.4/5.0
  Behavior4/5

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

  No annotations exist, so the description must carry the burden. It discloses caching behavior, data freshness, the nature of the values (range vs single), and warns against averaging across sources. It also explains the re-fetch option. This is substantial transparency beyond the bare minimum.

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

  Conciseness5/5

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

  Efficient structure: purpose first, then derivation context, then caching, then parameters, then data interpretation. Each sentence adds value, no redundancy. Well-organized with clear sections.

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

  Completeness5/5

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

  Given that the output schema exists, the description doesn't need to list return fields, but it does explain the meaning of the values (range vs single, units) and warns against improper use. It also covers caching and refresh behavior. No annotations, so description carries full burden, and it does so admirably.

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

  Parameters5/5

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

  Schema coverage is 0% (schema only says type string/null). The description fills in all gaps: date formats (YYYY-MM-DD, YYYY-MM, 30d), default behavior, and 'live' parameter meaning. It even explains the semantics of the returned values (which is beyond params).

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

  Purpose5/5

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

  The description clearly states the tool retrieves Cardio Fitness Score (VO2 Max estimate) with specific derivation (HR, walks/runs, demographics). It distinguishes itself from sibling tools by specifying this is about cardio fitness/VO2 max, not general activity or heart rate.

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

  Usage Guidelines3/5

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

  The description explains when results are stale (weekly update) and how to force fresh data (live=true), but it doesn't explicitly compare to sibling tools or state when not to use it. Some implied guidance via the 'live' parameter but no clear alternatives or exclusions.

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

• health_get_devicesA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden, and it delivers with the key disclosure: 'Live-only (no caching) - reflects current device state.' This is critical behavioral information — the agent learns this is a live snapshot, not a cached report. The return-shape description adds further transparency, though it doesn't address error states or empty-device behavior.

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

  Conciseness5/5

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

  Three crisp sections: (1) one-sentence purpose, (2) behavioral note with use cases, (3) return-shape enumeration. Every sentence earns its place with zero redundancy. The front-loaded headline sentence allows for quick scanning.

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

  Completeness4/5

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

  For a zero-parameter read tool with an output schema available, this is admirably complete — purpose, live behavior, use cases, and return fields are all covered. Could be enhanced with notes on failure modes or empty states, but those are minor for this tool's complexity.

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

  Parameters4/5

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

  With zero parameters and 100% schema coverage (trivially satisfied), the baseline is 4. The description adds value by thoroughly documenting the output shape ('id, type, device_version, battery, battery_level (0-100), last_sync_time, mac, features'), giving the agent a full picture of what to expect from the response.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'List paired devices with battery level and last sync time.' This is precise and clearly distinguishes it from siblings like health_get_activity or health_get_sleep — this is the device/resource-discovery tool. The field enumeration (battery, battery_level, last_sync_time) further cements the purpose.

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

  Usage Guidelines4/5

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

  The description provides clear use-case context: 'monitoring tracker health, knowing which device produced data, and spotting sync gaps.' This tells the agent when to reach for this tool. However, it does not explicitly name alternatives or include when-not-to-use language, so it stops short of a 5.

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

• health_trendsA
  4.4/5.0
  Behavior4/5

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

  It discloses auto-syncing if stale, the behavior of compare (ignoring period/start/end), and details about how spo2 and cardio_fitness are handled in output. However, the verbose and repetitive explanation makes the transparency less crisp than it could be, and it doesn't mention error handling or side effects beyond that.

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

  Conciseness2/5

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

  The description is excessively long and repetitive, with near-duplicate paragraphs about spo2/cardio_fitness formatting. It could be condensed significantly while preserving key information. The structure mixes args, returns, and deep nuances in a convoluted flow.

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

  Completeness4/5

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

  Given the complexity and lack of annotations, the description covers essential aspects: purpose, parameters, output details, and alternates. It includes auto-sync behavior and the raw-data alternative. Slightly incomplete regarding potential edge cases or error conditions, but the main context is well addressed.

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

  Parameters5/5

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

  The schema has zero description coverage, so the description fully compensates by explaining every parameter: data_type with options, period with options, start_date, end_date, and compare including its override behavior. All parameters are covered.

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

  Purpose5/5

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

  The description clearly states it analyzes trends in cached health data and computes averages/totals over time. It also distinguishes from siblings by explicitly saying 'Not for raw data - use health_get_* tools instead.'

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

  Usage Guidelines5/5

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

  The description explicitly directs when not to use it (for raw data) and indicates when to use it (for trend analysis). It also explains the parameter behavior, such as compare overriding other date/period parameters.

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

• health_get_heart_rateA
  4.5/5.0
  Behavior4/5

  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 discloses the cache-default behavior, auto-syncing logic, the meaning of the live flag, and the returned daily entry structure with zones. This gives the agent useful expectations 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.

  Conciseness5/5

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

  The description is well-organized: a one-line summary, a behavior note, an Args section, and a Returns section. It is compact but every sentence adds useful information without padding.

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

  Completeness4/5

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

  Given that there is an output schema and three optional parameters, the description provides strong coverage of purpose, parameters, caching behavior, and return shape. It could be slightly stronger by warning about unavailable data or explicitly guiding selection among the many health_get_* sibling tools, but it is largely complete.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description compensates fully by explaining start_date, end_date, and live with concrete formats like 'YYYY-MM-DD', 'YYYY-MM', and '30d'. It also explains each parameter's default and the effect of live on cache reads.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Get daily resting heart rate and heart rate zones.' It explicitly identifies the output granularity and zone breakdown, which distinguishes it from sibling health_get_* tools like health_get_activity or health_get_hrv.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: it reads from cache by default, auto-syncs when stale, and the live parameter can force a fresh API fetch. It does not explicitly name alternatives, but the purpose and cache behavior make the typical use case clear.

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

• health_get_exercisesA
  4.6/5.0
  Behavior4/5

  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 explicitly states the default behavior is reading from a local cache, that live=True triggers an API re-fetch, and it mentions a specific data-quality caveat ('HR data from cycling may be unreliable'). This is strong behavioral disclosure.

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

  Conciseness4/5

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

  The description is well-structured with a clear opening sentence, a behavior note, and a clean Args section. It is concise enough and front-loaded. The only minor deduction is for the 'Returns' section listing fields, which could be slightly trimmed since an output schema exists, but it remains useful for clarity.

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

  Completeness5/5

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

  Given the tool's complexity (4 optional parameters, no annotations, 0% schema coverage), the description is thoroughly complete. It covers defaults, parameter semantics, behavioral nuances, and return value composition. The output schema exists but the text description of return fields provides additional clarity.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate significantly. It does: it explains the date format options ('YYYY-MM-DD', 'YYYY-MM', or '30d'), describes exercise_type as a case-insensitive substring filter, and clarifies what live does. This adds substantial meaning beyond the schema's bare type definitions. The only minor gap is not explaining the default of start_date precisely.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get exercise log entries (individual tracked activities)'. It uses a specific verb+resource construction and immediately distinguishes it from sibling health_get_* tools by focusing on 'exercise' as opposed to heart rate, sleep, weight, etc. The phrase 'individual tracked activities' adds precision.

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

  Usage Guidelines5/5

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

  The description explicitly instructs to run health_sync first to populate the cache, and it indicates when to use live=True to fetch from the API. This provides clear context on when to use this tool versus the synchronization tool.

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

• health_get_sleepA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description takes on full responsibility for behavioral disclosure. It explains the default cache-read behavior, the live fetch option, and the sparse nature of sleep data (missing nights due to travel, off-wrist, or manual logs). This is significant contextual information beyond a simple 'get' operation, though it doesn't mention auth or rate limits.

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

  Conciseness5/5

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

  The description is appropriately structured: a brief summary sentence, then succinct optional details on cache/live behavior and data sparsity, followed by parameter documentation and return description. Every sentence adds value, and it remains compact despite covering edge cases.

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

  Completeness5/5

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

  Given the output schema exists, the description still adds meaningful details about return contents (total_minutes, efficiency, start/end times, stage breakdown) and the cache/live data flow. It covers prerequisites, data quality caveats, and parameter formats, making it complete for a data retrieval tool.

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

  Parameters5/5

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

  Schema description coverage is 0%, and the description fully documents all three parameters: start_date formats ('YYYY-MM-DD', 'YYYY-MM', '30d'), end_date format and default, and live as a boolean controlling API re-fetch. This completely compensates for the minimal schema.

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

  Purpose5/5

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

  The description clearly states it retrieves nightly sleep data including duration, stages, and efficiency. The verb 'Get' and resource 'nightly sleep data' are specific, and the scope is unambiguous, distinguishing it from sibling health_get_* tools.

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

  Usage Guidelines4/5

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

  Provides explicit usage context: default reads from local cache, live=True fetches from API, and health_sync must be run first to populate the cache. It also notes data sparsity conditions. However, it does not explicitly mention alternatives or exclusion criteria, though the tool name and sibling list make the domain clear.

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

• health_get_core_temperatureA
  4.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that readings are manually logged, absolute temperatures, and that the tool returns one entry per reading with datetime and temp_celsius. It also explains the 'live' parameter's behavior (re-fetch from API). However, it doesn't mention potential side effects or data freshness beyond the live flag, but for a read-only tool this is adequate.

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

  Conciseness5/5

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

  The description is well-structured with a clear opening sentence, a paragraph distinguishing from the sibling tool, and a concise Args section. Every sentence adds value, and it's appropriately sized for the tool's complexity.

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

  Completeness5/5

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

  Given the tool's moderate complexity (3 optional params, no required), the description covers purpose, usage, parameter formats, and return structure. The output schema exists, so return values are partially covered, but the description adds the datetime format and temp_celsius field names. It's complete for an agent to select and invoke correctly.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It explains start_date and end_date formats (YYYY-MM-DD, YYYY-MM, or '30d' for start; YYYY-MM-DD for end) and defaults, plus the live boolean's meaning. This adds significant value beyond the bare schema, though it doesn't detail edge cases like invalid formats or timezone handling.

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

  Purpose5/5

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

  The description clearly states the tool retrieves manually-logged core body temperature readings in Celsius, explicitly distinguishing it from device-derived skin temperature via health_get_skin_temperature. It specifies the resource (core temperature readings) and the action (get), making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool (for fever/body-temperature questions based on manually logged readings) and when not to (not for device-derived skin temperature), naming the alternative tool. It also notes that multiple readings per day are useful for tracking fever over time, providing clear usage context.

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

• health_get_lifetime_statsA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description fully carries the burden. It discloses that results are cache-bounded, includes a coverage block with specific fields, and explicitly states absence of tracker split and active score. This goes well beyond a generic read, providing actionable caveats.

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

  Conciseness5/5

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

  The description is succinct and front-loaded with the main purpose. It uses three short paragraphs/sentences, each adding distinct value: purpose, breakdown of records, and important caveats. No filler or redundancy.

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

  Completeness5/5

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

  Given there is an output schema, the description doesn't need to detail return values, but it still explains the coverage block and its importance. It covers what the tool does, its limitations, and how to interpret results—sufficient for a no-param read operation.

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

  Parameters4/5

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

  The tool has zero parameters, so the description naturally adds no parameter syntax. Per the baseline for 0-param tools, a score of 4 is appropriate—there is nothing to compensate for.

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

  Purpose5/5

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

  The description opens with a specific verb-resource statement: 'Get all-time activity totals and personal best records.' It clearly defines scope (totals for steps, floors, distance, calories) and distinguishes from siblings like health_get_activity by noting exclusions (no tracker-versus-total split, no active score).

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

  Usage Guidelines4/5

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

  It provides clear context on data freshness ('bounded by what has been synced') and instructs to read the coverage block before quoting totals as all-time. It does not explicitly name alternative tools for missing features, but it does state what this tool does not provide, which guides selection.

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

• health_get_skin_temperatureA
  4.7/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It clearly explains the key caveat that this is a relative deviation (can be negative), not an absolute temperature, and mentions the live parameter's re-fetch behavior. It doesn't explicitly state that this is a read-only operation, but that's implied by 'Get...' and the general tone. One minor gap is a lack of error conditions or permission requirements.

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

  Conciseness5/5

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

  The description is efficient and front-loaded: the first sentence states the core purpose, followed by critical context (what it is NOT), usage guidance, and clear Args section. Every sentence adds value; there is no fluff or redundant content.

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

  Completeness5/5

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

  Despite having a simple schema (3 parameters, all optional) and an output schema, the description provides all essential context for a health metric tool: what the data represents, units, baseline caveat, use cases, and parameter formats. The output schema covers the return structure, so the description doesn't need to dwell on it. For a tool without annotations, this is comprehensive.

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

  Parameters4/5

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

  Although schema description coverage is 0%, the description provides detailed meaning for all three parameters: start_date and end_date formats (including shorthand like '30d' and defaults), and the live parameter's behavior. This fully compensates for the schema's lack of descriptive text, adding practical examples and default values not obvious from the schema alone.

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

  Purpose5/5

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

  The description starts with a specific verb+resource ('Get nightly skin temperature variation') and clearly distinguishes it from the sibling tool health_get_core_temperature by explicitly stating it is a relative deviation, not absolute body temperature. This differentiates it from the many sibling health_get_* tools.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to use this tool (for illness/cycle/recovery signals) and when NOT to use it (for fever/body-temperature readings, use health_get_core_temperature instead). It also mentions the three-night baseline establishment period, which is a critical prerequisite for understanding why data might not appear.

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

• health_get_spo2A
  4.7/5.0
  Behavior5/5

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

  No annotations are provided, so the description bears full responsibility. It thoroughly discloses caching behavior, the need for health_sync, data sparsity, the meaning of different bounds (min/max vs avg_ci), warning against comparing across them, and normal ranges. It also explains the live flag's effect. This is rich 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.

  Conciseness5/5

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

  The description is well-structured with a clear overview, cache behavior, parameter explanations, return details, and clinical reference. Each sentence is purposeful, no fluff. Front-loaded with the main purpose.

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

  Completeness5/5

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

  Given the tool's complexity (cache vs live, two bound types, overlap scenario), the description covers all important behaviors. It explains parameters, return values, caveats about bounds, and clinical context. With no annotations and sparse schema (no descriptions), it fully compensates, and the output schema is not provided but the description explains the return structure sufficiently.

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

  Parameters4/5

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

  The schema has 3 parameters but their descriptions in the schema are minimal (only types and defaults). The description explains date formats (YYYY-MM-DD, YYYY-MM, or 30d), the meaning of 'live', and default ranges header. Since schema coverage is 0%, the description compensates well. It does not explain 'end_date' format explicitly but says it's YYYY-MM-DD. This adds significant value beyond schema.

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

  Purpose5/5

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

  The description clearly states it retrieves nightly SpO2 data with specific details about data source (local cache), and distinguishes itself from sibling health tools (e.g., health_get_heart_rate, health_get_sleep) by naming the metric and behavior. It also mentions the need for health_sync, differentiating its pipeline.

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

  Usage Guidelines4/5

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

  It explicitly states to run health_sync first to populate the cache and explains when data is sparse (only on-wrist sleep tracking). It also explains the live parameter for re-fetching. However, it does not directly contrast with siblings or state when not to use this tool, though the resource is clear enough.

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

• health_get_azmA
  4.8/5.0
  Behavior4/5

  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 clearly discloses that results come from a local cache by default with auto-sync when stale, that live re-fetches from the API, and that total_minutes is an unweighted sum. This is strong behavioral transparency, though it does not cover failure modes or data availability edge cases.

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

  Conciseness5/5

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

  The description is longer than average but well-structured and entirely informative. It front-loads the core purpose, then uses clear paragraphs for metric definition, caching behavior, arguments, return values, and sibling differentiation. Every sentence contributes value.

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

  Completeness5/5

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

  Given the tool's complexity—caching semantics, multiple date formats, zone definitions, and sibling overlap—the description is complete. It even covers return shape and distinguishes this metric from a related tool, leaving little for an agent to guess.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description fully compensates with an Args section: it defines start_date formats ("YYYY-MM-DD", "YYYY-MM", or "30d"), defaults (last 30 days), end_date default, and the meaning of live. This adds substantial meaning beyond the raw schema.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: "Get daily Active Zone Minutes (AZM)", then clarifies it as the "headline cardio metric". It also distinguishes itself from the sibling health_get_activity by explaining the difference between AZM and active wall-clock minutes, eliminating ambiguity.

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

  Usage Guidelines5/5

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

  The description gives explicit usage context: it explains the cache/sync default behavior, how the live parameter changes fetching, and explicitly contrasts with active_minutes in health_get_activity. This helps an agent choose between related health tools with clear exclusions.

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

• health_get_food_logA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It discloses that only hand-logged data appears, that cache is used by default with auto-sync, that 'live' forces a re-fetch, and that empty days are omitted. This goes well beyond a simple one-line summary and gives the agent accurate expectations.

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

  Conciseness5/5

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

  The description is concise (~110 words), front-loaded with the main purpose, and organized into clear sections for behavior, arguments, and return values. Every sentence adds useful information; there is no fluff or repetition.

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

  Completeness5/5

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

  Given the tool's moderate complexity—optional date handling, cache semantics, and a live override—the description covers all necessary context. It even describes the return shape despite an output schema being present, making the tool self-sufficient for an agent.

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

  Parameters5/5

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

  The input schema has 0% description coverage, so the tool description must compensate, and it does. It explains start_date formats including '30d', default behavior for both dates, and the meaning of 'live' in the context of cache re-fetching. This is meaningful semantic value beyond the raw schema.

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

  Purpose5/5

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

  The description uses a specific verb plus resource ('Get daily food and water log summary') and clearly differentiates this tool from siblings by scoping it to food/water logging and calorie/water intake. It states exactly what data is returned, leaving no ambiguity about the tool's function.

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

  Usage Guidelines4/5

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

  The description provides clear context on when this tool is appropriate: it covers food/water logs from connected apps, only includes hand-logged entries, and explains cache versus live behavior. It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for selection among related health tools.

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

• health_get_weightA
  4.8/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full responsibility, and it delivers: it discloses cache-first behavior, live re-fetch semantics, dependency on health_sync, and sparse weigh-in day coverage. This goes well beyond a simple read-only hint and sets accurate expectations about data availability.

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

  Conciseness5/5

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

  The description is front-loaded with the core purpose and then uses short, focused paragraphs for caching behavior, sparse data, parameters, and return value shape. Every sentence adds value with no filler or redundancy.

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

  Completeness5/5

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

  Given the tool's moderate complexity, the description covers cache semantics, prerequisites, date formats, output shape, and sparse-data behavior. The output schema exists, but the description still usefully summarizes return fields and one-entry-per-weigh-in behavior, making the tool fully comprehensible.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description compensates fully by explaining start_date and end_date formats, defaults, and the meaning of live. Each parameter's purpose and acceptable values are explicitly documented, making the tool invocable without schema help.

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

  Purpose5/5

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

  The description clearly states the tool gets weight log entries and enumerates the specific data fields (weight, BMI, body fat percentage), making the purpose unambiguous. It also distinguishes itself from sibling health tools by focusing on weight log entries versus broader trends or device data.

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

  Usage Guidelines4/5

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

  The description gives concrete usage context: default cache behavior, live=True for API fetches, the need to run health_sync first, and sparse data expectations. It stops short of explicitly naming alternatives or when-not-to-use cases, but the usage guidance is clear and actionable.

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

• health_get_activityA
  5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: caching, need for prior health_sync, rate limit, and the calculation of active minutes ('active_minutes = very_active + fairly_active (excludes lightly active)'). It also notes output granularity ('one entry per day').

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

  Conciseness5/5

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

  Although detailed, the description is well-organized: purpose first, then caching behavior, then rate-limit note, then output details. Each sentence adds value without redundancy, making it appropriately sized for the tool's complexity.

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

  Completeness5/5

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

  Given the simple schema (three optional params), the description covers all relevant aspects: param meanings, default behavior, output structure, and a practical limitation (rate limit). No missing information that would prevent correct use.

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

  Parameters5/5

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

  The description explains the date formats ('YYYY-MM-DD', 'YYYY-MM', or '30d') and the meaning of 'live' (fetch from API vs cache). It also clarifies the default values and what the output contains, adding significant meaning beyond the bare schema types and defaults.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get daily activity summaries (steps, calories, active minutes, distance).' It identifies the resource (activity summaries) and the action (get), distinguishing it from sibling health getters like heart rate or sleep.

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

  Usage Guidelines5/5

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

  It provides explicit usage guidance: 'Returns data from the local cache by default. Use live=True to fetch from the API. Run health_sync first to populate the cache.' Also includes a note about rate limits and daily API call behavior, which helps decide when to use live=True.

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

• health_get_hrvA
  5/5.0
  Behavior5/5

  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 transparently reveals that data comes from a local cache by default, that live=True bypasses the cache, and that running health_sync is needed to populate it. This is exemplary transparency for a health data tool.

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

  Conciseness5/5

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

  The description is concise yet complete, using a clear structure: a one-sentence purpose, cache behavior, a sync prerequisite, a caveat about sparse data, parameter definitions, and return value explanation. Every sentence adds value without redundancy.

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

  Completeness5/5

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

  Given no output schema and no annotations, the description provides a complete picture: what data is returned (one entry per night with daily_rmssd and deep_rmssd in ms), the relationship to sleep tracking, and the cache behavior. It addresses the complexity of the domain by explaining RMSSD meaning, making it fully self-contained.

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

  Parameters5/5

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

  All three parameters (start_date, end_date, live) are fully documented with formats and semantics. The description explains date formats ('YYYY-MM-DD', 'YYYY-MM', or '30d'), defaults, and the meaning of live, which the input schema itself does not provide (only types and defaults). This goes well beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get nightly HRV (heart rate variability) data.' It specifies the resource (HRV) and the verb (get), and distinguishes it from siblings like health_get_heart_rate. The mention of 'nightly' and cache behavior adds precision.

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

  Usage Guidelines5/5

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

  The description explicitly instructs to 'Run health_sync first to populate the cache,' which is a clear prerequisite. It also notes that HRV data is sparse ('only nights with on-wrist sleep tracking produce readings'), guiding the agent on when to expect missing data. The live=True option is explained for forcing API fetch, giving concrete context for when to use it.

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

• health_get_irregular_rhythmA
  5/5.0
  Behavior5/5

  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 transparently explains that alerts are not a diagnosis, describes the nature of the data (background checks), explains the 'live' parameter's cache behavior, and describes the return structure. No contradictions exist.

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

  Conciseness5/5

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

  The description is well-organized with clear sections, each sentence serving a purpose. It opens with a clear purpose statement, then provides contextual guidance, parameter details, and return info. No fluff or redundancy.

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

  Completeness5/5

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

  Given the tool's moderate complexity (3 params, output schema present), the description is complete. It covers the operational context, parameter semantics, and even describes the return format despite the output schema existing. It's both sufficient and effective.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate. It provides detailed semantics for all three parameters: start_date format and default, end_date format and default, and live's purpose. It also clarifies the return fields. This adds significant meaning beyond the generic schema titles.

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

  Purpose5/5

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

  The description clearly states the action: 'Get irregular heart rhythm notifications raised by the watch.' It also distinguishes from sibling health_get_ecg by specifying that ECG is for a deliberate reading with a trace, whereas this tool retrieves background checks. This makes the purpose specific and unambiguous.

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

  Usage Guidelines5/5

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

  It provides explicit context on when to use: these are background checks, not a diagnosis, and most accounts never have one. It also explicitly directs to use health_get_ecg for deliberate readings. Parameter usage is explained with defaults and formats, leaving no ambiguity for the agent.

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

• health_syncA
  5/5.0
  Behavior5/5

  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 thoroughly explains that the tool fetches from the Google Health API and stores in SQLite, syncs incrementally based on the latest cache entry, and that since/until will re-fetch and upsert a specific window. These are meaningful behavioral traits beyond a simple 'sync' label, and the description is transparent about the side effects (writes to cache) and edge cases (backfill, gap repair, ignoring 'days' on subsequent syncs).

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

  Conciseness5/5

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

  The description is well-structured and front-loaded. It leads with the core purpose, then usage context, then parameter details, and closes with return value and alternative tools. Every sentence provides necessary information, and the parameter docs are formatted clearly. No filler or redundancy.

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

  Completeness5/5

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

  Given the tool's complexity (4 parameters with nuanced behavior, incremental sync, backfill, window repair) and the presence of an output schema, the description is complete. It covers prerequisites, return summary, parameter semantics, and explicitly states what the tool is not for. It leaves no significant gaps for an agent to invoke it correctly.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate. It does so comprehensively: data_types lists all acceptable values, comma-separated usage, and default; days explains its role for first sync and that it is ignored later; since and until describe their backfill and repair semantics, including that until requires since and that together they re-fetch exactly the specified window. This adds rich meaning beyond the bare schema definitions.

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

  Purpose5/5

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

  The description opens with 'Sync health data to the local cache,' which clearly identifies the verb (sync) and resource (health data to local cache). It further distinguishes itself from sibling tools by stating 'Run this before using other health_get_* tools' and 'Not for querying data - use health_get_heart_rate ... instead.' This makes the purpose unambiguous and differentiates it from the many read-only getter tools.

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

  Usage Guidelines5/5

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

  The description gives explicit usage guidance: it should be run before using other health_get_* tools to populate the cache, and it is not for querying data. It also explains the incremental sync behavior and when to use since/until for backfill or gap repair, providing clear context for when to invoke this tool versus alternatives.

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