Server Quality Checklist

Tool Scores

• list_hevy_routinesC
  2.1/5.0
  Behavior2/5

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

  The description only says 'list,' implying a read operation, but no annotations are provided. It fails to disclose any behavioral traits such as pagination behavior, rate limits, or ordering. The description does not add value beyond the tool name.

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

  Conciseness2/5

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

  The description is very concise (one sentence), but it is under-specified. It lacks necessary details that would help an agent use the tool correctly. Conciseness should not sacrifice usefulness.

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

  Completeness2/5

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

  Despite having an output schema (unknown structure) and simple parameters, the description is incomplete. It does not explain what a Hevy routine is, how pagination works, or any context about the data returned. The tool definition is minimal and insufficient for effective use.

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

  Parameters1/5

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

  The input schema has two parameters (page, page_size) with no description coverage (0%). The description does not explain these parameters, their defaults, or how they affect the listing. The agent cannot determine the meaning or usage from the description alone.

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

  Purpose3/5

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

  The description states 'List Hevy routines,' which is a verb+resource pair, but it is very generic and does not differentiate from sibling tools like list_hevy_workouts or list_hevy_routine_folders. The agent would need additional context to know exactly what a 'routine' is in this domain.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. Given the presence of multiple similar sibling tools (e.g., list_hevy_workouts, list_hevy_routine_folders), the description should provide context for when listing routines is appropriate.

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

• list_hevy_routine_foldersC
  2.4/5.0
  Behavior2/5

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

  Given no annotations, the description carries full burden for behavioral disclosure. It fails to mention pagination behavior, authentication needs, or any side effects.

  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 extremely brief, but it is under-specified rather than concise. It does not provide enough information to justify its brevity.

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

  Completeness2/5

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

  With an output schema present but unelaborated, the description still leaves many gaps (e.g., output format, authentication, error conditions). For a list tool, more context is needed.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description adds no meaning to the page and page_size parameters. The agent gets no insight into parameter usage beyond defaults.

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

  Purpose4/5

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

  The description clearly states the action (List) and the resource (Hevy routine folders). It distinguishes this tool from siblings that deal with workouts, routines, or Garmin activities.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus other list tools like list_hevy_routines or list_hevy_workouts. The description lacks context for selection.

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

• get_garmin_activity_weatherC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavior. It only states 'get weather data' without elaborating on whether this is a read-only operation, possible edge cases (e.g., missing weather), or response structure.

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

  Conciseness3/5

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

  The description is a single sentence with no wasted words, which is concise. However, it is too brief and omits essential details, making it minimally adequate but not efficient in conveying complete information.

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

  Completeness2/5

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

  With one required parameter and an output schema likely present, the description lacks detail about return values, error conditions, or required context (e.g., how to obtain the activity_id). It is insufficient for complex usage.

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

  Parameters1/5

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

  Schema coverage is 0%—the 'activity_id' parameter has no description. The tool description does not add any information about the parameter's format, source, or constraints, leaving the agent without guidance.

  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 explicitly states 'Get weather data associated with a Garmin activity,' which is a clear verb-resource pairing. It distinguishes from siblings like 'get_garmin_activity' (general activity data) and 'get_garmin_activity_details' (likely more specific details).

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring weather data to exist for the activity, or when it might not return results.

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

• list_hevy_exercise_templatesC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behaviors like pagination, ordering, and rate limits. It only states 'list' without explaining that results are paginated via page/page_size parameters. This is insufficient transparency.

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

  Conciseness3/5

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

  The description is a single concise sentence, but it lacks necessary details. While efficient, it under-specifies behavior, making it minimally adequate.

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

  Completeness2/5

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

  Given the tool's simplicity (pagination, no required params), the description is incomplete. It fails to mention that results are paginated, how to handle pagination, or what the output contains, despite an output schema being present.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention or explain the 'page' or 'page_size' parameters. It adds no meaning beyond the schema's bare names, leaving the agent to infer usage from 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 clearly states the verb 'list' and the resource 'Hevy exercise templates'. It distinguishes from sibling tools like list_hevy_routines or list_hevy_workouts by specifying 'exercise templates'.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives, such as searching for specific templates or retrieving individual template details. No mention of pagination limits or best practices.

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

• get_garmin_activity_splitsC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only states it retrieves data. It omits behavioral details like read-only nature, authentication requirements, or side effects.

  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 a single efficient sentence with no wasted words. It could include more contextual information without sacrificing conciseness.

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

  Completeness3/5

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

  Given 1 parameter, no annotations, and an output schema, the description is minimally adequate. It explains the tool's function but lacks context about return values and relationships to sibling tools.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description should compensate. However, it provides no extra meaning beyond the parameter name 'activity_id', such as its source or format.

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

  Purpose4/5

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

  The description clearly states 'Get split/lap data for a Garmin activity' using a specific verb and resource. It distinguishes from siblings like get_garmin_activity and get_garmin_activity_details, though it could be more precise about what split/lap data includes.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool vs alternatives. It does not mention prerequisites, relationships to sibling tools, or when not to use it.

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

• get_hevy_workoutB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description should disclose behavioral traits like read-only nature or error conditions. It only states 'Get', implying a read operation, but lacks explicit safety info or side-effect disclosure.

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

  Conciseness3/5

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

  The description is extremely concise (8 words) and front-loaded. However, it is so minimal that it borders on under-specification, lacking detail that could help an agent.

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

  Completeness3/5

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

  Given the simple single-parameter retrieval and the presence of an output schema, the description is minimally adequate. It does not explain what the returned data contains, but the output schema may cover that.

  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 parameter 'workout_id' is implicitly explained by 'by ID', but the schema has 0% description coverage. The description adds minimal value beyond the schema, but it does hint at the parameter's role.

  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 the verb 'Get' and specifies the resource as 'one logged Hevy workout by ID'. This clearly distinguishes it from sibling tools like list_hevy_workouts, which return multiple workouts.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives (e.g., list_hevy_workouts). The description does not mention any prerequisites or context.

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

• get_garmin_activity_detailsB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, error handling, or rate limits. It only states what data is returned, without clarifying permissions or side effects.

  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, with a short purpose statement followed by parameter explanations. It is front-loaded with the core function. However, it could be slightly more structured, e.g., grouping related parameters.

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

  Completeness3/5

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

  Given the presence of an output schema, the description does not need to explain return values. However, it lacks context about required activity existence, error responses, or how the tool handles invalid IDs. For a read tool, it is minimally sufficient but not thorough.

  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 has 0% description coverage, so the description must compensate. It adds brief explanations for each parameter (e.g., 'Garmin activity ID', 'Maximum chart samples'), which adds some meaning beyond the schema, but does not provide units, format, or constraints beyond 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 tool name and description clearly state it retrieves detailed Garmin activity data, specifically including charts and map polyline data. This distinguishes it from siblings like get_garmin_activity_splits and get_garmin_activity_weather, which target specific subsets.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites or scenarios where other sibling tools would be more appropriate, leaving the agent to infer usage from the tool name alone.

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

• get_garmin_activityB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It indicates a read operation ('Get'), but provides no details on side effects, authentication requirements, rate limits, or what constitutes a 'summary'. The description lacks depth about behavioral traits beyond the basic purpose.

  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 a single sentence with no unnecessary words. It is front-loaded and efficient. However, it could include key details like what the summary contains without becoming verbose.

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

  Completeness3/5

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

  Given the tool has one required parameter and an output schema, the description is mostly adequate for basic usage. However, it leaves gaps: it does not define what a 'summary' includes (e.g., distance, duration) or differentiate from siblings. Sibling tools like get_garmin_activity_details suggest there are more detailed alternatives, but no guidance is given.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the only parameter (activity_id) has no description in the schema. The description adds 'by activity ID', but does not provide format, examples, or constraints beyond the schema's type and title. Value added is minimal.

  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', the resource 'Garmin Connect activity summary', and the method 'by activity ID'. The verb-resource pair is specific and distinguishes from sibling tools such as get_garmin_activity_details (which implies more detail) and list_garmin_activities (which returns multiple activities without a specific ID).

  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 implies usage context (when you have an activity ID and want a summary), but it does not explicitly state when to use this tool versus alternatives like get_garmin_activity_details or list_garmin_activities. No when-not or exclusion criteria are provided.

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

• get_garmin_activity_typesB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden for behavioral disclosure. It only states the tool 'List Garmin Connect activity type metadata', lacking details on data freshness, caching, error conditions, or whether it requires authentication. No behavioral traits beyond the basic action are described.

  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 a single concise sentence that is front-loaded with the action. However, it could be slightly more informative without becoming verbose. It earns its place but lacks nuance.

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

  Completeness3/5

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

  Given zero parameters, an output schema exists (not shown), and sibling tools handle related but distinct resources, the description is minimally adequate. However, it does not explain what 'metadata' includes or whether the output is sorted or filtered. It is complete enough for a simple list tool but could be more helpful.

  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 baseline is 4. The description adds meaning beyond the empty schema by specifying that it lists 'activity type metadata', clarifying the return value. This is sufficient for a parameterless tool.

  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 'List' and the resource 'Garmin Connect activity type metadata', which unambiguously indicates the tool's purpose. It differentiates from sibling tools like get_garmin_activity (specific activity) and list_garmin_activities (list of activities) by focusing on activity type metadata.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool vs alternatives. There is no mention of prerequisites, context, or when it might be preferable over sibling tools like list_garmin_activities or get_garmin_activity_types.

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

• get_garmin_last_activityA
  3.7/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only states the basic operation. It does not disclose expected behavior like read-only nature, authentication needs, error handling for missing activities, or any side effects. Minimal beyond purpose.

  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?

  Single sentence, no extraneous words. Perfectly concise for a simple tool.

  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 parameters and an output schema, the description is complete: it tells what the tool returns. No missing behavioral details essential for correct use given its simplicity.

  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?

  No parameters exist (0 params, schema coverage 100%), so the description adds no parameter info but also doesn't need to. Baseline 4 as per rule for 0 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 verb 'Get', the resource 'most recent Garmin Connect activity summary', which is specific and differentiates from siblings like get_garmin_activity (requires ID) and list_garmin_activities (returns multiple).

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool instead of alternatives, e.g., when needing the latest activity without an ID, or when not to use (e.g., if activity is outdated). No mention of prerequisites or context.

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

• list_hevy_workoutsA
  3.7/5.0
  Behavior2/5

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

  No annotations provided, so description must disclose behavioral traits. It mentions pagination (page, page_size cap) but omits ordering, rate limits, auth requirements, or that it's a read operation. Lacks key behavioral context for an agent.

  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?

  Extremely concise: two sentences plus structured args. No wasted words, clear front-loading of purpose. Every sentence earns its place.

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

  Completeness3/5

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

  For a simple list tool with pagination and an output schema, the description is adequate but misses details like ordering default (likely newest first), and no mention of filtering or caching. Adequate but could be more complete.

  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 description needs to add meaning. It explains page is one-based and page_size capped at 100, which the schema (only types/defaults) does not. 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?

  Description clearly states 'list logged Hevy workouts,' which is a specific verb+resource combination. It distinguishes well from sibling tools like get_hevy_workout (single workout) and list_garmin_activities (different platform).

  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?

  No explicit guidance on when to use this tool vs alternatives. Usage is implied as listing workouts, but there is no mention of when to prefer this over, e.g., list_hevy_routines or search functionality. Minimal guidance.

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

• list_garmin_activitiesA
  4.1/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 full burden. It mentions the 'limit' is capped at 100, which is a behavioral constraint, but does not disclose other traits such as return format, pagination behavior beyond offset, rate limits, or auth requirements. The term 'recent' is vague and undefined.

  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 brief: a one-sentence purpose followed by an Args block. Every sentence adds value, with front-loaded purpose and structured parameter details. The example activity types are useful without being verbose.

  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 low complexity with 3 optional parameters and an output schema (not shown). The description covers purpose and parameters adequately, but could be more precise about ordering (e.g., 'sorted by date descending') and clarify that 'recent' may depend on user's activity uploads. Overall, it's nearly complete for a list tool with an output schema.

  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 adds significant meaning: start is a zero-based offset, limit is capped at 100, and activity_type is optional with concrete examples (running, cycling, etc.). This fully compensates for the schema's lack of 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?

  The description clearly states 'List recent Garmin Connect activities,' specifying the action (list) and resource (Garmin Connect activities). It also provides parameter details and example activity types, distinguishing it from sibling tools like get_garmin_activity or list_garmin_activities_by_date.

  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 gives clear context for listing recent activities with optional filters, but does not explicitly state when to use this tool versus alternatives (e.g., list_garmin_activities_by_date for date ranges, get_garmin_activity for a single activity). Usage is implied rather than explicit.

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

• list_garmin_activities_by_dateA
  4.1/5.0
  Behavior3/5

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

  No annotations provided. The description discloses that omitting end_date limits results to the start date only, which is useful. However, it does not mention pagination, rate limits, or other behavioral traits beyond parameter defaults.

  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 compact, with the main purpose in the first line and parameter details in clear, bullet-like lines. No redundant or unnecessary text.

  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 4 parameters (1 required), an output schema exists (so return values not needed), and no annotations, the description adequately covers parameter formats and defaults. It could mention pagination or maximum results but is mostly complete for a listing 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%, so the description adds full meaning for all 4 parameters: start_date format, end_date optionality and default behavior, activity_type as optional key, sort_order with examples. This compensates completely for the schema gap.

  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 specifies the verb 'list', the resource 'Garmin Connect activities', and the constraint 'for a date range'. This clearly differentiates it from siblings like 'list_garmin_activities' which lacks date filtering.

  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 implies the tool is for listing activities by date range but does not explicitly state when to use it versus other list tools or provide exclusion criteria. No guidance on when not to use.

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