Server Quality Checklist

Tool Scores

• daniels_calculate_vdotB
  3.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool calculates VDOT based on distance and time, which implies a read-only, non-destructive operation, but doesn't explicitly confirm this. It also lacks details on error handling, rate limits, or authentication needs. The description adds basic context but misses key behavioral traits, resulting in a mediocre score.

  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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured sections for args and returns. Each sentence earns its place by providing essential information without redundancy. However, the 'Returns' section could be more concise by integrating with the purpose statement, slightly affecting efficiency.

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

  Completeness4/5

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

  Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema that documents the return value, the description is reasonably complete. It covers the purpose, parameter units, and return type, which suffices for a simple calculation tool. However, it lacks usage guidelines and deeper behavioral context, preventing a perfect score.

  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 schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'distance' is in meters and 'time' is in seconds, which clarifies units beyond the schema's generic number types. However, it doesn't explain valid ranges (e.g., positive values), constraints, or examples, leaving gaps in parameter understanding. This partial compensation aligns with a baseline score.

  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 tool's purpose: 'Calculate VDOT according to Jack Daniels.' It specifies the verb ('calculate'), the resource ('VDOT'), and the methodology ('according to Jack Daniels'), making it distinct from sibling tools like 'convert_pace' or 'mcmillan_calculate_training_paces'. However, it doesn't explicitly differentiate VDOT from other metrics like 'velocity_markers' or 'heart_rate_zones' among siblings, which prevents a perfect score.

  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 guidance on when to use this tool versus alternatives. It doesn't mention when VDOT calculation is appropriate compared to other tools like 'daniels_predict_race_time' or 'mcmillan_predict_race_times', nor does it specify prerequisites or exclusions. The only implied usage is for calculating aerobic capacity, but this is too vague for effective tool selection.

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

• riegel_predict_race_timeB
  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 the full burden of behavioral disclosure. While it mentions the formula used, it doesn't describe important behavioral aspects: whether this is a read-only calculation (implied but not stated), what assumptions Riegel's formula makes, accuracy limitations, or error handling. For a prediction tool with zero annotation coverage, this is inadequate.

  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 perfectly structured and concise. It opens with the core purpose, mentions the method, provides clear parameter documentation, and describes the return format. Every sentence earns its place with no wasted words, and information is logically organized from general to specific.

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

  Completeness4/5

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

  Given the tool's moderate complexity (mathematical prediction), 0% schema coverage, no annotations, but presence of an output schema, the description does well. It explains parameters thoroughly and mentions the return format. The main gap is lack of formula limitations/assumptions context. With an output schema handling return values, the description focuses appropriately on inputs and purpose.

  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 description provides clear parameter documentation in the Args section, explaining what each parameter represents (current_distance in meters, current_time in seconds, target_distance in meters). With 0% schema description coverage, this documentation fully compensates by adding essential semantic meaning beyond the bare schema types. The only minor gap is not explaining unit expectations beyond 'meters' and 'seconds'.

  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 tool's purpose: 'Predict race time for a target distance based on a current race performance.' It specifies the verb ('predict'), resource ('race time'), and method ('Uses Riegel's formula'). However, it doesn't explicitly differentiate from sibling tools like 'daniels_predict_race_time' or 'mcmillan_predict_race_times', which would require a 5.

  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 guidance on when to use this tool versus alternatives. With multiple prediction tools available (Riegel, Daniels, McMillan), there's no indication of when Riegel's formula is preferred, what its limitations are, or when other methods might be more appropriate. This leaves the agent without usage context.

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

• convert_paceA
  3.7/5.0
  Behavior3/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 does reveal the return format (dict with value, formatted, unit) and error conditions (ValueError for invalid units or unsupported conversions), which is valuable. However, it doesn't mention performance characteristics, rate limits, or whether this is a pure calculation tool versus one that stores data.

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

  Conciseness5/5

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

  The description is well-structured with clear sections (Args, Returns, Raises) and every sentence earns its place. The opening statement establishes purpose, followed by comprehensive parameter documentation, return value specification, and error conditions - all without unnecessary elaboration.

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

  Completeness4/5

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

  Given the tool's mathematical nature (unit conversion), no annotations, and the presence of an output schema (implied by the Returns section), the description is reasonably complete. It explains what the tool does, documents all parameters, specifies the return format, and mentions error conditions. The main gap is lack of differentiation from sibling tools.

  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?

  With 0% schema description coverage, the description fully compensates by clearly documenting all three parameters: 'value' as the numeric value to convert, 'from_unit' as the source unit with valid options enumerated, and 'to_unit' as the target unit with the same valid options. This provides complete semantic understanding beyond the bare schema.

  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 tool's purpose as converting between pace and speed units, using the specific verb 'convert' and specifying the resource as 'different pace and speed units'. However, it doesn't explicitly differentiate from sibling tools like 'daniels_calculate_training_paces' or 'mcmillan_calculate_training_paces', which might involve similar unit conversions but in different contexts.

  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 guidance on when to use this tool versus the many sibling tools available. With multiple Daniels and McMillan calculation tools that likely involve pace/speed conversions, there's no indication of when this general conversion tool is preferred over those more specialized tools.

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

• mcmillan_heart_rate_zonesA
  4/5.0
  Behavior3/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 key behavioral traits: it performs calculations (not destructive), uses estimation formulas when max_heart_rate is not provided, and returns a dictionary with specific outputs. However, it lacks details on error handling, performance characteristics, or rate limits.

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

  Conciseness5/5

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

  The description is efficiently structured: a clear purpose statement, methodology details, parameter explanations, and return value description—all in four concise sentences with zero wasted words. It's front-loaded with the core functionality.

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

  Completeness4/5

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

  Given the tool's moderate complexity (3 parameters, calculations with multiple methods), no annotations, but with an output schema (implied by 'Returns' section), the description is largely complete. It covers purpose, parameters, methodology, and outputs. Minor gaps include lack of error cases or example usage.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It clearly explains the meaning of all three parameters (age, resting_heart_rate, max_heart_rate), including units (years, BPM) and the optional nature of max_heart_rate with its estimation behavior. This adds significant value beyond the bare 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 specific action ('Calculate heart rate training zones'), the methodology ('McMillan methodology'), and the required inputs ('based on age, resting heart rate, and optional max heart rate'). It distinguishes itself from sibling tools by focusing specifically on heart rate zones rather than pace, velocity, or race time predictions.

  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 when heart rate zones are needed, mentioning the McMillan methodology and alternative calculation methods (HRMAX and HRRESERVE). However, it doesn't explicitly state when to use this tool versus its siblings (like mcmillan_calculate_training_paces) or provide clear exclusions or prerequisites.

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

• daniels_calculate_training_pacesA
  4.1/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 the full burden. It states the tool 'Get recommended training paces,' which implies a read-only operation, but doesn't disclose behavioral traits such as error handling for invalid VDOT values, performance characteristics, or any limitations. The description is minimal beyond the basic function.

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

  Conciseness5/5

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

  The description is front-loaded with the core purpose, followed by structured sections for Args and Returns. Every sentence earns its place by clearly defining inputs and outputs without unnecessary details, making it efficient and well-organized.

  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 low complexity (one parameter) and the presence of an output schema (detailed in the Returns section), the description is complete enough. It explains the purpose, parameter, and return structure, covering all necessary context without redundancy, as the output schema handles return values explicitly.

  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 0% description coverage, but the description compensates by explaining the 'vdot' parameter as 'VDOT value,' adding context about its role in Jack Daniels' formulas. With only one parameter, this provides sufficient meaning beyond the schema's type definition, though it could detail valid ranges or units.

  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 specific action ('Get recommended training paces') and resource ('for a given VDOT'), and distinguishes it from siblings by specifying it's based on Jack Daniels' formulas, unlike the McMillan tools. It uses a precise verb and identifies the exact calculation method.

  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 by mentioning 'based on Jack Daniels' formulas,' which suggests it should be used for VDOT-based pace calculations rather than alternatives like McMillan tools. However, it lacks explicit when-not-to-use guidance or direct comparisons to siblings like 'daniels_calculate_vdot' or 'mcmillan_calculate_training_paces,' leaving some ambiguity.

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

• daniels_predict_race_timeA
  4.2/5.0
  Behavior3/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 methodology ('Jack Daniels' equivalent performance methodology') and return format ('dict: Daniels' VDOT method prediction with value, format, and time_seconds'), but doesn't mention potential limitations, accuracy, or edge cases. It adds some behavioral context but could be more comprehensive for a prediction 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 front-loaded with the core purpose, followed by structured sections for Args and Returns. Every sentence adds value: the first explains what it does, the second the methodology, and the bullet points detail inputs/outputs without 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?

  Given the tool's moderate complexity (3 parameters, prediction logic), no annotations, and an output schema present, the description is fairly complete. It covers purpose, methodology, parameters, and return structure, but could benefit from more behavioral details like error handling or assumptions, though the 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.

  Parameters4/5

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

  The schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter's role ('current_distance: Distance of known performance in meters', etc.), which clarifies beyond the bare schema types. However, it doesn't specify units beyond meters/seconds or validate ranges, leaving some gaps.

  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: 'Predict race time for a target distance based on a current race performance.' It specifies the verb ('predict'), resource ('race time'), and methodology ('Jack Daniels' equivalent performance methodology'), distinguishing it from sibling tools like 'riegel_predict_race_time' and 'mcmillan_predict_race_times' by naming the specific method.

  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 context by stating it's for predicting race times based on current performance, but it doesn't explicitly guide when to use this tool versus alternatives like 'mcmillan_predict_race_times' or 'riegel_predict_race_time'. It provides clear input requirements but lacks explicit comparisons or exclusions.

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

• mcmillan_calculate_training_pacesA
  4.2/5.0
  Behavior3/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 tool's purpose and output structure but lacks behavioral details such as error handling for invalid inputs, computational complexity, or any rate limits. It does not contradict annotations, but could benefit from more operational 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 front-loaded with the core purpose in the first sentence, followed by clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.

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

  Completeness4/5

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

  Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is mostly complete. It explains the purpose, parameters, and output structure. However, it could improve by addressing potential errors or linking to sibling tools for context, though the output schema reduces the need to detail return values.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'distance' is in meters and 'time' is in seconds, which clarifies units beyond the schema's basic number types. However, it does not provide validation rules or examples, leaving some gaps in parameter understanding.

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

  Purpose5/5

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

  The description clearly states the specific action ('Calculate training paces for all zones'), methodology ('using McMillan methodology'), and input basis ('based on a race performance'). It distinguishes from siblings like 'daniels_calculate_training_paces' by specifying the McMillan methodology and from 'convert_pace' by focusing on comprehensive zone calculations rather than simple conversions.

  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 context by stating 'based on a race performance,' which suggests when to use this tool (after a race result is available). However, it does not explicitly state when not to use it or name alternatives like 'daniels_calculate_training_paces' for different methodologies, missing full explicit guidance.

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

• mcmillan_calculate_velocity_markersA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It explains what the tool does (calculates velocity markers) and the output format, but doesn't disclose behavioral traits like error handling, validation rules for inputs, or performance characteristics. The description adds basic context but lacks depth on operational 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 front-loaded with the core purpose in the first sentence, followed by a structured 'Args' and 'Returns' section. Every sentence earns its place by providing essential information without redundancy, making it highly efficient and easy to parse.

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

  Completeness4/5

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

  Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is reasonably complete. It explains the purpose, input semantics, and output format. The output schema likely covers return values, so the description doesn't need to detail them further. However, it could improve by adding more behavioral context or usage caveats.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'distance' is in meters and 'time' is in seconds, which clarifies the units beyond the schema's numeric types. However, it doesn't explain valid ranges or constraints (e.g., positive values, realistic race distances).

  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 specific action ('calculate velocity markers'), identifies the methodology ('McMillan'), and specifies the exact markers produced (vLT, CV, vVO2). It distinguishes this tool from siblings like 'mcmillan_calculate_training_paces' by focusing on velocity markers rather than training paces.

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

  Usage Guidelines4/5

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

  The description provides clear context ('from a race performance using McMillan methodology'), which implicitly suggests when to use this tool. However, it doesn't explicitly state when to choose this over alternatives like 'daniels_calculate_vdot' or 'mcmillan_predict_race_times', nor does it mention any prerequisites or exclusions.

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

• mcmillan_predict_race_timesA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It mentions the methodology ('McMillan') and output format ('HH:MM:SS'), which adds useful context beyond basic functionality. However, it lacks details on behavioral traits such as error handling, assumptions (e.g., standard distances), or limitations (e.g., accuracy range).

  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 front-loaded: the first sentence states the core purpose, followed by structured 'Args' and 'Returns' sections. Every sentence earns its place by adding essential information without 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?

  Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is mostly complete. It covers purpose, inputs, and output format. The output schema exists, so explaining return values is unnecessary. However, it could benefit from more behavioral context (e.g., methodology details or limitations).

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying units ('meters' for distance, 'seconds' for time) and clarifying that inputs are based on a 'single race performance,' which is not evident from the schema alone. However, it does not detail what 'standard distances' entail or provide examples.

  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: 'Predict race times for standard distances based on a single race performance using McMillan methodology.' It specifies the verb ('predict'), resource ('race times'), scope ('standard distances'), and methodology ('McMillan'), distinguishing it from sibling tools like 'riegel_predict_race_time' or 'daniels_predict_race_time'.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool: when predicting race times based on a single performance using the McMillan method. It implicitly distinguishes it from other prediction methods (e.g., Riegel, Daniels) by naming the methodology, but it does not explicitly state when not to use it or list specific alternatives among siblings.

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