Server Quality Checklist

Tool Scores

• get_activityA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the activity must be 'completed' and that data includes 'per-rep actuals — watts, heart rate, cadence per detected interval.' However, it does not describe error behavior, permissions, or other side effects. It adds some behavioral context but lacks depth expected for an unannotated tool.

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

  Conciseness5/5

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

  The description is two short sentences, front-loaded with the core action. The second sentence provides purpose and a usage hint. No filler or redundancy; every word 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?

  For a simple one-parameter fetch tool with an output schema, the description is fairly complete. It explains the resource, the data contained, and the prerequisite workflow. It does not discuss edge cases or permission requirements, but the presence of an output schema reduces the need to explain return values.

  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%: the activity_id parameter is fully described with an example and a reference to review_period. The description reinforces this by mentioning review_period, but it does not add new meaning beyond the schema. 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 action: 'Fetches one completed activity with its intervals.' This is a specific verb (fetches) with a specific resource (one completed activity) and a specific scope (with intervals). It distinguishes the tool from siblings like review_period by focusing on a single activity's interval 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 provides explicit usage context: 'Run review_period first to find the activity id.' This instructs the agent on a prerequisite and references a sibling tool. It also states the intended use case ('for checking how a structured workout actually went'), giving clear context for when to use this tool, though it does not explicitly mention when not to use alternatives.

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

• delete_blockA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses a critical behavioral limitation (only server-created workouts are deleted) and what cannot be deleted. However, it does not state whether deletion is irreversible, mention permissions, or describe side effects beyond the immediate scope.

  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 short paragraphs with the primary action front-loaded. Every sentence adds meaningful information about scope or limitations, with no unnecessary words or repetition.

  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 three straightforward required parameters and an existing output schema, the description sufficiently explains the tool's operation and its key limitation. It lacks explicit mention of permissions or irreversibility, but for a delete operation with a clearly scoped action, it is adequately 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?

  The input schema already provides descriptive parameter definitions ('The block to remove', 'Search from/to this date'), covering 100% of parameters. The description adds minimal extra parameter context and primarily repeats the block-name and date-range concepts already present in 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?

  States 'Removes a block from the calendar' with a specific verb and resource, and clarifies the precise scope by noting it deletes only server-created workouts under the given block name. This clearly distinguishes it from sibling tools like upload_block, list_block, and export_block.

  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 usage context: the tool only affects server-created workouts under the named block, and explicitly warns that self-added, imported, or other-block workouts cannot be hit. It does not name alternative tools, but the conditions for successful use are clearly implied.

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

• list_blockA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the core behavior: restricts results to server-created workouts only. It also discloses a related behavioral trait of delete_block (cannot delete non-server workouts). This is valuable context beyond what the schema reveals, though it omits other traits like pagination or error semantics, hence not a 5.

  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 exceptionally concise: two short paragraphs, with the purpose stated in the first sentence. Every sentence adds value, especially the scope limitation and the delete_block relation. There is zero fluff or redundancy.

  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 covers return values, so the description need not explain them. It covers purpose, scope, and a key interaction with a sibling tool. It does not mention error conditions or pagination, but given the tool's simplicity and the presence of an output schema, the description is largely 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%, so the input schema already fully explains start_date, end_date, and block_name. The description only generically refers to 'a period' which aligns with the date parameters but adds no new meaning for any specific parameter. This meets the baseline but does not exceed it.

  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: 'Shows workouts this server has put in the calendar during a period.' It clearly distinguishes itself from siblings by stating 'Shows only its own workouts,' which differentiates it from any tool that might list all calendar entries. This is unambiguous and directly tied to the tool's name.

  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 when-not-to-use guidance: 'Anything you added by hand, imported, or got from a coach is invisible here.' It also references the sibling tool delete_block to clarify that these invisible workouts cannot be deleted by that tool. However, it does not explicitly mention an alternative for listing those other workouts, so it falls short of a perfect 5.

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

• export_blockA
  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 disclosure burden. It reveals the tool is non-destructive (downloads), has a dependency on a prior upload, and produces files in specific formats (zwo, etc.). It does not explicitly state side effects or permission requirements, but the nature of the operation is clear.

  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 organized into three focused paragraphs: purpose, usage context, and file placement. Each section provides necessary information without redundancy, though the phrase 'workout files' appears twice. It is front-loaded with the core purpose.

  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 has 5 parameters and an output schema, the description covers the key prerequisites (upload_block first), the main use case (alternative to integration), and post-export steps (placing .zwo files). It does not explain the output schema or error handling, but the output schema exists to cover return values.

  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 coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; the schema already explains dates, output_dir, and file_format. The description's mention of .zwo placement adds context for output use, but not parameter semantics.

  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 'Downloads an uploaded block as workout files,' which clearly states the verb (downloads), resource (uploaded block), and output (workout files). It differentiates from siblings like upload_block and list_block by emphasizing the export nature and positioning it as an alternative to the intervals.icu integration.

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

  Usage Guidelines5/5

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

  The description explicitly states a prerequisite: 'The workouts must be in the calendar first — run upload_block before.' It also provides the use case: 'useful when Zwift runs on a device where the integration is unavailable,' which clarifies when to choose this tool over the integration. It also includes concrete file placement instructions.

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

• get_fitnessA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the important computational nuance that form is computed as CTL − ATL because intervals.icu exposes no form field, and states the default date range. It doesn't cover permissions or error behavior, but for a read-only trend tool this is reasonable.

  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 three concise sentences that front-load the purpose, explain the one non-obvious computation, and then provide the default and interpretive guidance. Every sentence earns its place with no wasted words.

  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 simplicity, an output schema exists, and the description covers the essential behavioral aspects (what metrics, how form is derived, default range, and how to interpret the trend), it is complete. There is no significant gap for an agent to misuse the 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?

  Schema description coverage is 100%, so the schema already explains the start_date and end_date parameters thoroughly with defaults. The description redundantly mentions the 28-day default but adds no new parameter-level details beyond the schema, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool shows the fitness trend with specific metrics (CTL, ATL, form/TSB) on a per-day basis. This specific verb+resource combination distinguishes it from sibling tools like get_power_curve or get_activity.

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

  Usage Guidelines4/5

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

  It provides clear context on when to use it (e.g., defaults to last 28 days) and interprets the trend's meaning (peaking vs. digging a hole). It doesn't explicitly name alternatives or exclusions, so it stops short of a 5, but the usage context is solid.

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

• get_power_curveA
  4.3/5.0
  Behavior4/5

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

  No annotations provided, so description carries burden. It discloses downsampling to classic durations, raw one-point-per-second availability, units (watts and W/kg), and that it covers best efforts over period. This is meaningful behavioral context beyond schema.

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

  Conciseness5/5

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

  Compact two-sentence description that starts with a clear summary, then adds necessary detail; no waste.

  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 analytics tool with optional parameters and an output schema, the description fully explains what the curve represents, which durations, units, and sampling behavior. Nothing critical is missing.

  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 coverage is 100%; both sport and period are described with defaults and examples. Description adds context around curve durations and units but not additional parameter-level detail beyond the schema; baseline 3 applies.

  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?

  Descriptive verb 'Shows' plus resource 'power curve' and immediately clarifies it is best average power per duration; the strength profile framing and classic durations distinguish from sibling get_fitness/get_activity.

  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?

  Clear context: use when examining athlete's power curve/strength profile over a period, with sport and period options. It doesn't explicitly name alternatives or exclusions, but context is sufficient.

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

• check_connectionA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It clearly implies a read-only operation through 'verifies' and 'fetches', and adds context that threshold values are sourced from the account rather than guessed. It does not explicitly mention side effects, but the described behavior is consistent and non-destructive.

  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 only two sentences, front-loaded with the primary action ('Verifies') and includes an actionable directive ('Run this before building a workout'). Every sentence provides useful information without 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 (0 parameters) and an output schema exists, so return values are externally documented. The description covers purpose, timing, and the source of thresholds, making it complete for an agent deciding when and why to invoke it.

  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?

  There are zero parameters and schema coverage is 100%, so no parameter-level documentation is needed. The baseline for zero-parameter tools is 4, and the description doesn't need to compensate for missing parameter info.

  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 specific verbs ('verifies', 'fetches') and a clear resource ('connection', 'athlete's threshold values'). It distinguishes the tool from sibling tools by focusing on pre-workout threshold retrieval.

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

  Usage Guidelines4/5

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

  It explicitly states when to use the tool: 'Run this before building a workout.' It also explains why, noting that threshold values come from the account. It does not name alternative tools, but the usage context is clear.

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

• upload_blockA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It discloses key behaviors: sync to Zwift/Garmin, the English requirement, the duration comparison check, pitfalls with nested repeats, and the idempotent re-run behavior. This goes well beyond a simple 'upload' and alerts the agent to potential silent failures.

  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 three concise paragraphs, front-loaded with the primary purpose. Each sentence earns its place: sync destinations, language constraints, the duration-check warning, and idempotency. No redundant information, and the structure makes it easy to scan.

  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 description covers all essential context for safe and effective use: external sync side effects, language expectations, the silent-failure warning, and update behavior. Since an output schema exists, return value documentation is not needed. The description is fully adequate for this tool's complexity.

  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 itself provides rich details for both parameters (e.g., block_name's update semantics, duration_minutes' comparison check). The tool description adds little parameter-specific meaning beyond what the schema already states, so the baseline of 3 applies.

  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: 'Puts a block of planned workouts in the intervals.icu calendar.' It clearly distinguishes this from siblings like list_block, delete_block, and export_block by focusing on the upload/creation/update action. The additional sync details (Zwift, Garmin) further clarify its role.

  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 to use the tool (to put workouts in the calendar) and provides crucial guidance for correction: 'Re-run with the same block_name to correct; it creates no duplicates.' It does not explicitly mention alternatives or when not to use it, but the purpose is so distinct that an agent can infer usage. The warning about silent DSL mistakes also guides careful usage.

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

• review_periodA
  4.7/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 does so well. It discloses what the tool does (shows compliance, flags missed workouts, includes spontaneous/foreign activities), how results are presented ('reported, not interpreted'), and the default time window. No safety or side-effect concerns are stated, but the 'review' nature clearly implies read-only behavior.

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

  Conciseness5/5

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

  The description is appropriately sized and well-structured. The first sentence front-loads the purpose, the first paragraph details scope and outputs, and the second paragraph gives interpretation guidance and alternatives. Every sentence earns its place without unnecessary verbosity.

  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 has two optional params, an output schema (present), and moderate complexity. The description explains what customers will see (planned workouts, compliance, missed flags, all activities), notes a key nuance (spontaneous/foreign plans count toward load), and directs users to other tools for deeper detail. Given the output schema handles return structure, this description is complete and well-contextualized.

  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 both start_date and end_date already documented with formats and defaults. The description adds minimal extra meaning beyond reinforcing the 7-day default, so the baseline of 3 is appropriate; it doesn't compensate with deeper semantics.

  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 ('reviews') and resource ('planned versus actual training in a period'). It enumerates the outputs (planned workouts, compliance, missed workouts, all activities) and differentiates from siblings by pointing to get_activity and get_fitness for alternative views.

  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 provides explicit usage guidance: it explains the default behavior (last 7 days) and gives direct alternatives for more specific needs ('Use get_activity for per-interval detail', 'get_fitness for the CTL/ATL/form trend'). This satisfies the 'when to use vs alternatives' requirement.

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