Server Quality Checklist

Tool Scores

• compare_activitiesA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full transparency burden. It goes beyond a basic statement by disclosing that deltas are calculated within the tool, that a plain-language pace verdict is included, and that positive numbers mean slower, which is a common point of confusion. This is genuinely helpful 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 compact and front-loaded, with the purpose in the first sentence, followed by parameter definitions and then a key behavioral caveat. Every sentence earns its place; there is 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?

  The tool is simple (two integer ids) and an output schema exists, so the description need not explain return values. It covers purpose, parameters, and behavior (including the sign convention), which fully equips an agent to select and 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?

  The input schema has no property descriptions (0% coverage), so the description's Args section is the only source of meaning for id_a and id_b. It provides clear, sufficient semantics: 'First activity id' and 'Second activity id.' While minimal, it is adequate for a simple two-id comparison and adds value beyond the schema's bare 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 first sentence, 'Compare two activities side by side, with the differences computed,' clearly names the verb, the resource, and the tool's distinctive output. It also distinguishes this from sibling tools like get_activity_detail or list_activities by emphasizing comparison and computed deltas.

  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 should be used when a side-by-side comparison with computed differences is needed, but it does not explicitly state when to use it over alternatives or exclude other scenarios. There is no mention of alternatives or conditions like 'use get_activity_detail for a single activity.'

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

• get_activity_detailA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosure. It adds useful context about the content of the response (laps, multisport legs), but doesn't explicitly state read-only behavior, error conditions, or any side effects. The information provided is helpful but 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 concise and well-structured: a clear opening statement, a single-line argument explanation, and a memorable rationale for laps. Every sentence earns its place.

  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 output schema exists, so return values need no further explanation. The description covers the main use case and even provides a motivational example for laps. It lacks explicit limitations or comparison to get_activity_streams, but is sufficient for a low-complexity, single-parameter 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?

  The schema has 0% parameter description coverage, but the description fully compensates by explaining 'activity_id' is 'The activity's id, as returned by list_activities', providing both meaning and source.

  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 'Full detail for one activity: summary, laps, and multisport legs', which specifies the verb (get), resource (activity detail), and distinguishes it from siblings like list_activities or get_activity_streams.

  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 explains when laps matter ('eight quarter-mile repeats look identical to a steady run in the summary numbers alone'), implying this tool is for interval-level detail. However, it doesn't explicitly name alternatives or state 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.

• delete_workoutA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behavioral traits: deletion only occurs when confirm=true, and without confirm it performs a dry-run ('reports what would be removed and does nothing'). This goes beyond the schema and is valuable safety-critical information. It does not mention reversibility or permissions, but the dry-run behavior is the most important aspect.

  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?

  Efficiently structured with a clear action statement followed by an Args block. Every sentence contributes value: the one-line purpose, the arg explanations, and the important two-step rule. No redundancy or filler.

  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 destructive tool with no annotations, the description covers the core behavioral contract: the confirm guard, the dry-run behavior, and the relationship to create_workout. An output schema exists, so return format need not be described. It omits potential edge cases (e.g., invalid workout_id) but is otherwise complete for typical usage.

  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%, so the description carries full responsibility for parameter meaning. It explains workout_id as 'The id returned by create_workout' and confirm as 'Must be true to actually delete,' adding essential semantics that the schema (type/default) does not convey.

  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: 'Remove a workout from the athlete's Garmin library.' It clearly identifies the action and object, and positions itself as the inverse of create_workout, distinguishing it from sibling read-oriented 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?

  Explicitly characterizes this as 'The undo for create_workout,' providing clear contextual linkage. Also explains the two-step confirm rule, which is essential for safe invocation. Does not list alternative tools, but the sibling context makes the appropriate usage clear.

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

• list_activitiesA
  4.6/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 and meets it well. It discloses ordering ('most recent first'), filtering semantics (including the nuanced behavior of sport filters revealing multisport legs), response format ('compact record'), and default/capped limit. This goes beyond basic expectations and fully informs the 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?

  The description is well-structured: a clear one-sentence summary followed by an 'Args' section. Every sentence provides valuable information, including the multisport edge case. It is detailed yet efficient, 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?

  Despite moderate complexity (4 optional params, no annotations), the description covers ordering, filtering, formatting, and a subtle multisport behavior. An output schema exists, so not detailing every return field is acceptable. The description is self-contained and sufficient for correct invocation.

  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 (no property descriptions), but the description compensates by explaining every parameter: ISO date format with example, sport filter options, default and max limit, and the 'until' boundary. It adds significant 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+resource statement: 'List recorded activities, most recent first.' This clearly differentiates it from siblings like get_activity_detail or weekly_summary, and the mention of 'compact record' further highlights its listing focus.

  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 useful context about filters and output format but does not explicitly state when to use it over alternatives (e.g., 'for a single activity's details, use get_activity_detail'). Usage is implied through the described behavior, but no exclusions or alternative guidance is provided.

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

• weekly_summaryA
  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 discloses important behavioral details such as week-start snapping, defaulting to the current week, and special handling of multisport events. It does not explicitly mention read-only nature, but the summary context makes it obvious.

  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 and well-structured, with a clear breakdown of the parameter. It provides essential information without any 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?

  The tool is simple with one optional parameter and an output schema. The description covers core functionality, parameter semantics, and edge cases like multisport counting, making it complete 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.

  Parameters5/5

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

  The description thoroughly explains the week_start parameter, including the snapping behavior and default value, fully compensating for the lack of schema descriptions. This adds significant meaning beyond the input 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 that the tool provides training totals for one week, broken down by sport. This distinguishes it from sibling tools like get_activity_detail (individual activities) and compare_activities (comparisons).

  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 implies the tool is for weekly summary use, providing clear context. However, it does not explicitly state when to prefer this over alternatives or when not to use it, so it lacks explicit exclusions.

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

• database_statusA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool returns database contents and reachability, and crucially warns that an empty result may mean nothing has been ingested yet. While it doesn't explicitly state side-effect-freeness, the read-only nature is clearly implied.

  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 brief sentences, front-loading the core purpose ('What the database currently holds, and whether it is reachable') followed by a valuable usage tip. Every sentence earns its place with no redundancy or filler.

  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 zero-parameter diagnostic tool with an output schema, the description is complete. It explains what the tool does, gives a usage scenario, and clarifies a potential misinterpretation of results. The output schema covers return structure, so no further detail is needed.

  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 there is nothing to document. According to the rules, with 0 params the baseline is 4. The description correctly focuses on the tool's output and usage rather than inventing parameter details.

  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 function: reporting the database's current contents and reachability. It distinguishes itself from sibling tools that focus on specific activity operations by addressing the underlying data store state. The phrasing, while not using an explicit verb like 'reports' or 'checks,' unambiguously communicates the tool's purpose.

  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 explicitly states when this tool is worth calling: 'before concluding that an activity is missing.' It explains the rationale that an empty result could indicate no ingestion rather than a missing session, providing actionable guidance for the agent. It doesn't name alternatives, but gives a clear trigger for use.

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

• create_workoutA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility for disclosing side effects. It does so excellently: 'creates nothing' without confirm, and with confirm=true it 'puts a real workout on their Garmin account and onto their watch.' It also explains the preview behavior, which is far beyond what annotations would typically provide.

  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?

  Though lengthy, the description is well-structured: purpose statement, Args list, a prominent usage note, and a concrete example. Every section serves a clear purpose and the length is justified given the complexity of the blocks parameter. 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 complexity (nested blocks structure), the presence of an output schema (though not shown), and the lack of annotations, the description covers the essential aspects: what the tool does, the full input structure, the two-phase invocation pattern, and side effects. It is sufficiently complete for an agent to use it correctly without external guidance.

  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 provides only names and types (0% description coverage), so the description must fully elaborate each parameter. It does: name, blocks with step/repeat structure, constraints (exactly one of duration_s or distance_m), sport options, description, and the critical confirm flag. The extensive example further clarifies the blocks format, adding substantial semantic value 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 opens with a specific verb and resource: 'Create a structured workout in the athlete's Garmin library.' This clearly distinguishes it from sibling tools (e.g., delete_workout, get_activity_detail) and accurately conveys the tool's core 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 explicit, step-by-step usage guidance: call without confirm first to preview, then call again with confirm=true only after athlete agreement. It clearly states the side effect of the final call. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it falls slightly 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.

• get_activity_streamsA
  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 fully carries the burden of behavioral disclosure. It explains that series are averaged into buckets, output is columnar, smoothed values understate real peaks, and true_range provides the real extremes. This is thorough and actionable.

  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 header, parameter list, and behavioral notes. Every sentence adds value—the example about samples per channel helps justify max_points. 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?

  Despite having an output schema, the description also details the return format and data processing, making it complete for a tool of this complexity. It covers both parameter semantics and edge-case behavior (smoothing, true_range) without requiring additional external knowledge.

  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 must explain all parameters. It does so comprehensively: activity_id, fields with available options, and max_points with defaults and caps, adding 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 clearly states the tool returns time series data for a single activity, listing the data types (heart rate, pace, altitude). It distinguishes from siblings by specifying 'one activity' and the columnar output format.

  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 clearly scopes the tool to retrieving time series for a single activity, which implies when to use it. It does not explicitly name alternative tools for other use cases, but the context is clear enough for a user to decide.

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

• sync_nowA
  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 fully reveals the tool's behavior: it writes to DuckDB, requires the ingest worker, fails fast on worker absence, and also handles inbox imports. This discloses failure modes and a concurrency constraint, which is exemplary transparency.

  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: a one-line summary, an Args section, then two paragraphs of behavioral notes. Every sentence provides distinct information with no 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?

  Given the single parameter and the presence of an output schema, the description covers purpose, usage, prerequisites, and failure behavior comprehensively. No critical aspect is left undocumented.

  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 only defines 'limit' with a default null, while the description explains it as 'Maximum activities to download' and clarifies the default is the configured batch size (25). This adds critical semantic meaning that the schema lacks.

  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 'Pull new activities from Garmin right now', which is a specific verb+resource combination that clearly distinguishes this sync tool from siblings like list_activities or get_activity_detail. The added mention of importing from data/inbox further expands the scope, but the core action is unambiguous.

  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 implies usage for on-demand synchronization ('right now') and states a prerequisite (ingest worker running), but it does not explicitly name alternatives or when-not-to-use scenarios. This clear context places it above mere implication but below explicit exclusion guidance.

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