Server Quality Checklist

Tool Scores

• analyze_seriesC
  2.6/5.0
  Behavior2/5

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

  No annotations exist, so the description carries the full burden. It adds the trait 'deterministic', which is useful, but it does not disclose whether the operation is read-only, if there are side effects, or what the output format is. This is insufficient given the tool's complexity.

  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?

  A single, front-loaded sentence with no wasted words. Every phrase contributes to stating the tool's core capability, and it is appropriately sized for the information it conveys.

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

  Completeness1/5

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

  The tool has 12 parameters, no output schema, and no annotations, yet the description provides no detail on how to invoke it, what the parameters mean, what a 'cataloged series' is, or what results to expect. This is severely incomplete for a tool of this complexity.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any of the 12 parameters, including required ones like dataset, metrics, and analysis. It only lists analysis types that already appear in the schema enum, adding no value beyond structure.

  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 uses 'Run' as a specific verb and enumerates concrete analysis types (rolling statistics, baselines, correlations, seasonal comparisons, trends), making the tool's function clear. However, it does not explicitly distinguish from sibling tools like aggregate_data or fit_series_model, and the phrase 'cataloged series' is somewhat ambiguous.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as aggregate_data, read_series, or fit_series_model. The description implies it is for analytical computations but lacks explicit context, exclusions, or prerequisites.

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

• cycling_progress_reportB
  3.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It explicitly states 'Read-only and descriptive,' giving a clear safety signal. However, it does not explain what 'source-aware' means, how the report is structured, or how data is handled, leaving notable behavioral 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 two sentences, efficient, and front-loaded with the core action. Every phrase contributes meaning—'source-aware,' 'monthly canonical volume/load,' and 'labelled power-curve trends'—without unnecessary filler.

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

  Completeness2/5

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

  For a report generator that integrates multiple data sources, the description is too thin. It doesn't specify output format, how sources are combined, or edge cases like missing data. There is no output schema or annotations to fill the gaps, leaving a complex tool under-specified.

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

  Parameters2/5

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

  The schema defines startDate and endDate with formats but no semantic descriptions. The tool description never mentions these parameters or clarifies that they delimit the reporting period. With 0% schema description coverage, the description should compensate but does not.

  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 combines FTP and VO₂max histories with volume/load and power-curve trends to build a cycling progress report. The verb 'Combine' and resource specification make it distinct from sibling tools like get_ftp_history or power_curve_trend, which focus on individual data sources.

  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?

  Usage is implied: you'd use this when you want a comprehensive summary across multiple cycling metrics. However, there is no explicit statement of when to use this over specific sibling tools, nor any mention of alternatives or exclusions.

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

• search_contextB
  3.1/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 results are follow-up tool suggestions rather than numerical answers, which is helpful, but it omits other behavioral details such as pagination, response shape, or rate limiting.

  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 a single, direct sentence with no filler or redundant information. It is front-loaded with the action and resource.

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

  Completeness2/5

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

  The description does not explain how to use the filters, what the output format is, or how the tool determines follow-up tools. Given no output schema and no annotations, this is too sparse for a search tool with structured filtering.

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

  Parameters1/5

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

  The schema has three parameters with 0% description coverage, and the description provides no information about 'query', 'limit', or 'filters'. It fails to compensate for the lack of schema descriptions, leaving parameter semantics entirely undefined.

  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 names a specific verb ('Search') and a concrete resource ('compact generated activity, plan, nutrition, and message context') and adds a unique role ('identify authoritative follow-up tools'). This helps differentiate it from sibling data-query tools, though the distinction is not fully explicit.

  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 phrase 'rather than making numerical claims' implies this tool is for routing to other tools rather than getting numeric data, but it does not explicitly state when to use this tool versus alternatives or when not to use it.

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

• latest_cycling_activitiesB
  3.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 burden of behavioral disclosure. It explicitly states the operation is read-only, explains deduplication behavior, and notes the optional multisport flagging. It does not cover pagination, sorting, or error behavior, but the provided safety and dedup details are valuable.

  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 concise sentences, front-loaded with the action and resource. Every phrase adds value, including the deduplication caveat and the read-only note, with no redundant or filler text.

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

  Completeness3/5

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

  For a simple list operation with four optional parameters and no output schema, the description gives a reasonable overview but misses key context like date-range semantics, limit usage, and the return format. The dedup and multisport details help, but the tool is not fully specified for an agent to invoke without further inference.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain limit, startDate, or endDate. It only indirectly hints at includeMultisport via 'optionally flagging multisport parent records'. The description does not compensate for the lack of parameter documentation.

  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 lists Garmin cycling source records, with specific verbs and resource. It distinguishes from siblings by focusing on Garmin cycling data and mentioning deduplication of Intervals summaries, though the term 'latest' is not restated in the description.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives like find_activities or read_series. It implies its purpose through the name and title but lacks exclusions or alternative tool recommendations.

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

• power_curve_trendB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description states 'Read-only', which is a key behavioral trait. It also hints at response contents ('supporting activity and source type'), but omits details on parameter dependencies, date range behavior, or default handling, which is a gap 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?

  A single concise sentence that leads with the action and includes relevant scoping information. Every word earns its place; no redundancy.

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

  Completeness2/5

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

  This is a 6-parameter tool with no annotations and no output schema, yet the description is only one sentence. It does not explain what 'labelled' means, the exact output structure, the handling of no parameters, or the interpretation of monthly bests across a date range. The description is insufficient for reliable agent use.

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

  Parameters2/5

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

  Schema description coverage is 0%. The description partially maps to parameters via 'sport or sport family' and 'source type', but entirely omits startDate and endDate. It does not explain how dates influence 'monthly bests' or the logical requirement to specify at least one of sport/sportFamily despite no required parameters.

  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 'Return monthly bests for selected power durations' with scoping via 'sport or sport family' and supporting activity/source type. This specific verb+resource structure distinguishes it from sibling trend tools like get_ftp_history or get_vo2max_history.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives. The description implies a use case but does not mention exclusions, prerequisites, or alternative tools, leaving the agent to infer selection from the title alone.

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

• aggregate_dataB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description must fully disclose behavioral traits. It only states that it is declarative and constrained, but does not explain return behavior, side effects, read-only nature, or edge cases. This is a significant transparency gap for a tool with no output schema or annotation support.

  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 extremely concise, containing only two short sentences. It front-loads the core purpose ('Declarative aggregation over one cataloged dataset') and appends relevant constraints. Every word earns its place with no wasted content.

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

  Completeness1/5

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

  The tool is complex: 9 parameters, nested filter objects, several enums, no output schema, and no annotations. The description provides almost no context beyond a one-line summary, leaving the agent without crucial behavioral or semantic details. It is inadequate for safe and correct invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for explaining the 9 parameters. It only clarifies that the dataset is a cataloged dataset and that expressions are limited, which vaguely relates to the 'dataset' and 'metrics' parameters. It provides no meaning for filters, date ranges, dimensions, timeBucket, limit, or orderBy.

  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 identifies the tool's function: declarative aggregation over a single cataloged dataset. It is specific with the verb 'aggregate' and the resource 'cataloged dataset', and the constraints 'No joins, arbitrary expressions, or file paths' further distinguish it from potential sibling 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?

  The description implies when to use the tool: when you need declarative aggregation over exactly one cataloged dataset. It also provides exclusions ('No joins, arbitrary expressions, or file paths'), which informs users about non-intended use cases. However, it does not explicitly name alternative tools or provide detailed when/when-not guidance.

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

• hydrate_strava_segment_historyB
  3.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 of behavioral disclosure. It discloses that the operation is write-only, that it fetches paged historic efforts, and that interrupted work is resumable. However, it does not specify side effects, prerequisites like authentication, or error/return behaviors, leaving ambiguity.

  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 sentences, with the key concept front-loaded ('Write-only targeted enrichment'). It is free of redundancy and appropriately sized for a focused tool.

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

  Completeness3/5

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

  Given the tool has only two parameters and no output schema, the description covers the core behavior (fetching and hydrating segment history) and mentions resumability and pagination. However, it is incomplete for practical use because it omits parameter semantics and any usage restrictions or interactions with sibling tools.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain both parameters. It fails to explain 'refresh' and only implicitly alludes to 'segmentId' via 'persisted Strava segment'. This leaves the agent without enough context to correctly set parameter values.

  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: it fetches a persisted Strava segment and the athlete's historic efforts for that segment, serving as a targeted enrichment action. It distinguishes itself from sibling tools like hydrate_strava_activity by focusing specifically on segment history.

  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 does not provide explicit when-to-use guidance or mention alternatives among the sibling hydration tools. The 'resumable' note hints at retry scenarios but lacks a clear directive on when to select this tool over hydrate_recent_strava_activities or hydrate_strava_activity.

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

• describe_dataA
  3.5/5.0
  Behavior3/5

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

  The description includes 'Read-only,' which is a valuable safety signal. However, with no annotations, it does not fully disclose other behavioral traits such as output format, pagination, or whether all datasets are returned at once. It partially carries the burden but leaves gaps.

  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 a single sentence, front-loaded with the action verb 'List,' and contains no filler. It efficiently conveys the tool's purpose and key output categories.

  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 description covers the main aspects of the tool: it lists data categories (datasets, fields, units, filters, providers, time coverage) and notes it is read-only. With no output schema, it provides enough context for an agent to understand what the tool returns, though it could be more explicit about the exact return structure.

  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, and the schema is empty. The baseline for 0 params is 4. The description adds meaning about the tool's output, but no parameter semantics are needed, so this score is appropriate.

  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 'List cataloged datasets' with specific attributes (fields, units, permitted filters/groupings, providers, time coverage). This distinguishes it from more specific tools like 'describe_dataset', though it does not explicitly differentiate from that sibling.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention that describe_dataset might be used for single-dataset details, nor any preferred context for using describe_data. The read-only hint is a behavioral trait, not usage guidance.

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

• fit_series_modelA
  3.5/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 behavioral disclosure. It adds useful context by mentioning 'bounded' and 'descriptive,' and clarifies scope with 'Not a sport-performance model.' However, it does not disclose output format, read-only nature, or any side effects, leaving significant gaps.

  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 sentences, front-loaded with the core action and model types, followed by a concise scope disclaimer. Every word earns its place with zero waste.

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

  Completeness2/5

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

  The tool has 12 parameters, no output schema, and no schema descriptions. The minimal description cannot adequately guide an agent on how to use the tool correctly; it lacks details on required inputs, interpretation of results, and how it differs from similar tools like analyze_series or aggregate_data.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only clarifies the model parameter by listing the specific model types (OLS, Theil–Sen, quadratic, cubic), but leaves dataset, metrics, filters, dates, and other 8+ parameters entirely unexplained.

  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 fits a bounded OLS, Theil–Sen, quadratic, or cubic descriptive model. It uses a specific verb ('Fit') and resource, and the explicit 'Not a sport-performance model' distinguishes it from sports-related siblings like power_curve_trend and get_ftp_history.

  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 an implicit usage context by naming the model types and explicitly excluding sport-performance modeling, which hints at when not to use it. However, it does not name alternatives or provide explicit 'when to use' guidance, relying on the tool name and sibling context.

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

• get_ftp_historyA
  3.6/5.0
  Behavior4/5

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

  The description explicitly includes 'Read-only,' which is crucial given that no annotations are provided. It also adds behavioral context with terms like 'normalized' and 'source-aware preferred daily values,' disclosing processing behavior. However, it doesn't detail how source preference is resolved, so some ambiguity remains.

  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 a single, information-dense sentence followed by 'Read-only.' It front-loads the core action and resource, with zero wasted words or redundant filler.

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

  Completeness2/5

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

  With no annotations, no output schema, and 0% parameter coverage, the description carries the full burden. It clarifies the general topic but omits return format, date-range behavior, default values, and parameter interplay, leaving an agent under-equipped to invoke the tool correctly.

  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?

  With 0% schema coverage, the description must compensate for parameter ambiguity. It indirectly covers date parameters via 'dated' and sourcePreference via 'source-aware,' but sport is unmentioned and the enum values for sourcePreference are not explained. The description adds some meaning but not enough to fully replace schema descriptions.

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

  Purpose5/5

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

  The description uses a specific verb ('Return') and names a precise resource ('normalized cycling FTP settings and activity-summary observations'), making the tool's function clear. It distinguishes from sibling tools like get_vo2max_history by focusing on FTP and source-aware daily values.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives such as read_series or query_read_only_data. The description lacks explicit use cases, prerequisites, or exclusions, so an agent receives no help choosing between overlapping read-only tools.

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

• read_seriesA
  3.6/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 disclose two notable behaviors: deterministic cursor pagination (stable pagination across requests) and automatic stream downsampling (data resolution may be automatically reduced). However, it omits other pertinent behaviors such as ordering, limits, error handling, or the meaning of 'bounded' in the title. Some transparency is provided, but critical gaps remain.

  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 a single, compact sentence of 11 words. It is front-loaded with the core action ('Read') and packs three meaningful concepts (read, pagination, downsampling) without any wasted words. Every phrase earns its place.

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

  Completeness2/5

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

  Given the tool's complexity (9 parameters, no output schema, no annotations), this description is too sparse. It does not describe the response format, how filters interact with series, whether startDate/endDate are required despite being optional in the schema, or what 'bounded' means in practice. A single sentence is insufficient for an agent to safely invoke this tool with a correct mental model of its behavior.

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

  Parameters3/5

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

  The input schema has 0% description coverage, so the description must compensate. It does add meaning to several parameters: 'cataloged' hints at dataset semantics, 'numeric series' clarifies metrics, 'pagination' relates to cursor and pageSize, and 'downsampling' explains resolution. However, it leaves filters, startDate/endDate, activityId, and other parameters unexplained. The description adds some value but does not fully compensate for the missing schema descriptions.

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

  Purpose5/5

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

  The description uses the verb 'Read' with a specific resource ('cataloged numeric series') and adds distinctive features ('deterministic cursor pagination', 'automatic stream downsampling'). It clearly differentiates from siblings like aggregate_data, analyze_series, and fit_series_model, which imply transformation or modeling rather than raw data access.

  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 a read operation for cataloged numeric series, suggesting it is the tool for fetching time series data. However, it does not explicitly state when to use this tool versus alternatives like query_read_only_data or describe_dataset, nor does it provide exclusion criteria. The usage context is implied but not articulated.

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

• swim_progress_reportA
  3.7/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 one behavioral trait (does not derive pace trends from moving time/distance), but provides no information about whether the operation is read-only, what side effects might exist, or what 'source-aware' and 'data completeness' mean in practice. This is marginally more than a minimal mention.

  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 exactly two sentences, with the main purpose front-loaded and the clarifying negative statement second. Every word 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.

  Completeness3/5

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

  The tool has no output schema and no annotations, so the description should explain what the report returns and any edge cases. It mentions 'data completeness' but doesn't define it, nor does it describe the output format or potential errors. The core purpose is clear but the context around the report's content is incomplete.

  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 0%, so the description must add meaning. It implicitly maps 'date range' to startDate/endDate and 'pool length' to poolLengthM, but it does not explain the semantics of 'data completeness' or how the parameters interact. The parameter names are self-explanatory, but the description adds limited 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 uses a specific verb ('Compare') and clearly identifies the resource ('Garmin swimming summaries and data completeness') and scope ('over a date range, optionally within one pool length'). The negative statement ('It does not derive pace trends...') helps distinguish it from trend-based sibling tools like cycling_progress_report or power_curve_trend.

  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 when to use the tool (comparing Garmin swimming summaries over a date range) and mentions the optional pool length filter, but it does not explicitly name alternatives or state when not to use it. The negative statement about pace trends offers a hint but no direct alternative.

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

• find_activitiesA
  3.8/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full transparency burden. It discloses pagination, read-only behavior, and the nuanced caveat that likely-race flags are not provider-confirmed, which adds valuable context beyond basic functionality. It does not cover auth or rate limits, but for a read-only search tool this is adequate.

  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 sentences with no filler, front-loading the core purpose and then adding key behavioral caveats. Every clause earns its place, making it highly efficient.

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

  Completeness3/5

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

  With 8 parameters, no schema descriptions, and no output schema, the description covers the core filtering and pagination behavior but omits operational details such as default sort, cursor usage, and distance unit semantics. It is adequate for an initial agent selection but leaves several runtime details to be discovered.

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

  Parameters2/5

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

  Schema property descriptions have 0% coverage, and the description only explains four parameter categories (sport, distance, name, date) while ignoring sort, limit, and cursor. It adds meaning with terms like 'canonical' and 'likely-race,' but leaves most parameters unexplained, forcing the agent to rely on schema names alone.

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

  Purpose5/5

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

  The description uses a specific verb ('find') and clearly identifies the resource ('canonical activities') plus filter dimensions (sport, distance, name, date). The title and description distinguish this as an activity discovery and race-detection tool, separating it from sibling tools that describe, aggregate, or hydrate data.

  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 provides clear context for what the tool does, implying it should be used when searching for activities by filters. However, it does not explicitly name when to use this tool over alternatives or mention exclusions, so an agent must infer precedence relative to siblings like get_activity_segments or read_series.

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

• get_activity_segmentsA
  3.8/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 and does disclose a key behavioral trait: it automatically hydrates the activity before returning results. However, it omits side effects of hydration, rate limits, possible errors, and whether refresh forces re-hydration, leaving important behavioral gaps.

  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 sentences, front-loaded with the purpose, and the second sentence adds a valuable usage directive. Every word earns its place with no repetition or filler.

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

  Completeness3/5

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

  There is no output schema and no annotations, so the description should carry more context. It communicates the core workflow and return type ('persisted segment efforts'), but leaves out limit pagination behavior, refresh semantics, and failure cases—making it adequate but not fully complete.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It indirectly clarifies activityId (the selected activity), but limit and refresh are not explained at all, leaving their semantics and effect ambiguous to the agent.

  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 a specific verb and resource: it hydrates a Strava activity and returns its persisted segment efforts, covering segments, climbs, KOM/PRs, and per-segment analysis. This distinguishes it from sibling tools like hydrate_strava_activity by centering on reading segment data after hydration.

  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 gives explicit usage context: 'For a selected activity's segments, climbs, KOM/PRs, or per-segment analysis' and directs the agent to 'Use this before saying segment data is unavailable.' It does not explicitly mention when not to use it or name alternatives, so it falls 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.

• hydrate_recent_strava_activitiesA
  3.8/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 behavioral disclosure. It reveals that the tool is write-only, processes activities one at a time, and reports every outcome, which is useful. However, it does not mention side effects, idempotency, required permissions, or error behavior, leaving significant gaps.

  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 just two sentences, front-loaded with the core purpose ('Write-only targeted batch enrichment'). Both sentences add non-redundant information, 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.

  Completeness2/5

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

  Given six parameters, no output schema, and no annotations, the description is insufficiently complete. It does not clarify what 'hydrate' actually does, what the outcome reports look like, or the purpose of limit/refresh, making it risky for an agent to invoke confidently.

  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 has 0% description coverage, so the description must compensate. It adds high-level meaning by distinguishing an 'explicit list' (activityIds) from a 'bounded date/sport window' (startDate, endDate, sports). Yet it does not explain 'limit' or the 'refresh' boolean, which are ambiguous without further context.

  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 it is a 'write-only targeted batch enrichment' and explains how to select activities via an explicit list or bounded date/sport window. This distinguishes it from sibling hydrate_strava_activity, which is singular, by emphasizing batch processing and 'several recent' activities.

  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 when to use this tool by contrasting 'batch' against the singular hydrate_strava_activity and by offering two selection modes (explicit list vs. date/sport window). However, it does not explicitly name alternatives or state when not to use the tool, so it stops short of a full exclusion set.

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

• describe_datasetA
  3.9/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 burden of behavioral disclosure. It states 'Read-only,' which is a key behavioral trait, and enumerates what the tool returns. However, it does not clarify the meaning of 'compact schema' or describe any potential errors or prerequisites. The added context is useful but not extensive.

  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 concise sentences with no filler. The first sentence states the primary purpose and output scope, and the second adds the read-only nature. It is front-loaded and every word adds value.

  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 simplicity (one parameter, no output schema), the description is fairly complete. It lists the specific aspects returned (schema, filters, provenance, coverage) and clarifies that it is read-only. Minor gaps exist, such as not explaining the 'dataset' parameter or what 'compact schema' entails, but these are not critical for a low-complexity read tool.

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

  Parameters2/5

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

  The input schema has a single parameter 'dataset' with only a type and minLength. Schema description coverage is 0%, so the description must explain this parameter. The phrase 'one cataloged dataset' hints that 'dataset' identifies a specific dataset, but does not specify whether it's a name, ID, or how to obtain it. This minimal guidance does not adequately compensate for the lack of schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool 'Read a compact schema, permitted filters/groupings, provenance fields, and coverage for one cataloged dataset.' The verb 'Read' is specific, and the resource is a single cataloged dataset. This distinguishes it from sibling tools like 'describe_data' by emphasizing the scope ('one cataloged dataset').

  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 when to use this tool: when you need metadata about a specific dataset, such as its schema, filters, provenance, and coverage. It also notes 'Read-only,' indicating a safe, non-mutating operation. However, it does not explicitly mention alternatives or exclusions, so it falls 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_vo2max_historyA
  3.9/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 transparency burden. It explicitly states 'Read-only' and discloses that observations are 'normalized' and that 'generic and cycling values remain separate', which are useful behavioral traits beyond a simple read. It lacks details on output format or error handling, but the provided context is valuable.

  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 concise sentences, front-loaded with the main purpose and immediately adding a key behavioral nuance. Every word adds value with no fluff.

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

  Completeness2/5

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

  Given there is no output schema and no annotations, the description should explain what the return data looks like and the semantics of the parameters. It fails to clarify date range behavior, allowed sport values, or the meaning of 'normalized', leaving significant gaps 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.

  Parameters2/5

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

  Schema description coverage is 0%, and the description only implies the sport parameter by saying 'exactly one sport' but does not define allowed values or clarify that startDate/endDate define a range. The schema marks all parameters as optional, yet the description implies a sport is needed, creating ambiguity. No parameter details are offered.

  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 'normalized Garmin VO₂max observations for exactly one sport', specifying both the resource and scope. It also distinguishes itself from siblings by noting that generic and cycling values remain separate, making it specific to sport-specific VO2max history.

  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 use when you need VO2max data for a single sport, and the note that 'generic and cycling values remain separate' provides context for data granularity. However, it does not explicitly mention alternatives or exclusions, though the sibling list and tool name make the use case clear.

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

• catence_statusA
  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 of behavioral disclosure. It does state 'Read-only,' which is a behavioral trait, but it does not disclose additional details such as auth requirements, rate limits, or side effects beyond the read-only nature.

  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 a single concise sentence that lists all relevant data aspects, followed by the 'Read-only' qualifier. Every word serves a purpose, and the structure is front-loaded with action and resource, making it efficient and scannable.

  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 simplicity (no parameters, no output schema, no annotations), the description adequately explains what data is available. It enumerates the specific status dimensions, which is sufficient for a read-only status tool, though it does not describe the return format or error behavior.

  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, and the input schema is empty. Per the rubric, a baseline score of 4 is appropriate when there are no parameters, as there is no semantic gap to fill.

  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 begins with 'Read sync state, data coverage, entity counts, stream availability, unresolved errors, and retrieval-index freshness,' which clearly enumerates the tool's purpose with specific verbs and resources. It also explicitly labels the tool as 'Read-only,' distinguishing it from mutation tools and aligning with its title.

  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 for checking data status but does not provide explicit guidance on when to prefer this tool over siblings. It lacks mention of alternatives or exclusion criteria, so the usage context is only implicit.

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

• power_coverage_reportA
  4/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 explicitly states 'Read-only,' which is a key safety trait, and discloses the data source ('Garmin FIT-derived power'). It does not mention return format or rate limits, but those are less critical for a read-only report.

  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?

  Three short, purposeful sentences cover purpose, data source, and safety. There is zero redundancy and the key information is front-loaded. It is a model of conciseness.

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

  Completeness3/5

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

  The description covers the core purpose and read-only safety but omits what the report actually returns (e.g., format of the inventory), how date parameters work, and details on the `sourceQuality` enum. For a 5-parameter tool with no output schema, the description is minimally adequate but has clear gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description should compensate. It only addresses 'sport or sport family' (mapping to `sport` and `sportFamily`) but says nothing about `startDate`, `endDate`, or `sourceQuality`. Parameter semantics are largely missing, leaving agents guessing about date filtering and the sourceQuality enum.

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

  Purpose5/5

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

  The description uses the verb 'Report' and specifies the resource: powered activities and the complete duration-best inventory for a sport or sport family. It also differentiates itself from siblings by stating 'Uses Garmin FIT-derived power, not sparse activity summaries,' making it clear what makes this tool distinct.

  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 says the tool is for an 'explicit sport or sport family' and contrasts with 'sparse activity summaries,' giving context on when to use it. However, it does not explicitly name alternative tools or provide a full when-not-to-use list, so it falls 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.

• hydrate_strava_activityA
  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 takes on the burden of disclosing side effects. It explicitly says 'Write-only' and states it 'archives and persists' activity data, making the mutating nature clear. However, it does not mention error behavior, idempotency, or what happens if no match is found, which prevents a higher score.

  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 sentences with the central action front-loaded in 'Write-only targeted enrichment.' Every sentence adds value: purpose, detailed effects, and an alternative. No 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?

  For a write operation with no annotations and no output schema, the description covers the main usage context, side effects, and an alternative. It lacks details about the refresh parameter, return value, and failure modes, but the core use case is sufficiently described.

  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 0%, so the description must compensate for both parameters. It clarifies that activityId refers to a 'Catence activity/source' rather than a Strava ID, but it says nothing about the optional 'refresh' boolean, which is a notable gap. It partially compensates but is incomplete.

  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: 'Write-only targeted enrichment' that 'safely matches exactly one Catence activity/source to Strava, then archives and persists its activity detail, gear assignment, and segment efforts.' This specific verb-resource combination distinguishes it from sibling tools like hydrate_recent_strava_activities (batch) and get_activity_segments (read-only).

  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 provides when-not-to-use guidance: 'For a segment/climb request, prefer get_activity_segments, which invokes this prerequisite automatically.' It also implies targeted single-activity usage versus batch hydration via the 'exactly one' phrasing.

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

• get_swim_lapsA
  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 of behavioral disclosure. It explicitly states that only source-aware data is returned, missing lists are reported as unavailable, and laps are never reconstructed from samples. This is highly transparent.

  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 sentences, front-loaded with the primary action and followed by a concise caveat. Every sentence earns its place with no unnecessary detail.

  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 simplicity (two parameters, no output schema, no annotations), the description covers purpose, missing-data behavior, and a key exclusion. It could benefit from mentioning the return format or structure, but overall it is sufficiently complete.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaning to the provider parameter by contrasting Garmin detected vs Intervals.icu auto-detected sets, and clarifies the source-aware behavior. ActivityId is not described but is self-explanatory as a common identifier.

  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 a specific verb ('Return') and identifies the exact resource: source-aware swim lengths, plus Garmin/Intervals.icu detected sets. It distinguishes from siblings by emphasizing source-awareness and the explicit rule that laps are never reconstructed from samples, making its scope unmistakable.

  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 when to use this tool: when provider-supplied swim lengths are needed, and when not: when reconstructed laps would be acceptable, since 'laps are never reconstructed.' It does not name specific alternatives, but the boundary is clear.

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

• query_read_only_dataA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description fully carries the burden of behavioral disclosure. It explicitly mentions deterministic cursor pagination, incomplete-result reporting, and rejects filesystem access, extensions, DDL, and mutation. This gives the agent a precise safety and behavior model.

  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?

  Two dense sentences cover purpose, constraints, pagination, and incomplete reporting. Every clause adds value; no filler 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 description covers the core operation, constraints, pagination behavior, and result completeness. However, with no output schema, it does not describe the exact shape of results beyond the incompleteness flag, and it assumes the agent knows what 'cataloged views' are. Still, this is quite complete for a flexible SQL query tool.

  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 has 0% description coverage, so the description must add meaning. It does so by explaining that the sql must be a single parameterized SELECT/WITH, that pagination is cursor-based, and that values are parameterized. This adds meaningful context 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 action ('query'), the resource ('cataloged read-only data'), and the specific mechanism ('parameterized SELECT or WITH … SELECT'). The phrase 'Advanced fallback' distinguishes this from the domain-specific sibling 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?

  The description gives clear usage context by labeling it an 'Advanced fallback' and by specifying allowed operations (SELECT/WITH over cataloged views only). It does not explicitly name alternative tools or say when not to use it, but the constraints provide strong guidance.

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