Server Quality Checklist

Tool Scores

• strava_get_activity_kudoersA
  3.5/5.0
  Behavior2/5

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

  Annotations already cover safety (readOnlyHint=true, openWorldHint=true, destructiveHint=false). The description adds only the endpoint, which is trivial. No additional behavioral details such as pagination, ordering, or response structure are disclosed beyond the schema.

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

  Conciseness5/5

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

  The description is a single sentence with no filler, directly stating the tool's purpose. It is front-loaded and appropriately sized for the tool's simplicity.

  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 no output schema, the description should explain the return format. It only states 'Athletes who gave kudos' but does not mention pagination, athlete object structure, or ordering. The annotations cover safety but not response details, leaving a notable gap.

  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 all three parameters (id, page, per_page) documented in the schema. The description adds no parameter-specific meaning, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description explicitly states 'Athletes who gave kudos to an activity' and includes the endpoint path, making the resource and action unmistakable. This clearly differentiates it from sibling tools like get_activity_comments or get_activity_laps.

  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 retrieving kudoers but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It relies on the tool's name and purpose to convey context.

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

• strava_get_activity_commentsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the endpoint, not pagination behavior or response format; 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?

  One concise sentence, front-loaded with the core purpose and API endpoint, 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?

  A simple read-only list tool with good annotations and full schema coverage. No output schema exists, but the description conveys the core function; however, it omits return-value structure and pagination details, which could be helpful for a complete understanding.

  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?

  Input schema has 100% coverage with descriptions for id, page, and per_page. The description adds no parameter-specific meaning, so the baseline 3 is appropriate since schema already documents everything.

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

  Purpose5/5

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

  States 'Comments left on an activity' with the exact API endpoint (GET /activities/{id}/comments), clearly identifying the resource and action. This distinguishes it from sibling tools like get_activity_kudoers and get_activity_laps.

  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 on when to use this tool versus alternatives, nor any mention of pagination defaults, ordering, or activity ownership. The description is purely factual and does not help the agent decide when to invoke it.

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

• strava_get_activity_lapsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the GET endpoint, reinforcing read-only behavior. However, it does not disclose other behavioral traits such as whether laps may be absent, order of results, or response format, so the added value beyond annotations is modest.

  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, front-loaded sentence that succinctly states the purpose and endpoint. Every word is informative, with no redundancy or filler.

  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 read-only tool, the description is adequate. It identifies the resource, endpoint, and read-only nature via annotations. Minor gaps like result ordering or empty-case behavior are not critical given the low complexity and complete schema.

  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 100% coverage for the single 'id' parameter, including a clear description ('The activity identifier') and type constraints. The tool description does not add further parameter-specific information, but it is not needed because the schema fully 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 returns laps recorded for an activity, naming the specific resource and including the endpoint (GET /activities/{id}/laps). This distinguishes it from sibling tools like get_activity_zones, get_activity_comments, etc.

  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 about when to use this tool versus alternatives. The endpoint and resource are implied, but there is no explicit mention of prerequisites, typical use cases, or exclusions for activities without laps.

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

• strava_get_routeA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is established. The description adds output content (segments and estimated moving time) but does not disclose error handling, authentication needs, or other behavioral nuances.

  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 front-loads the resource, includes the endpoint context, and contains no filler or redundant information.

  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 one parameter, good annotations, and a simple read operation, the description adequately communicates the core return contents (segments and estimated moving time). It could mention the full route fields or error scenarios, but for this simple tool it is sufficiently complete.

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

  Parameters3/5

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

  The input schema fully documents the 'id' parameter with type, range, and description, achieving 100% coverage. The description adds no parameter-specific semantics, but the baseline of 3 applies because the schema carries the necessary detail.

  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 'A single route with its segments and estimated moving time (GET /routes/{id})' clearly identifies the tool as retrieving a specific route by ID, distinguishing it from list operations like strava_list_routes. The endpoint specification further reinforces the GET verb and resource.

  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, nor are prerequisites or exclusions mentioned. It does not state that the route ID typically comes from strava_list_routes or that other route-related tools exist.

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

• strava_get_clubA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the HTTP method (GET) which is a useful behavioral detail, but it does not disclose other traits like error behavior, data freshness, or authentication requirements. This is acceptable given the tool's simplicity and annotation coverage.

  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: 'Details of a single club (GET /clubs/{id}).' It is front-loaded, contains zero fluff, and every word serves a purpose.

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

  Completeness4/5

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

  For a simple get-by-id tool with one well-documented parameter, strong annotations, and no output schema, the description is adequately complete. 'Details' implies the return of the club object, and the endpoint clarifies the operation. It could be slightly richer by naming what details are returned, but it is not insufficient.

  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 does not add any parameter-specific meaning beyond what the schema already provides. The 'id' parameter is fully documented in the schema, so the description adds no extra value here.

  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+resource: 'Details of a single club' and includes the endpoint 'GET /clubs/{id}'. This distinguishes it from sibling tool strava_list_clubs, which lists multiple clubs.

  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 usage context is implied by 'single club' — use this when you need a specific club's details, as opposed to listing clubs. However, no explicit alternatives, prerequisites, or exclusions are mentioned, so guidance is only implied rather than stated.

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

• strava_get_athlete_statsA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: the set of activities included (visible to Everyone) and the time ranges, which are not conveyed by annotations. No contradictions detected.

  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 concise sentences, each adding valuable information: what is returned and a critical visibility constraint. Front-loaded with the core purpose, no 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?

  Without an output schema, the description should clarify what 'totals' means (e.g., counts, distances, times) and confirm that the athlete is implicitly the authenticated one. The mention of '{id}' without a schema parameter leaves ambiguity, and the return format is underspecified.

  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 parameters, so the baseline is 4. However, the description references 'GET /athletes/{id}/stats', suggesting an athlete ID parameter that is not in the schema. This introduces ambiguity about how the athlete is selected, which detracts from clarity 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 returns rolled-up ride/run/swim totals across specific time periods (last 4 weeks, year to date, all time) and includes the endpoint. This is specific and distinguishes it from sibling tools like athlete summary or zones.

  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 retrieving aggregate stats, but does not explicitly say when to prefer this over alternatives or any exclusions. It mentions a visibility caveat ('Only counts activities visible to Everyone') but offers no direct guidance on tool selection.

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

• strava_get_activity_streamsA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds meaningful behavioral detail beyond annotations: downsampling to max_points and the intentional response size management ('keep the response small'). This gives the agent awareness of response shaping behavior.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose. It efficiently includes the endpoint, examples of stream types, and the key downsampling behavior. No unnecessary words or repetition.

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

  Completeness4/5

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

  The description provides sufficient context for a read-only data-fetching tool: it specifies the resource, the data types, and the downsampling behavior. With good annotations and full schema coverage, the description is adequate for an agent to select and invoke the tool. However, there is no output schema, so the description could be slightly richer in describing the response structure, but the stream types enumerated give a good sense.

  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 baseline is 3. The description mentions max_points in the context of downsampling, but all parameter semantics (id, keys, max_points) are already fully documented in the schema. No additional meaning is added 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's purpose: 'Time-series data for an activity' with specific stream types (heart rate, power, speed, altitude, cadence). This distinguishes it from sibling tools like laps, zones, comments, and kudoers, which serve different data needs. The inclusion of the endpoint '(GET /activities/{id}/streams)' further reinforces the specific resource.

  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 retrieving time-series activity data but does not explicitly state when to use it over alternatives. It provides context about downsampling ('Streams are downsampled to max_points'), but no direct comparison to siblings like strava_get_activity_laps or strava_get_activity_zones. This is adequate context without explicit exclusions.

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

• strava_get_activity_zonesA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the 'Requires a Strava subscription' prerequisite and the exact GET endpoint, providing useful behavioral context beyond 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?

  One concise sentence that front-loads the tool's purpose, includes the endpoint, and states the subscription requirement. No filler or redundant information.

  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 single-parameter read tool with annotations, the description covers what it returns, the API path, and a key prerequisite. It does not describe output structure, but the lack of an output schema and the simple nature of the tool make this 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?

  With 100% schema coverage and a single parameter, the schema's description 'The activity identifier' is sufficient. The tool description adds no additional parameter semantics 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 names the specific resource ('activity zones'), the metric ('Time spent in each heart-rate and power zone'), and the exact endpoint, clearly distinguishing it from sibling tools like strava_get_activity and strava_get_activity_laps.

  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 clearly implies when to use this tool (when you need heart-rate and power zone breakdown for an activity) but does not explicitly mention alternatives or situations where it should not be used. The subscription requirement is a constraint, not usage guidance.

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

• strava_get_segmentA
  4/5.0
  Behavior4/5

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

  Annotations already indicate a read-only, non-destructive operation, and the description adds valuable context: the exact HTTP method (GET) and the conditional behavior around the athlete's personal-record effort depending on the read_all scope. This exceeds what annotations alone provide.

  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 front-loads the core purpose ('A single segment') and includes necessary technical details without redundancy.

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

  Completeness4/5

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

  For a simple 1-parameter getter with strong annotations, the description sufficiently conveys the response (a segment, with optional PR) and the relevant API context. It lacks explicit failure/error behavior, but that is not essential given the tool's simplicity.

  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% (id is described as 'The segment identifier.'). The description adds no further meaning to the parameter, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly identifies the tool as retrieving a single segment by ID, using a specific endpoint (GET /segments/{id}) and mentioning the optional personal-record effort. This distinguishes it from sibling listing tools like strava_list_starred_segments.

  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 fetching one segment, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusion scenarios. The scope condition for the personal record provides some context, but it is not a direct comparison to available siblings.

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

• strava_list_routesA
  4/5.0
  Behavior4/5

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

  Annotations already cover read-only and non-destructive behavior. The description adds valuable context by specifying the resource scope (only the athlete's own routes) and the auth scope needed for private routes, which goes beyond 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 a single, dense sentence covering ownership, endpoint, and scope requirement. It is front-loaded and every phrase adds value with no 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 paginated list endpoint with strong annotations and a complete schema, the description covers the essential context: resource owner and auth scope. It could optionally mention the response format, but the title and purpose make it obvious.

  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 page and per_page documented, including defaults. The tool description offers no additional parameter details, so the baseline of 3 applies as the schema handles the semantic burden.

  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 lists routes created by the authenticated athlete, includes the endpoint, and thereby distinguishes itself from sibling tools like strava_get_route. The purpose is specific and unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage when needing the authenticated athlete's routes and notes the read_all scope requirement for private routes, but it does not explicitly contrast with alternatives such as strava_get_route or other list tools. Guidance is implicit rather than explicit.

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

• strava_list_starred_segmentsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the data is scoped to the authenticated athlete, but gives no further behavioral details like pagination or rate limits. This is adequate but not rich.

  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 front-loads the core purpose. No filler or redundant information, every word earns its place.

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

  Completeness4/5

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

  For a simple list tool with optional pagination parameters and no output schema, the description covers the essential purpose. It doesn't explicitly state that a list is returned, but the title and endpoint imply it, and annotations cover safety. Minor gap: no mention of usage nuances like pagination behavior, but given low complexity, 4 is fair.

  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 both page and per_page already carrying descriptions. The tool description adds no additional parameter meaning, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool lists segments starred by the authenticated athlete, with a specific verb and resource. It distinguishes from siblings like get_segment (individual segment) and list_activities (activities) by focusing on starred segments.

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

  Usage Guidelines4/5

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

  The description provides clear context: it returns starred segments for the authenticated user. It does not explicitly name alternatives or exclusions, but the scope is unambiguous, making it clear when this tool is appropriate.

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

• strava_list_clubsA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the scope constraint and the HTTP endpoint, but not pagination or response details, which is acceptable for a simple read operation.

  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 with no redundant information. It efficiently conveys the purpose and includes the endpoint for reference.

  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 list operation with fully documented parameters, read-only annotations, and no output schema, the description is sufficient. It clearly states the resource and scope, enabling correct invocation.

  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 provides 100% coverage for both parameters (page and per_page), including descriptions and defaults. The description adds no additional parameter-specific semantics, so this is 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 explicitly identifies the resource (clubs), the scope (authenticated athlete), and the action (list). It clearly distinguishes from sibling tools like strava_get_club, which retrieves a single club.

  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 states clear context: it lists clubs the authenticated athlete belongs to. It does not explicitly mention alternatives or exclusions, but the scope is unambiguous enough for an agent to know when to use it.

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

• strava_get_athleteA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare the tool read-only and non-destructive. The description adds valuable context about the profile:read_all scope requirement and specific fields (bikes, shoes, clubs, FTP, weight), going beyond the annotations to explain data availability.

  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, efficient sentence that front-loads the core function ('Raw profile of the authenticated athlete') and includes the key scope caveat. No redundant wording.

  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 zero-parameter tool with no output schema, the description adequately covers the main purpose and scope-dependent content. It gives concrete examples of included data and the prerequisite scope, making it sufficient for tool selection.

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

  Parameters4/5

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

  There are zero parameters, so schema coverage is trivially complete and no parameter explanation is needed. The description instead clarifies the payload contents, which is useful given no output 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 identifies the tool as retrieving the raw profile of the authenticated athlete, naming the exact endpoint. The word 'raw' distinguishes it from sibling tools like summary, stats, and zones.

  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 does not explicitly state when to use this tool over alternatives, but the scope note and 'raw profile' hint at full-detail use cases. It lacks explicit exclusions or comparisons with sibling tools.

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

• strava_list_activitiesA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral context: newest-first ordering, compact summaries, and a hint about efficient date-range exploration. 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?

  Two sentences with zero filler. The purpose is front-loaded, and the usage tip is concise and actionable.

  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 no output schema, the description covers purpose, ordering, summary format, and endpoint, plus a practical usage tip. It is slightly vague on what 'compact summaries' contain, but adequate for the tool's simplicity and annotation coverage.

  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 covers 100% of parameters with descriptions. The description adds the tip to prefer before/after over paging, but does not add syntax or format details beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 the authenticated athlete's activities, newest first, as compact summaries, with a specific endpoint reference. This distinguishes it from sibling tools like strava_get_activity which targets a single activity.

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

  Usage Guidelines4/5

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

  It provides clear context (authenticated athlete's activities) and a concrete usage tip (use before/after to scope a date range instead of paging blindly). However, it does not explicitly name alternatives or exclusion scenarios, so it's clear but not fully differentiated.

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

• strava_get_gearA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that this is a GET request, returns total logged distance, and explains ID format and provenance, providing useful context beyond 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?

  Two concise sentences, front-loaded with the core purpose, 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?

  For a simple one-parameter read-only tool, the description covers the return value and gives practical ID guidance. Annotations handle safety. It is sufficiently complete 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.

  Parameters4/5

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

  Schema coverage for the single parameter is 100%, but the description adds meaning by giving examples of valid ID formats (b1234567/g1234567) and explaining where to find IDs, which helps the agent correctly populate 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 identifies the resource (gear) and the returned data (bike or shoes with total logged distance), and includes the GET endpoint. This distinguishes it from sibling tools that target activities, segments, or routes.

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

  Usage Guidelines4/5

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

  It provides context on where gear IDs appear (activities and athlete profile), which helps an agent know when to use this tool. It doesn't explicitly discuss alternatives, but no other sibling tool targets gear, so the context is sufficient.

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

• strava_get_rate_limitA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by specifying that the usage is 'from the most recent API call' (indicating it is a snapshot, not live) and by naming the default limits. This goes beyond the annotations without contradicting them.

  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 long, front-loaded with the core function and followed by a practical usage hint. Every sentence 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.

  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) and strong annotations, the description is nearly complete. It explains the source of the data and provides default limits. A slight gap is that it does not specify the exact structure of the returned usage object, but this is not critical for a straightforward status-check 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 tool has zero parameters, and the schema is effectively 100% covered. According to the rubric, 0 parameters warrants a baseline of 4. The description focuses on the tool's output rather than parameter semantics, which is appropriate given no inputs exist.

  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 what the tool does: it reports Strava's request usage from the most recent API call. The verb 'reported' and resource 'request usage' are specific, and it is distinct from sibling tools that fetch athlete data, activities, etc. The title reinforces the purpose.

  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 explicitly advises checking this tool 'before issuing many requests,' providing clear usage context. It does not mention alternatives or exclusions, but there are no competing rate-limit tools among the siblings, so this is adequate.

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

• strava_auth_statusA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by enumerating the exact pieces of information returned (connection status, athlete, scopes, expiry) and its diagnostic purpose, going beyond the annotations without contradicting them.

  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 sentences, perfectly front-loaded. The first lists what the tool reports, the second gives the use case. Every word 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?

  For a simple read-only status tool with no parameters and no output schema, this description fully covers the tool's purpose, returned data, and when to use it. Nothing is missing.

  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, so schema coverage is trivially 100%. The description correctly omits parameter details, and no additional semantic explanation is needed. Baseline for 0 params is 4.

  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 what the tool does: it reports connection status, athlete identity, OAuth scopes, and token expiry. This is specific and distinguishes it from sibling tools, which are all about retrieving athlete/activity data, not auth status.

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

  Usage Guidelines4/5

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

  It explicitly says 'Use this to diagnose authorization errors,' providing a clear when-to-use scenario. It doesn't mention alternatives or exclusions, but given the unique purpose among siblings, this is sufficient.

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

• strava_get_activityA
  4.5/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral detail: segment efforts and full map polyline are omitted unless requested, and the parameter descriptions note large payloads. No contradiction.

  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 tool's purpose, 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?

  For a simple get-by-id tool with 3 parameters and no output schema, the description covers the key response content (splits, laps, etc.), the default exclusions, and how to request omitted data. It is complete enough for an AI to select and invoke 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?

  All three parameters have schema descriptions (100% coverage), so baseline is 3. The main description reiterates the omission behavior but does not add significant new parameter semantics 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 retrieves full detail for a single activity, listing specific data (splits, laps, gear, calories, power, HR averages). It distinguishes from sibling tools by noting that segment efforts and the full map polyline are omitted unless requested, making its scope explicit.

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

  Usage Guidelines4/5

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

  The description provides clear context about what is included and what is omitted by default, implying when to use this tool. It does not explicitly name alternatives like strava_get_activity_laps or strava_get_activity_streams, but the context is strong enough to guide selection.

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

• strava_get_athlete_summaryA
  4.5/5.0
  Behavior5/5

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

  The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these annotations by specifying the exact data returned (profile, gear, totals in km and hours, recent activities) and the units, helping the agent understand the tool's scope without relying solely on the schema.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence with the key phrase 'One-shot overview' front-loaded. It efficiently lists the data categories and units without any wasted words, earning a 5.

  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 (one optional parameter, no output schema), the description is remarkably complete. It specifies what data is included, the units, and the intended starting-point role. No significant behavioral or usage 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?

  The input schema has one parameter (recent_activity_count) with full schema description coverage (100%). The tool description does not add additional parameter semantics beyond what the schema already provides. Per the baseline for high schema coverage, the score is 3.

  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 specific phrase 'One-shot overview of the authenticated athlete' and enumerates the exact contents (profile, gear, totals in km/hours, recent activities), clearly distinguishing it from sibling tools like strava_get_athlete (profile only) and strava_get_athlete_stats (stats only). The verb 'overview' and resource 'athlete' are explicit.

  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 states 'Best starting point for questions about overall training,' which clearly indicates when to use this tool. However, it does not explicitly mention when not to use it or name alternatives, though the sibling tool list provides implied contrast. This is clear context without explicit exclusions.

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

• strava_get_athlete_zonesA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds context by noting the 'configured' nature of the zones and the specific auth scope required, which is not covered by annotations. This provides meaningful behavioral detail for a read operation.

  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 entire description is a single, well-structured sentence that includes the resource, the endpoint, and the auth requirement. No redundant information is present; every phrase 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?

  Given the simple, parameterless nature of this read tool, the description sufficiently conveys what it returns (heart-rate and power zones) and its prerequisites. No output schema exists, but the description's mention of the content is adequate for the agent to understand the result. It could mention the response format, but that is not essential for such a straightforward getter.

  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 with 100% coverage. The description correctly omits parameter details, and with no params to explain, the baseline score of 4 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 identifies the tool's function: retrieving the athlete's configured heart-rate and power zones. It names the specific resource (athlete zones) and distinguishes it from the sibling tool 'strava_get_activity_zones' by specifying 'athlete's' zones. The inclusion of the API endpoint adds precision.

  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 states a clear prerequisite: 'Requires the profile:read_all scope,' which informs the agent when the tool can be invoked. However, it does not explicitly contrast with sibling tools like strava_get_activity_zones or provide alternative use cases, so it lacks a when-not-to-use statement. This is useful, but not fully explicit.

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