Server Quality Checklist

Tool Scores

• call_routed_toolA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full burden of explaining behavior. It only says 'invoke a tool' without mentioning potential side effects of the dynamically called tool, error handling for invalid names or arguments, or that arguments must be passed as a JSON string. This lack of detail is concerning for a tool that could trigger arbitrary operations.

  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, using only two sentences and a short argument list. It is front-loaded with the core purpose, and every sentence earns its place without unnecessary 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?

  As a dynamic tool invoker, the description is thin. It does not explain how to use the tool in conjunction with route_tools, what happens on failure, or that it may execute destructive operations depending on the routed tool. The presence of an output schema does not compensate for these missing behavioral details.

  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 description adds some meaning by stating the name must be 'Exact tool name from route_tools output' and that arguments is a 'JSON object.' However, it contradicts the schema which declares arguments as a string, leaving ambiguity about the expected format. Despite 0% schema coverage, the description only partially compensates for this gap.

  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 'Invoke a tool returned by route_tools,' using a specific verb and resource. This distinguishes it from sibling domain-specific tools like get_athlete_profile or list_activities, making its role as a meta-tool obvious.

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

  Usage Guidelines4/5

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

  The description clearly indicates the tool is for invoking tools returned by route_tools, providing a clear context for use. However, it does not explicitly state when not to use it or list alternative approaches, though the context is self-sufficient.

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

• create_eventA
  3.9/5.0
  Behavior2/5

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

  Annotations only indicate idempotentHint=false and destructiveHint=false. The description adds no behavioral context beyond 'create'—it doesn't mention idempotency implications, required authentication/authorization, whether duplicates are possible, or the structure of the created resource. With sparse annotations, the description carries more burden but fails to disclose meaningful behavioral traits.

  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 opening purpose and usage sentences are concise and front-loaded. However, the Args section duplicates schema-provided parameter details, making part of the description redundant and not fully earning its place.

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

  Completeness4/5

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

  For a creation tool with a fully described schema and an output schema, the combination of description and schema is largely sufficient. It could benefit from noting side effects or response characteristics, but the essential context for invoking the tool is present.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the description's Args block essentially restates the same parameter descriptions found in the input schema. It adds no new semantic meaning, so it earns the baseline score for relying on schema completeness.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'Create a new planned workout, race event, or note on the calendar.' This clearly defines the tool's scope and distinguishes it from sibling tools like update_event and delete_event.

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

  Usage Guidelines5/5

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

  It explicitly states when to use the tool ('Use when scheduling upcoming training or race events') and provides a direct alternative for modification ('To modify an existing calendar event, use update_event'). This gives clear guidance for tool selection.

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

• get_athlete_profileA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds a small amount of behavioral context by listing the specific metrics returned, but it doesn't elaborate on authentication, rate limits, error cases, or other runtime behaviors beyond the annotation.

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

  Conciseness5/5

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

  The description is three concise sentences: purpose, usage, and argument explanation. It is front-loaded with the core function, contains no fluff, and every sentence provides 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?

  For a simple read-only tool with one optional parameter and an output schema, the description is sufficiently complete. It states what data is fetched, when to use it, and the parameter's default behavior. Minor gaps like error handling are low-risk for this use case.

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

  Parameters3/5

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

  The input schema already covers 100% of the parameter with a description identical to the 'Args' section in the description text. Thus, the description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description opens with 'Fetch athlete profile details, including FTP, LTHR, weight, max HR, and training zones,' which is a specific verb+resource statement that clearly differentiates it from sibling tools focused on activities, events, wellness, etc. It precisely states what data is returned.

  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 second sentence, 'Use to inspect baseline athletic physiological metrics and training zone configurations,' provides clear context on when to use the tool. However, it does not explicitly mention alternatives or exclusion conditions, though no sibling tool directly overlaps with athlete profiles.

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

• delete_eventA
  4.1/5.0
  Behavior3/5

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

  Annotations already disclose idempotent and destructive traits, so the bar is lower. The description adds the context that deletion is by ID and within the training calendar, but doesn't add details beyond that. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is concise, front-loaded with the action, and follows a clear structure (purpose, usage, args). Every sentence earns its place without unnecessary filler.

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

  Completeness5/5

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

  For a simple delete tool with two parameters, complete schema coverage, an output schema, and annotations covering safety, the description plus structured data are sufficient to select and invoke the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters fully described. The description repeats the argument names and defaults but adds no new semantic information beyond what the schema already provides.

  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 'Delete a calendar event or planned workout by ID' with a specific verb and resource, and distinguishes itself from sibling tools like delete_activity by focusing on calendar events/workouts.

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

  Usage Guidelines4/5

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

  The description provides explicit usage context: 'Use to remove canceled workouts or events from the training calendar.' While it doesn't explicitly mention alternatives, the distinct resource (events vs. activities) is clear from the sibling tool names and the description.

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

• get_wellnessA
  4.1/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already covers the safety profile. The description adds contextual scope (single-day retrieval) but does not disclose any additional behavioral traits such as error handling, rate limits, or authentication requirements. It is consistent with annotations, but the value beyond them is limited.

  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 a lead sentence, a usage note, and a compact argument list. The Args section is somewhat redundant with the schema, but overall it is concise 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?

  With a detailed output schema present and annotations covering read-only behavior, the description sufficiently covers purpose, usage context, and parameter intent. It could mention what specific metrics are returned, but the output schema addresses that. No significant gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both parameters are fully described in the schema. The description's Args section simply restates the schema without adding new semantic meaning. This meets the baseline but no more.

  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 'Fetch wellness record for a specific date,' using a specific verb, resource, and scope. It clearly distinguishes from the sibling tool list_wellness, which handles multiple days, by explicitly mentioning the single-day focus.

  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 provides explicit when-to-use guidance ('when examining a single day's physiological metrics') and explicitly names the alternative for multi-day queries ('To list metrics across multiple days, use list_wellness'). This fully orients the agent.

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

• list_workoutsA
  4.1/5.0
  Behavior3/5

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

  The readOnlyHint annotation already covers safety, and the description is consistent with a read operation. The description adds the 'structured library' context but does not disclose additional behavioral traits like pagination or effect scope, which is acceptable for a simple 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.

  Conciseness4/5

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

  The description is concise and front-loaded with purpose and usage guidance, followed by a compact parameter list. The parameter list is redundant with the schema but not bloated, keeping it efficient overall.

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

  Completeness4/5

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

  For a simple read-only list tool with an output schema, the description covers the essential context: what it does, when to use it, and a key alternative. It lacks mention of related sibling tools like list_workout_folders, but this is not critical given the straightforward nature.

  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 100%, and the description's parameter explanations essentially repeat the schema (folder_id as optional filter, athlete_id default). No new semantic information is added beyond what the schema already provides, so a baseline score is appropriate.

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

  Purpose5/5

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

  The description clearly states 'List structured library workouts' with a specific verb and resource, distinguishing from siblings like list_activities and list_workout_folders. The explicit use-case 'browsing reusable workout templates' and the pointer to create_event for scheduling further clarify its unique role.

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

  Usage Guidelines5/5

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

  It explicitly states when to use the tool ('Use when browsing reusable workout templates') and provides an alternative for a common misinterpretation ('To schedule a workout onto the calendar, use create_event'). This is clear, direct guidance.

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

• update_eventA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds 'existing' (won't create) but does not disclose return behavior, partial update semantics, or auth needs beyond what schema/annotations imply.

  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 and front-loaded with purpose and usage guidance. However, the Args section is redundant given the schema's comprehensive parameter descriptions, though it is not excessively long and remains readable.

  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 (5 params, 1 required), rich schema descriptions, complete annotations, and an output schema, the description adequately covers purpose, usage, and exclusions. It does not explain return values, but that is handled by the output schema. Minor gap: no mention of handling non-existent event IDs.

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

  Parameters3/5

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

  Schema coverage is 100% and each parameter already has a description. The tool description's Args section essentially restates the schema with slight wording differences (e.g., 'workout description or details' vs 'workout prescription steps or notes'), adding no significant semantic value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool 'Update an existing calendar event or planned workout' with specific fields (workout targets, start dates, titles). It explicitly distinguishes from create_event, fulfilling sibling differentiation.

  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?

  Provides explicit guidance: 'Use when modifying workout targets, start dates, or titles' and names the alternative 'To schedule a new event, use create_event.' This gives clear when-to-use and when-not-to-use direction.

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

• update_wellnessA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, lowering the bar. The description adds 'Updates only specified fields,' which conveys partial-update semantics beyond the annotations. It does not detail auth or error behavior, but the description is still informative.

  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 front-loads the purpose and usage in the first two sentences, then provides a compact args list. For 10 parameters, the list is appropriately terse and scannable. No filler; every section earns its place.

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

  Completeness4/5

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

  An output schema exists, so the description need not explain return values. With annotations covering idempotency/safety, the description covering update semantics, and schema covering all parameters, the tool is well-specified. Minor missing details like upsert behavior are not critical.

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

  Parameters3/5

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

  Schema coverage is 100% and the schema descriptions already include units, scales, defaults, and examples. The description mostly repeats this information without adding new param-level meaning. The 'Updates only specified fields' note is valuable globally but not parameter-specific, so baseline 3 applies.

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

  Purpose5/5

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

  Description opens with 'Update daily wellness metrics for a given date,' a specific verb+resource+scope combination. It clearly distinguishes from read-style siblings by stating it is for logging/updating wellness metrics. No ambiguity.

  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?

  'Use to log or update daily sleep, weight, HRV, and subjective readiness' provides explicit usage context. 'Updates only specified fields' clarifies an important boundary. It does not name alternatives, but the sibling list/get tools make the alternative obvious.

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

• list_eventsA
  4.2/5.0
  Behavior3/5

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

  The annotations include readOnlyHint=true, so the agent already knows this is a safe read operation. The description adds some context by listing what is included (planned workouts, notes, race events) and the date range constraint. However, it does not disclose potential behaviors like pagination, ordering, or return format. This is similar to the TDQS 4.3 example where annotations cover safety and the description adds date-range scoping, warranting a 3.

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

  Conciseness5/5

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

  The description is concise and well-structured. The first sentence states the core function, the second provides usage context, the third points to an alternative, and the Args section lists parameters succinctly. Every sentence serves a purpose with 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 simple list tool with an output schema (indicated by context signals), the description is largely complete: it states what the tool does, when to use it, and how it differs from get_event. It does not mention pagination or ordering, but these are not required given the output schema likely documents return values. A small gap remains because it does not explicitly state that results are returned as a list, but overall it is adequate.

  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 100%, with each parameter already described in the schema (e.g., 'Start date in YYYY-MM-DD format'). The description's Args section merely repeats parameter names and types, adding no extra semantic value. Per the rubric, with high schema coverage, the baseline is 3, and the description does not exceed that baseline.

  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: 'List calendar events and planned workouts between dates.' This uses a specific verb (List), specifies the resource (calendar events and planned workouts), and scopes it by date range. It also differentiates from the sibling get_event by explicitly mentioning that fetching details of a specific planned event should use get_event.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance: 'Use when browsing planned workouts, notes, or race events on the calendar. To fetch details of a specific planned event, use get_event.' It tells the agent when to choose this tool and names the alternative for a more specific task, clearly distinguishing from a sibling tool.

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

• delete_activityA
  4.3/5.0
  Behavior4/5

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

  Annotations already set idempotentHint and destructiveHint. The description adds value by saying 'permanently remove' (indicating the deletion is irreversible, beyond the bare destructiveHint) and specifying the target as calendar files. It does not contradict annotations, and with the annotation coverage, the bar for additional behavioral disclosure is lower. Missing details like auth requirements are not needed given the simplicity and annotation hints.

  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 plus an args listing. It is front-loaded with the primary action, immediately justifies the use case, and every sentence earns its place. No fluff or redundancy.

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

  Completeness5/5

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

  The tool is simple: one required parameter, an output schema exists, and annotations cover safety traits. The description fully explains what the tool does and when to use it, making it complete for an agent to select and invoke it 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?

  The schema already has 100% coverage for the single parameter activity_id, with its own description 'Unique activity ID to delete.' The Args section repeats this exactly, adding no new meaning. Baseline is 3 due to high schema coverage, and the description does not compensate with additional syntax or format details.

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

  Purpose5/5

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

  The description clearly states 'Delete an activity by ID from Intervals.icu calendar' with a specific verb, resource, and identifier. It also distinguishes itself from sibling delete_event by specifying 'activity' and gives a concrete use case for removing duplicate or invalid uploaded activity files.

  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 phrase 'Use to permanently remove duplicate or invalid uploaded activity files' provides explicit context for when this tool should be used. It does not explicitly mention alternatives or exclusion criteria, but the sibling tool names (delete_event, update_activity) make differentiation apparent.

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

• get_activityA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description adds that the tool returns 'full details and detailed metrics' with examples like Normalized Power and TSS. However, it does not discuss pagination, error conditions, or additional side effects, so the added behavioral context is moderate.

  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 short, front-loaded with the main purpose, and uses a clean Args block. Every sentence serves a purpose—purpose, usage, and parameter definition—without redundancy.

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

  Completeness5/5

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

  Given the tool's simplicity (single required parameter), the presence of an output schema, and the readOnlyHint annotation, the description covers usage context and alternatives sufficiently. It does not need to explain return values because the output schema exists.

  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 and description both describe activity_id as 'The unique ID of the activity' with no additional detail; schema coverage is 100%, so the parameter semantics are adequately covered by the schema 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 opens with 'Get full details and detailed metrics for a single activity,' using a specific verb and object that clearly indicates a single-activity retrieval. It contrasts with 'list_activities' by emphasizing 'single activity' and mentions workout metrics, distinguishing it from other 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 Guidelines5/5

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

  It explicitly states 'Use when analyzing specific workout metrics (e.g. Normalized Power, TSS, HR zones)' and directs to 'list_activities' for listing multiple activities, providing both positive and negative usage guidance.

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

• get_eventA
  4.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already discloses safety, and the description does not contradict it. It adds some behavioral context by noting the tool can also fetch planned workouts and that athlete_id defaults to '0', but otherwise does not reveal additional behavioral traits such as auth requirements or rate limits. Given the annotation coverage, a score of 3 is appropriate.

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

  Conciseness5/5

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

  The description is concise, front-loaded with the core purpose, and includes only essential usage guidance and an alternative. Every sentence contributes value, and the format is scannable. The Args section is minimal and does not bloat the description.

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

  Completeness5/5

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

  The tool is simple (2 parameters, 1 required), has an output schema, and the readOnlyHint annotation. The description explains the primary use case, the alternative for listing, and the parameter defaults, which is complete for the tool's complexity. The output schema handles return values, so no further explanation is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the description adds no new meaning to the parameters beyond what the schema already states. The description repeats the parameter names and defaults but does not enrich them beyond the schema. Baseline 3 applies because the schema fully documents the 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 identifies the tool as fetching details of a single calendar event or planned workout, distinguishing it from list_events by emphasizing 'single' and specific use cases like inspecting workout steps or race plans. The verb 'fetch' and resource are specific, and sibling differentiation is explicit.

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

  Usage Guidelines5/5

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

  The description provides explicit usage context ('Use when inspecting target workout steps or race plans') and names an alternative for date-range queries ('To list events across a date range, use list_events'). This guidance helps the agent choose between get_event and list_events.

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

• list_activitiesA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the 'completed' qualifier and 'activity summaries' scope, which is useful, but it does not disclose potential pagination, ordering, or other behavioral traits. This matches the level of moderate added context seen in the calibration example.

  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 plus an Args list, with no fluff. Purpose, usage, alternative, and parameters are all front-loaded. Every element earns its place.

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

  Completeness5/5

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

  The tool has an output schema, annotations, and clear sibling context. The description provides purpose, usage guidance, alternative tools, and parameter documentation, making it fully contextual for an agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, with parameter descriptions identical to the Args section. The description adds no meaning beyond the schema—it simply restates the same date formats and athlete_id default. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a specific verb+resource+scope: 'List completed workout activities within a date range.' It clearly distinguishes from sibling tools like get_activity by stating it retrieves summaries rather than detailed streams.

  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?

  Explicit usage guidance: 'Use when retrieving activity summaries across a date range.' It directly names the alternative for detailed data: 'To fetch detailed power/HR streams or intervals for a single activity, use get_activity.' This provides both when-to-use and when-not-to-use.

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

• list_wellnessA
  4.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already covers the safety profile. The description adds useful context about date-range scoping and tracked metrics, but does not disclose potential behavioral details such as pagination, ordering, or result limits. This is adequate but not rich beyond the annotation.

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

  Conciseness5/5

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

  The description is compact: a one-sentence purpose, a one-sentence usage guideline, an explicit sibling pointer, and a brief Args list. Every sentence contributes value and there is no redundancy.

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

  Completeness5/5

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

  Given the simple parameter set, the readOnlyHint annotation, and the presence of an output schema, the description provides sufficient contextual completeness. It covers scope, use case, alternatives, and parameter defaults in a minimal, effective way.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the structured schema already fully documents all three parameters. The description's Args block simply repeats the schema information (oldest, newest, athlete_id default) without adding new meaning, earning the baseline score.

  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+resource ('List daily wellness records in a date range') and explicitly distinguishes itself from get_wellness for single-day inspection. This is clear and well-differentiated from siblings.

  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 states when to use this tool ('when tracking trends in sleep, HRV, weight, and readiness over time') and explicitly names an alternative for single-day lookup (get_wellness). This is exemplary guidance.

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

• list_workout_foldersA
  4.3/5.0
  Behavior3/5

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

  The description is brief but does not contradict the readOnlyHint annotation. It adds limited behavioral context beyond the annotation, such as the default athlete ID, but does not describe return format or edge cases. With the output schema available and the readOnlyHint, the bar is lowered; the description provides acceptable baseline transparency.

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

  Conciseness5/5

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

  The description is concise, with three short sentences that provide purpose, usage context, and a parameter note. Every sentence adds value, and the structure is easy to parse.

  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 simple read-only tool with one parameter, an output schema, and clear sibling differentiation, the description is complete. It covers purpose, usage guidance, and parameter default, leaving no critical gaps.

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

  Parameters3/5

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

  Schema coverage is 100% with a single parameter including a default value and description. The description merely restates the athlete_id default, adding no additional meaning beyond the schema. Baseline 3 is appropriate when the schema already documents the parameter.

  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 lists workout folders in the athlete library, using a specific verb and resource. It also distinguishes itself from the sibling tool list_workouts by explicitly noting that list_workouts is for listing workouts within a folder.

  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?

  Explicit guidance is provided: 'Use when browsing workout library structure' and 'To list workouts within a folder, use list_workouts.' This names the alternative tool and gives clear context for when to use this one.

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

• route_toolsA
  4.3/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 implies a read-only discovery operation by saying 'find tools' and pointing to call_routed_tool for invocation, but it does not explicitly state read-only behavior or describe the output characteristics.

  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: a clear purpose statement, a usage directive, and a parameter explanation with example. Every sentence earns its place, and the information is front-loaded.

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

  Completeness4/5

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

  For a simple one-parameter tool, the description is quite complete: it covers the purpose, the sequencing relative to call_routed_tool, and parameter semantics. The existence of an output schema obviates the need to describe return values, so no major gaps remain.

  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 coverage, the description fully compensates by explaining the 'query' parameter as a natural-language description of what the user wants to do, complete with a concrete example ('get athlete FTP'). This gives clear semantic meaning beyond the schema's bare type field.

  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 finds tools relevant to the task, distinguishing it from sibling tools that perform specific operations. It also distinguishes from call_routed_tool by indicating a two-step workflow: find first, then invoke.

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

  Usage Guidelines4/5

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

  Explicitly instructs to call this FIRST and then use call_routed_tool, giving clear sequencing and an example query. It does not provide explicit when-not-to-use cases, but for a routing/discovery tool this is sufficient guidance.

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

• add_activity_messageA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate idempotentHint=false and destructiveHint=false. The description adds context beyond this by explaining the activity is a 'conversation thread' and that the purpose is feedback, which helps the agent understand the operation's side effects. It does not contradict annotations and offers useful behavioral context without duplicating the hints.

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

  Conciseness5/5

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

  The description is concise and well-structured. It leads with the primary purpose, follows with usage guidance and an alternative, and ends with a clear parameter list. Every sentence earns its place with no wasted words or repetition of annotations.

  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 simple two-parameter tool with full schema coverage and an output schema, the description completely captures what an agent needs: purpose, usage context, and an alternative. The description is sufficient for correct invocation without requiring additional inference.

  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 covers 100% of parameter descriptions, so the description's 'Args' section simply mirrors the schema without adding new meaning. The baseline of 3 applies because the description doesn't provide extra format, constraints, or relationships beyond what the schema already states.

  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, resource, and scope: 'Post a comment/note to an activity conversation thread.' The verb 'post' and the specific resource 'activity conversation thread' make the tool's purpose unmistakable. It also distinguishes itself from the sibling tool 'update_activity' by explicitly noting the alternative for editing descriptions.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance: 'Use to add athlete/coach feedback to a workout.' It also gives an alternative: 'To edit activity description directly, use update_activity instead.' This clearly tells the agent when this tool is appropriate and when it is not, directly addressing tool selection.

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

• list_activity_messagesA
  4.5/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true, so the safety profile is already known. The description adds value by specifying the content type (comments and coach messages) and the discussion-thread context. It provides enough transparency for a simple read operation, though it does not detail pagination or ordering, which is acceptable given the output schema exists.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the primary purpose, followed by usage guidance and the arg list. Every sentence earns its place, with no wasted words.

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

  Completeness5/5

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

  The tool is simple (one parameter, read-only), and the description plus annotations and output schema fully cover its use. It specifies when to use it, the alternative for writing, and the content returned, making it contextually complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the description repeats 'Activity ID' in the Args section, adding no new meaning beyond the schema. This meets the baseline but does not enrich 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 verb 'Retrieve' and the resource 'comments and coach messages associated with an activity', distinguishing it from sibling add_activity_message. It also specifies the use case of viewing a discussion thread, making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description explicitly says 'Use to view discussion thread on an activity' and contrasts with 'To post a new message, use add_activity_message', giving a clear when-to-use and an alternative. This is ideal guidance.

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

• update_activityA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the description's addition of 'Only specified fields are updated' provides meaningful partial-update semantics beyond the annotations. It does not contradict the annotations.

  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 succinct and well-organized: an opening sentence, usage guidance, an alternative, and a compact parameter list. Even though the parameter list mirrors the schema, the overall structure is clean and every section serves a clear purpose.

  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?

  With full schema coverage, annotations, and an output schema present, the description provides all necessary context: what it does, when to use it, what parameters mean, and a pointer to an alternative tool. No critical gaps remain.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the Args list in the description merely duplicates the schema descriptions without adding new detail (e.g., type examples are identical). Baseline of 3 is appropriate as the schema itself carries the parameter meaning.

  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 updates metadata fields on an activity, with a specific verb ('Update') and resource ('activity'). It also distinguishes itself from sibling tool add_activity_message by explicitly directing users to that tool for comment posting.

  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?

  Provides explicit when-to-use guidance ('Use when editing activity titles, descriptions, types, or gear assignment') and an alternative (add_activity_message). This clearly differentiates usage from a key sibling.

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