Server Quality Checklist

Tool Scores

• get_wellnessA
  4.4/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 effectively describes key behaviors: it's a read operation (implied by 'fetching'), includes constraints (date format requirements, warnings about large date ranges), error handling (raises ValidationError and IntervalsError), and return structure. It doesn't mention rate limits or authentication needs, but covers most critical aspects for a read tool.

  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 well-structured with clear sections (Best for, Not recommended, etc.), but it's verbose with redundant elements. The 'Prompt Example' and 'Usage Example' are somewhat repetitive, and the 'Parameters' and 'Returns' sections duplicate information that could be inferred from the schema. It's front-loaded with key info but includes unnecessary detail.

  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 (2 parameters, no annotations, but with output schema), the description is highly complete. It covers purpose, usage guidelines, behavioral traits, parameter semantics, error handling, and relationships with sibling tools. The output schema exists, so the description appropriately explains return values without over-documenting them. No significant gaps remain for effective tool use.

  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 must compensate. It fully documents both parameters: oldest_date (required, YYYY-MM-DD format) and newest_date (optional, same format, with default behavior if not provided). The description adds essential meaning beyond the bare schema, including format requirements and behavioral details like 'no upper date limit' for missing newest_date.

  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 fetches wellness data from intervals.icu for a configured athlete, specifying the resource (wellness data) and source (intervals.icu). It distinguishes from sibling tools by mentioning get_grouped_wellness for trend analysis, though it doesn't explicitly differentiate from get_activities or get_grouped_activities. The purpose is specific but not fully sibling-differentiated.

  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 guidance with 'Best for' and 'Not recommended for' sections, detailing use cases (daily wellness metrics, health trends) and exclusions (real-time monitoring, medical diagnosis). It also names an alternative tool (get_grouped_wellness) for trend analysis, offering clear when-to-use and when-not-to-use advice.

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

• get_activitiesA
  4.7/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 effectively describes key behaviors: it's a read operation (implied by 'fetching'), warns about potential timeouts with large date ranges, specifies date format requirements, and outlines error conditions (ValidationError, IntervalsError). However, it doesn't explicitly mention rate limits, authentication needs, or pagination details, leaving some gaps.

  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 well-structured with clear sections (Best for, Not recommended for, Common mistakes, Prompt Example, Usage Example, Tool Relationships, Returns, Parameters, Raises), making it easy to scan. While comprehensive, it's slightly verbose with some redundancy (e.g., date format repeated multiple times), but every section adds value, so it's appropriately sized for the tool's complexity.

  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 has 2 parameters with 0% schema coverage, no annotations, but has an output schema, the description provides excellent contextual completeness. It fully documents parameters, usage guidelines, behavioral traits (timeouts, errors), relationships with sibling tools, and includes examples. The output schema handles return values, so the description's Returns section is sufficient without needing to detail every field.

  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 description coverage is 0%, so the description must fully compensate. It does so excellently: it clearly documents both parameters (oldest_date, newest_date), specifies required vs. optional status, explains format (YYYY-MM-DD), describes default behavior (no upper limit if newest_date not provided), and includes prompt and usage examples that illustrate parameter usage. This adds substantial meaning 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 explicitly states the tool's purpose as 'fetching activities from intervals.icu for the configured athlete' and distinguishes it from siblings by noting it's the 'Primary tool' for getting a 'complete list of activities within a date range'. It clearly specifies the verb (fetching/getting), resource (activities), and scope (date range, configured athlete).

  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 guidance with dedicated sections: 'Best for:' lists specific use cases (complete list, analyzing training history, exporting), 'Not recommended for:' warns against large date ranges without pagination and real-time tracking, and 'Tool Relationships:' directs to sibling tools (get_grouped_activities for aggregated analysis, get specific details as needed). This covers when to use, when not to use, and alternatives.

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

• get_grouped_activitiesA
  4.7/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 effectively describes the tool's purpose, common mistakes (e.g., invalid group_by values), and return structure, though it lacks details on rate limits, authentication needs, or error handling beyond the 'Raises' section. It adds significant value beyond the input schema without contradicting any annotations.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (Best for, Not recommended, Parameters, Returns, etc.), but it includes redundant elements like the JSON usage example and prompt examples that could be condensed. Most sentences earn their place by providing useful information, though some formatting adds bulk without proportional value.

  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 4 parameters, 0% schema coverage, no annotations, but an output schema, the description is highly complete. It covers purpose, usage guidelines, parameters, returns, errors, and relationships with sibling tools, providing all necessary context for an agent to understand and invoke the tool correctly without relying on structured fields.

  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?

  Given 0% schema description coverage, the description compensates fully by detailing all parameters in the 'Parameters' section, including their purposes, formats, defaults, and optionality. It explains 'oldest_date' as the oldest date to fetch from, 'newest_date' as an optional upper limit, 'group_by' options, and 'include_details' effect, adding crucial meaning 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 tool 'fetches and groups activities to reduce data volume and show patterns,' which is a specific verb+resource combination. It distinguishes from sibling tools like 'get_activities' by emphasizing grouping and summarization rather than individual activity retrieval, making the purpose unambiguous and differentiated.

  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 guidance with 'Best for' and 'Not recommended for' sections, clearly outlining when to use this tool versus alternatives. It mentions using it after 'get_activities' for analysis or directly for summarized data, and warns against using it for individual details or real-time tracking, offering comprehensive usage context.

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

• get_grouped_wellnessA
  4.7/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 effectively describes the tool's behavior: it groups data over time periods, returns averages and statistics, and includes warnings about common mistakes (e.g., invalid group_by values). However, it lacks details on error handling beyond the 'Raises' section, such as rate limits or authentication needs, which could be more explicit for a tool with no annotations.

  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 well-structured with clear sections (e.g., 'Best for:', 'Parameters', 'Returns'), but it is somewhat lengthy due to including examples and detailed parameter info. Every sentence adds value, such as usage examples and tool relationships, but it could be more front-loaded by emphasizing key points earlier to improve efficiency.

  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 complexity of the tool (4 parameters, no annotations, schema coverage 0%), the description is highly complete. It covers purpose, usage guidelines, parameters, returns (with an output schema provided), and error handling. The presence of an output schema reduces the need to explain return values in detail, and the description supplements this adequately with examples and contextual info.

  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 description coverage is 0%, so the description must compensate fully. It does so by providing detailed parameter semantics in the 'Parameters' section, including data types, formats (e.g., YYYY-MM-DD), optionality, default values, and allowed options for 'group_by' (e.g., 'week', 'month', 'all'). This adds significant meaning beyond the basic 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 the tool's purpose: 'fetching and grouping wellness data to show trends and patterns.' It uses specific verbs ('fetching,' 'grouping') and distinguishes from sibling tools by mentioning 'get_wellness' for individual records versus this tool for trend analysis. The title is null, so the description fully carries this burden.

  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 guidance with 'Best for:' and 'Not recommended for:' sections, clearly stating when to use this tool (e.g., analyzing trends over time) versus alternatives (e.g., individual day analysis). It also includes 'Tool Relationships' that references sibling tools like 'get_wellness' for context on when to use this tool directly or after others.

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