Server Quality Checklist

Tool Scores

• garmin_get_daily_summaryA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the context that this is a multi-metric aggregate summary, and the schema's `detail` parameter explains the summary/full payload trade-off. It does not discuss potential quirks like missing data or timezone behavior, so it adds moderate but not extensive 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 two sentences, both packed with information. The first concisely lists the returned metrics; the second provides clear use-case guidance. No wasted words or repetition, and key information is front-loaded.

  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 is a low-complexity read-only retrieval with no output schema. The description lists all major categories of returned data, and the schema covers parameters well. It lacks only minor operational details (e.g., behavior on unavailable data), which are not critical for this type of tool. Overall, it is complete enough for an agent to invoke correctly.

  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 100%: both `date` and `detail` have thorough descriptions with relative date syntax and the summary/full distinction. The description itself does not mention parameters, but the schema fully carries the burden. Baseline 3 is appropriate.

  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 a specific verb and resource: 'Get the all-round wellness summary for one day' and enumerates the included metrics (steps, distance, floors, calories, etc.), distinguishing it from specialized siblings like garmin_get_sleep or garmin_get_heart_rate. It also frames its role as the aggregate summary tool.

  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 explicit usage guidance with 'Start here for broad questions like "how active was I on Tuesday"' and notes it 'answers in one call what would otherwise take several,' implying aggregation. However, it does not explicitly name alternative tools or state when not to use it, missing full exclusion guidance.

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

• garmin_get_body_batteryA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by explaining the semantics (rises with rest, falls with activity/stress) and the return fields (high/low, charge/drain totals), which helps the agent interpret results without contradicting the annotations.

  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?

  Two concise, front-loaded sentences. The first sentence states what the tool does; the second adds useful interpretive context. No redundant phrases or filler, every clause earns its place.

  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?

  For a simple read-only tool with no output schema, the description tells the agent what to expect (daily high/low, charge/drain totals) and why it matters (trending vs recovery). Combined with the rich parameter schema and safety annotations, the tool is fully described with no obvious gaps.

  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?

  The input schema covers all three parameters with detailed descriptions (date formats, relative values, and the summary/full detail distinction), so schema coverage is 100%. The description only refers generically to 'a date range' and doesn't add parameter-specific details beyond what the schema provides, landing at the baseline.

  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 ('Get') and names the exact resource ('body battery energy levels') plus the date-range scope. It lists the specific data returned (daily high/low, charge/drain totals), which clearly distinguishes it from sibling tools like garmin_get_stress or garmin_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 gives a clear use case: analyzing multi-day energy trends, with the explanatory note about how body battery rises with rest and falls with activity/stress. It doesn't explicitly mention alternatives or exclusions, but the context is sufficient to infer when this tool is appropriate.

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

• garmin_get_body_compositionA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond this: it only returns days with a recorded weigh-in and explains that empty results indicate missing data, not an error. This is meaningful and does not contradict any annotations.

  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 two sentences. The first sentence front-loads the purpose, and the second adds an important caveat. No wasted words, ideal for quick AI parsing.

  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?

  With no output schema, the description carries the burden of explaining return values. It lists the key metrics returned and explicitly addresses empty-result behavior. Combined with comprehensive schema descriptions and annotations, the tool is fully specified for a read-only retrieval operation.

  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 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides (e.g., detail enum, date formats). The description's mention of returned fields complements but does not override or deepen parameter understanding.

  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 weigh-ins over a date range and lists specific metrics (weight, BMI, body fat, water percentage, muscle and bone mass, range averages). This is a specific verb+resource with concrete data fields, making it distinct from sibling tools that retrieve other health metrics.

  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 clear context: it returns weigh-in data for a date range and notes that an empty result means no measurement was recorded. While it doesn't explicitly mention when to use an alternative sibling tool, the context is sufficient for an agent to select this tool for body composition-related queries.

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

• garmin_get_stressA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds behavioral detail about what the summary contains and that 'full' returns a per-interval series. No contradictions with annotations.

  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?

  Two sentences, front-loaded with the core action. Each clause carries specific information: what is returned, the stress categories, and when to request the full series. No filler or redundant wording.

  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?

  For a simple read-only tool with only 2 parameters, fully described in the schema, and no output schema, the description adequately explains return contents and the optional full-detail mode. It is complete for practical use.

  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 100%: both 'date' and 'detail' have detailed descriptions. The description reinforces 'Use detail='full'' but adds little beyond the schema's own parameter explanations, so a baseline of 3 is appropriate.

  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 stress for one day.' It then enumerates the exact output components (average and maximum stress, plus time divided between rest/low/medium/high stress), which clearly distinguishes it from sibling health metric getters like sleep 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 Guidelines4/5

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

  Provides clear guidance on when to use the default 'summary' vs 'detail='full'' ('Use detail='full' for the underlying per-interval stress series'). It does not explicitly compare alternatives among siblings, but the scope and data type make the use case obvious.

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

• garmin_get_training_readinessA
  4.3/5.0
  Behavior4/5

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

  Annotations already convey readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful context: it is scoped to 'one day', includes a 0-100 score, and enumerates the underlying factors returned. No contradiction with annotations.

  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 two sentences, front-loaded with the core purpose, and wastes no words. The second sentence adds practical usage guidance and sibling differentiation 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?

  With no output schema, the description adequately conveys what the tool returns: a score and the contributing factors. It also captures the tool's scope (single day) and purpose. Combined with the detailed schema and annotations, this is complete for a read-only retrieval tool.

  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?

  The input schema provides full 100% coverage for both parameters, including relative date syntax and the summary/full distinction. The description does not add parameter-level detail beyond what the schema already documents, 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.

  Purpose5/5

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

  The description clearly states the tool 'Get Garmin's training readiness score for one day (0-100)' and enumerates the factors it returns. It also explicitly distinguishes this tool from raw metrics by calling it 'Garmin's own synthesis of the recovery signals', setting it apart from likely sibling tools like sleep or 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 gives explicit usage context: 'This is the tool for "should I train hard today"' and says it is a synthesis rather than a raw metric. It implies when not to use it (for raw metric inspection) but does not name specific sibling alternatives, so it falls just 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.

• garmin_get_user_profileA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a non-obvious behavioral trait: Garmin returns metric values even if the app displays imperial, which is important for interpreting units across tools. This goes beyond annotations.

  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 extremely concise: two sentences that front-load the core purpose and immediately provide a crucial usage tip. No wasted words or redundant information.

  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?

  For a simple read-only profile getter with one optional parameter and no output schema, the description is fully complete. It lists the returned fields, warns about metric units, and the schema handles the detail parameter. The tool is simple enough that no additional behavior needs explaining.

  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?

  The only parameter 'detail' is fully explained in the input schema with a clear description of 'summary' vs 'full' and usage guidance. Since schema description coverage is 100%, the description does not need to add parameter semantics; baseline 3 is appropriate.

  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 with a specific verb ('Get') and resource ('account profile'), and lists concrete fields (name, birth date, height, weight, gender, activity level, measurement system). It distinguishes itself from sibling tools like garmin_get_body_composition by focusing on the user profile and its measurement system.

  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 explicit usage context: 'Worth checking once before interpreting units in other tools' and explains that Garmin returns metric values regardless of app display. While it doesn't mention alternatives or exclusions, this is a clear when-to-use hint that adds value.

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

• garmin_get_hrvA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds context about the temporal scope ('one day'), the specific data included (weekly vs last night averages, baseline range, status), and the typical use case. It does not mention any side-effect or hazardous behavior, which is appropriate for a read-only operation.

  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 two sentences long, with the first sentence delivering the core functionality and outputs, and the second sentence providing usage context. Every word earns its place; there is no redundancy or filler, making it highly efficient.

  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 tool's moderate complexity, the description covers the key aspects: what it returns, the one-day scope, and when to prefer it. The schema handles parameter details, and no output schema exists, so the description adequately informs the agent about expected behavior. It could mention the return format, but that is not critical for selection.

  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?

  The input schema provides 100% coverage with clear descriptions for both 'date' and 'detail', including relative date syntax and the warning that 'full' can be 'potentially enormous'. The description does not need to add further parameter details since the schema is already comprehensive, and it adds no extra parameter-specific nuance beyond what is documented.

  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 'overnight heart rate variability for one day' and enumerates specific outputs (weekly average, last night's average, baseline range, HRV status). It uses a specific verb 'Get' and a distinct resource, making it easy to understand its function and differentiate from sibling 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 advises to 'prefer this when asked about recovery trends rather than a single night's sleep,' which contrasts with the sleep tool. It also provides rationale ('HRV is the most sensitive single indicator of accumulated stress or illness'), giving clear guidance on when to use it over alternatives.

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

• garmin_api_requestA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that responses are returned as-is with no processing, and provides path format guidance, which is useful context beyond the annotations. It doesn't cover error handling or rate limits, but those are less critical given the annotation safety profile.

  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 sentences, front-loaded with purpose, then usage guidance and an example. Every sentence earns its place with no redundancy or fluff.

  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?

  With full parameter schema coverage, strong annotations, and a clear escape-hatch role, the description covers the essential context: what it does, when to use it, and what to expect in the response. No output schema is needed because the response is intentionally raw, and the description explicitly says so.

  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?

  Input schema covers all 3 parameters with detailed descriptions and examples, so the description doesn't need to repeat them. It reinforces the path format with an example, but the main semantic payload already lives in the schema, so the description adds little beyond a baseline.

  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 'Call any Garmin Connect API path directly' and clarifies its role as the escape hatch for ~130 endpoints without a dedicated tool, listing example data types. This clearly distinguishes it from the sibling-specific tools, which each target a single resource.

  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?

  Explicitly instructs to prefer a dedicated tool when one exists, citing easier-to-read output and validated arguments. It also gives a concrete example path and notes the response is raw, making the when-to-use decision unambiguous.

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

• garmin_get_activityA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is clear. The description adds value by enumerating the exact data fields returned (type, timing, distance, etc.), giving the agent a concrete expectation. The 'detail' parameter description also warns that 'full' can be enormous, which is useful behavioral context. No contradiction with annotations.

  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?

  Two sentences, with the main purpose in the first and a prerequisite in the second. No repetition of schema details, no fluff. The content is front-loaded and every phrase earns its place.

  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 complexity (2 params, no output schema, strong annotations), the description is complete. It lists the return contents, specifies the prerequisite workflow, and the parameter descriptions handle the summary/full choice. No critical information is missing for an agent to select and invoke the tool.

  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 coverage is 100%: both parameters have meaningful descriptions. The description adds extra guidance by pointing to garmin_list_activities for finding the ID, which reinforces the activity_id semantics beyond the schema. The 'detail' enum is thoroughly explained with use-case advice.

  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 states a specific verb ('Get'), a specific resource ('full record of one recorded workout'), and the method (by activity ID). It clearly distinguishes from sibling tools by focusing on individual activity details versus daily summaries or user profile 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 explicitly instructs to find the ID with garmin_list_activities first, giving a clear usage workflow. The parameter description for 'detail' further explains when to use 'summary' vs 'full', providing effective context. However, it does not explicitly contrast with other sibling getters like garmin_get_daily_summary, so it misses a full 'when-not-to-use' clause.

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

• garmin_get_sleepA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnly and idempotent, so the description adds behavioral context beyond them: it clarifies the date boundary ('night ENDING'), introduces the impact of 'today' vs. a calendar date, and warns that detail='full' returns large per-minute series. This provides useful caution for usage without contradicting the annotations.

  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 two sentences that are packed with useful information and no fluff. The first sentence defines the primary purpose and the key data fields; the second clarifies the 'today' special case and the full-detail trade-off. Every sentence earns its place.

  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?

  For a tool with no output schema, the description is remarkably complete: it enumerates the fields returned, explains the date interpretation, and flags the payload size for full detail. Combined with rich annotations and a fully covered input schema, an agent has enough context to invoke the tool 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 coverage is 100% with descriptions for both 'date' and 'detail'. The description adds further semantic value by explaining the night-ending convention and explicitly linking 'today' to last night's data, as well as stressing the large size of full detail output. This goes beyond the schema's basic format 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 gets sleep data for the night ending on a given date, listing specific metrics like sleep score, time in stages, SpO2, respiration, and heart rate. This specific verb+resource clearly distinguishes it from sibling tools like Garmin's daily summary or HRV 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?

  The description provides clear context on when to use the tool: it is for sleep data, and explicitly advises using 'today' for last night's sleep. It does not mention alternatives or exclusions, but the scope is well-defined enough for an agent to select the tool appropriately.

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

• garmin_get_stepsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds 'Cheap and compact,' which discloses performance and response-size traits beyond the annotations, and the schema's detail parameter further warns about 'full' being potentially enormous. This is valuable behavioral context, though not exhaustive.

  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 two sentences: the first front-loads the purpose, the second provides usage guidance. Every word earns its place, 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?

  The tool is simple, read-only, and fully covered by rich schema descriptions and safety annotations. The description states what data is returned (step totals, goal, distance) and when to prefer it, making it complete for an agent to select and invoke correctly without needing an output schema.

  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 100%, with each parameter (detail, end_date, start_date) fully explained including formats and behavior. The description's phrase 'in a range' aligns with the start/end date parameters but adds no new semantic detail beyond what the schema already provides, 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.

  Purpose5/5

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

  The description opens with 'Get daily step totals, step goal and distance for each day in a range,' using a specific verb and resource. It also distinguishes itself from the sibling daily-summary tool by explicitly recommending this tool for step-only questions, making its purpose unmistakable.

  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 says 'prefer this over repeated daily-summary calls when the question is only about step counts over time,' giving clear when-to-use guidance and naming the alternative. This directly helps the agent choose between this tool and garmin_get_daily_summary.

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

• garmin_list_activitiesA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the list is ordered newest first, includes specific fields, and supports a date range. It also communicates a typical workflow (list then get detail), which is extra transparency not present in the structured data.

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

  Conciseness5/5

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

  Two sentences: the first states exactly what the tool returns and the ordering; the second gives the usage workflow. No fluff, redundant text, or filler. Front-loads the key purpose and ends with actionable guidance.

  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?

  For a read-only list tool with three optional parameters, the description fully covers what the tool does, what fields it returns, and how it fits into the broader workflow (use to find an activity, then pass activityId to garmin_get_activity). No output schema exists, but the description enumerates the returned attributes, so the agent knows what to expect. Sibling tools are not needed for this simple use case.

  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 100%, with each parameter (detail, end_date, start_date) already explained in the input schema. The description does not add new parameter-level semantics beyond what the schema provides, 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.

  Purpose5/5

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

  The description states a specific verb ('List') and a clear resource ('recorded workouts'), and specifies the returned fields (activity ID, type, name, etc.) and ordering ('newest first'). It also distinguishes itself from garmin_get_activity by framing the list as a precursor to fetching single-activity detail.

  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?

  Explicitly tells the agent when to use this tool: 'Use this to find an activity, then pass its activityId to garmin_get_activity for the full detail of a single session.' This names the alternative tool and gives the context (finding an activity before retrieving its full detail).

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

• garmin_get_health_snapshotA
  4.7/5.0
  Behavior5/5

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

  Beyond annotations (readOnly, idempotent), the description discloses that metrics are trimmed to headline numbers and that unsupported metrics are reported as errors within the result rather than failing the call. This adds meaningful behavioral context beyond the annotations.

  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?

  Two sentences with no fluff: the first states purpose and contents, the second gives usage guidance and error behavior. Highly concise and front-loaded.

  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?

  With one parameter, no output schema, and rich annotations, the description provides sufficient context for an agent: what is included, when to use it, and how errors are handled. The tool is simple enough that this description is complete.

  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 100% for the single `date` parameter, which fully explains format and defaults. The description adds no additional parameter detail, 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.

  Purpose5/5

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

  The description clearly states the tool provides an all-in-one recovery picture for a single day, listing the included metrics (daily summary, sleep, HRV, body battery, training readiness). This distinguishes it from sibling metric-specific tools like garmin_get_sleep or garmin_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 Guidelines5/5

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

  Explicit guidance is given: prefer this for open questions like 'how did I sleep' or 'should I train today', and it notes this replaces five separate calls. This clearly signals when to use it over the individual metric tools.

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

• garmin_get_heart_rateA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond this: it discloses the granularity of data (summary stats vs. continuous series) and warns that 'full' returns an 'accurate but potentially enormous' payload. No contradiction exists between description and annotations.

  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?

  Two sentences, front-loaded with the core purpose, followed by a parameter tip and a sibling-tool alternative. Every sentence earns its place with zero redundancy. Highly concise and well-structured.

  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?

  For a simple two-parameter read tool with rich annotations and thorough schema descriptions, the description provides enough context for correct selection and invocation. It explains what outputs to expect (resting, min/max, 7-day average), covers the full-detail option, and names the alternative for workout data. No output schema exists, but the description fills that gap adequately.

  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 100%, and the schema already thoroughly explains both 'date' and 'detail' parameters, including defaults and trade-offs. The description only briefly mentions detail='full' for continuous series, which is already in the schema, adding no new parameter-level meaning. Baseline 3 applies because the schema carries the load.

  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 verb ('Get'), resource ('heart rate'), and scope ('for one day') along with specific outputs (resting, min/max, 7-day average). It also distinguishes from the sibling tool garmin_get_activity by directing workout-specific heart rate queries there. This is a specific, actionable purpose statement.

  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?

  Explicitly says when to use this tool (for daily heart rate summary) and when not to (for workout-specific heart rate, use garmin_get_activity instead). Also provides guidance on the 'detail' parameter, recommending 'summary' for most cases and cautioning that 'full' is potentially enormous. This is excellent usage direction.

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