HAPI Strava MCP Server

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by specifying the 'top 10' result limit and that it performs a matching/return operation, though it could further clarify the geographic nature of the search.

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

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

Single sentence is brief, but wastes space with the tautological 'Explore segments -' prefix which merely echoes the tool name/title. The dash construction is awkward and the focus on 'query' distracts from the actual geographic parameter requirements.

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

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

Given 4 parameters with 0% schema coverage (including 1 required), no output schema, and domain-specific data (Strava segments), the description is incomplete. It fails to explain the required 'bounds' parameter format or the categorical filtering system, leaving the agent under-equipped to construct valid requests.

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

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

With 0% schema description coverage, the description fails to compensate for the undocumented parameters. It characterizes the operation as a 'specified query' rather than explaining that 'bounds' requires a 4-element coordinate array (likely lat/long bounding box), that max_cat/min_cat represent difficulty categories (0-5), or the activity_type filter values.

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

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

The description states it returns segments, but 'matching a specified query' is vague and misleading given the actual parameters are geographic bounds (lat/long box), numeric categories, and activity type—not a text query. The opening 'Explore segments' restates the tool name without adding specificity.

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

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

Provides no guidance on when to use this versus sibling tools like getLoggedInAthleteStarredSegments (which retrieves starred segments) or getEffortsBySegmentId (which retrieves efforts for a specific segment). No prerequisites or alternatives are mentioned.

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

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

Significantly enriches the readOnlyHint annotation by disclosing three key behaviors: authentication requirements, pagination support, and privacy/visibility constraints ('Athlete profile visibility is respected') that affect returned data.

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

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

Four sentences convey purpose, auth requirements, pagination, and privacy constraints with minimal redundancy. The leading clause 'List Club Activities -' slightly duplicates the title but serves as a functional header.

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

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

Given the lack of output schema, the description adequately covers invocation constraints (auth, pagination) and data behavior (privacy). It provides sufficient context for a data retrieval tool with simple scalar parameters.

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

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

With 0% schema description coverage, the description compensates by semantically mapping parameters: 'specific club' implies the 'id' parameter, and 'Pagination is supported' explicitly indicates the purpose of 'page' and 'per_page' parameters.

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

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

The description provides a specific verb ('Retrieve') and resource ('recent activities from members of a specific club') that clearly distinguishes this from sibling tools like getClubMembersById (which returns members, not activities) and getClubById (which returns club metadata).

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

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

Explicitly states the authorization prerequisite ('authenticated athlete must belong to the requested club'), which is crucial for successful invocation. However, it does not explicitly name alternative tools when club membership is unavailable.

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

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

While consistent with readOnlyHint annotations, the description adds no behavioral context beyond 'returns a list'. It fails to disclose pagination behavior (despite page/per_page parameters), rate limits, or the structure/composition of administrator objects returned.

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

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

The single-sentence structure is appropriately brief, but the dash-separated construction ('List X - Returns a list of X') is redundant with the title, wasting precious description space without adding value.

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

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

Given a 3-parameter tool with pagination support and no output schema, the description is insufficient. It omits pagination semantics, return value structure, and error conditions (e.g., invalid club ID behavior), providing only the minimal tautological restatement of the title.

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

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

With 0% schema coverage, the description fails to compensate adequately. While 'given club' implicitly references the required id parameter, it provides no documentation for the pagination parameters (page, per_page), leaving their semantics, defaults, and constraints completely unspecified.

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

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

The description states the basic purpose (listing club administrators) and distinguishes from siblings like getClubMembersById by specifying 'administrators' vs 'members'. However, it uses tautological structure ('List... Returns a list') that wastes space without adding specificity about what distinguishes an administrator from a member or 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.

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

No guidance provided on when to use this tool versus alternatives like getClubMembersById or getLoggedInAthleteClubs. No mention of prerequisites (e.g., needing a valid club ID) or when admin data is preferable to general member data.

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

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

While annotations correctly indicate this is a read-only operation, the description adds no behavioral context beyond the tautological 'Returns a given club.' It omits error conditions (e.g., club not found), authentication requirements, rate limiting, or what constitutes the returned club resource.

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

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

The description is brief (one sentence) but inefficiently structured with redundancy—the phrase 'Get Club' largely repeats the title, and 'Returns a given club using its identifier' is repetitive with the tool name `getClubById`. It wastes space on tautology rather than adding information density.

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

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

Given the tool's low complexity (single integer parameter, read-only operation) and presence of safety annotations, the description is minimally adequate but incomplete. It fails to address the lack of output schema by describing return structure or explaining the relationship between this endpoint and other club-related sibling tools.

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

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

With 0% schema description coverage, the description bears full responsibility for explaining the `id` parameter. It merely references an 'identifier' without clarifying that this is the numeric club ID, where to obtain it (e.g., from `getLoggedInAthleteClubs`), or its int64 format constraints. Minimal compensation for the schema gap.

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

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

The description clearly states the tool retrieves (returns) a specific resource (a club) using an identifier, satisfying verb+resource clarity. However, it fails to differentiate from siblings like `getClubMembersById` or `getLoggedInAthleteClubs` which operate on similar club-related resources.

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

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

The description provides no guidance on when to use this tool versus alternatives such as `getLoggedInAthleteClubs` (which presumably lists clubs rather than retrieving a specific one) or `getClubMembersById`. There are no prerequisites, exclusions, or contextual triggers mentioned.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. However, the description adds no behavioral context about pagination (how page/per_page interact), rate limiting, or what happens if the club ID doesn't exist. For a list endpoint, omitting pagination behavior is a significant gap.

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

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

Single sentence with minor redundancy (title restatement before the dash). Appropriately brief but front-loading with the title repetition wastes the opening. Structure is simple but functional.

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

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

Given 0% schema coverage, 3 parameters including pagination controls, and no output schema, the description is insufficient. It omits critical details: what 'id' represents (club vs athlete), pagination mechanics, and return structure expectations.

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

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

With 0% schema coverage, the description must compensate but fails to document the pagination parameters (page, per_page) entirely. It only implicitly suggests 'id' refers to a club ID via 'members of a given club', providing minimal semantic value beyond the schema's type information.

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

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

The description specifies the resource (athletes who are club members) and action (returns/list), distinguishing from siblings like getClubAdminsById and getClubActivitiesById by focusing on 'members' specifically. However, it wastes space restating the title ('List Club Members') before the dash.

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

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

No guidance provided on when to use this versus getClubAdminsById or getClubById. No mention of pagination strategy despite the presence of page/per_page parameters, leaving users to infer proper usage patterns.

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

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

Adds critical behavioral context beyond annotations: 'Requires subscription' discloses a business logic gate, and 'authenticated athlete's' clarifies scope limitations. Annotations confirm read-only safety, while description adds authorization constraints.

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

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

Two efficient sentences with minimal waste. Slight redundancy opening with 'List Segment Efforts' when title already states this, but otherwise front-loaded with the essential operation and constraints.

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

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

Adequate for basic invocation but incomplete given complexity: 4 parameters with 0% schema coverage require description-level documentation, especially for date filters and pagination. Subscription warning is complete, but parameter gaps remain.

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

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

With 0% schema description coverage, the description fails to compensate for undocumented parameters. Only implies segment_id through 'given segment'; per_page, start_date_local, and end_date_local receive no semantic explanation despite date-time formats needing clarification.

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

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

Clear verb 'Returns' with specific resource 'segment efforts' and scope 'authenticated athlete's for a given segment'. Distinguishes from exploreSegments (public discovery) by specifying authenticated data, though could better contrast with sibling getSegmentEffortById (singular vs plural).

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

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

States prerequisite 'Requires subscription' but provides no guidance on when to use this versus alternatives like getSegmentEffortById (single effort lookup) or exploreSegments (discovery). No mention of pagination behavior or date filtering best practices.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds no behavioral context beyond this, failing to mention what data the equipment object contains, caching behavior, or rate limits.

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

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

The description is brief (one sentence), but wastes space by repeating the title verbatim before the dash. The structure is 'Title - description' which is redundant rather than efficiently conveying new information.

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

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

Given the single parameter and read-only annotations, the description is almost sufficient, but lacks domain context. With similar 'getById' siblings, it should clarify that 'gear' refers to athlete equipment (bikes/shoes) to avoid confusion with other entity types.

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

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

With 0% schema coverage (the 'id' parameter is undocumented), the description only vaguely references 'its identifier' without explaining the ID format, how to obtain it, or what entity it identifies (gear vs athlete).

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

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

The description restates the tool title ('Get Equipment') and name ('using its identifier' echoes 'ById'), making it tautological. While it identifies the resource (equipment) and action, it fails to distinguish from siblings like getClubById or getRoutesByAthleteId.

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

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

Provides no guidance on when to use this tool versus alternatives, nor any prerequisites for the identifier parameter. The agent cannot determine if this is preferred over filtering club gear or how it relates to athlete equipment.

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

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

Annotations confirm read-only safety, while the description adds valuable behavioral context: the variance between detailed and summary representations based on token scope. This permission-dependent behavior is not indicated in structured annotations.

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

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

Two efficient sentences. The first bridges title and action; the second delivers essential scope information. Minor redundancy with the title in the first clause prevents a 5.

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

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

Appropriate for a simple read operation. Annotations cover the safety profile; the description covers scope-based response variance. No output schema exists, but the description explains the representation difference (detailed vs summary).

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

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

Baseline 4 for zero-parameter tools. The schema is empty (100% coverage vacuously), and the description correctly implies no inputs are required beyond the authentication context.

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

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

The description states a specific verb ('Returns') and resource ('currently authenticated athlete'), clearly distinguishing it from siblings like 'getLoggedInAthleteClubs' or 'getRoutesByAthleteId' which access different related resources.

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

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

Provides clear context about scope requirements ('profile:read_all' for detailed vs summary representation), which is critical usage information. Lacks explicit 'when not to use' or alternative naming, but the scope guidance is substantial.

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

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

Annotations already declare readOnlyHint=true, so the description's 'Returns a list...' text is consistent. The description adds valuable context that this specifically returns clubs 'whose membership includes the authenticated athlete,' clarifying the membership relationship. However, it lacks details on pagination behavior, empty result handling, or rate limits.

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

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

The description is somewhat redundant with the title ('List Athlete Clubs - Returns...'), creating slight inefficiency. However, it is appropriately brief and the second clause clarifies the specific membership scope. Each sentence contributes meaning, though the first half largely restates the title.

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

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

Given the simple list operation and presence of readOnly annotations, the description adequately covers the core return value. However, with no output schema and undocumented pagination parameters, the description should have addressed pagination behavior or parameter semantics to be complete.

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

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

With 0% schema description coverage, the description carries full burden for parameter documentation but mentions neither 'page' nor 'per_page'. While these are standard pagination parameters, the description provides zero guidance on their usage, defaults, or constraints.

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

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

The description clearly identifies the resource (clubs) and specific scope (authenticated athlete's membership), distinguishing it from sibling tools like getClubById which require a specific club ID. However, it doesn't explicitly differentiate from getLoggedInAthlete (which gets athlete profile) or when to prefer this over other club endpoints.

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

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

No guidance provided on when to use this tool versus alternatives like getClubById (which requires an ID) or how it relates to the athlete's profile. The pagination parameters (page/per_page) are present in schema but entirely undocumented in description.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral context about privacy filtering (private segments excluded without proper scope). This security/visibility behavior is critical and not captured in structured annotations.

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

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

The description wastes space repeating the title 'List Starred Segments' at the beginning. The remaining content is efficient, but the redundant opening reduces the value density of the limited description space.

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

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

The description covers the core purpose and privacy behavior adequately for a list endpoint. However, given the lack of output schema and zero parameter description coverage, it should include pagination guidance to be fully complete.

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

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

With 0% schema description coverage, the description fails to compensate for the undocumented pagination parameters (page, per_page). No explanation of pagination behavior, integer formats, or defaults is provided, forcing agents to infer from standard conventions.

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

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

The description clearly identifies the action (List) and specific resource (authenticated athlete's starred segments). It distinguishes from siblings like exploreSegments by specifying 'authenticated athlete' and 'starred' (favorited) content, though it could more explicitly contrast with the exploration tool.

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

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

The description provides the important usage constraint regarding the read_all scope required to view private segments. However, it lacks explicit guidance on when to use this versus exploreSegments or other segment-related tools in the sibling list.

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

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

The annotations establish this as a safe read operation (readOnlyHint: true), and the description adds valuable behavioral context not present in structured fields: specifically, the privacy-filtering logic ('Private routes are filtered out unless requested by a token with read_all scope'). This discloses important domain-specific behavior regarding data visibility.

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

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

The description consists of two efficiently structured sentences that front-load the action. The first clause establishes the operation, while the second adds the privacy constraint. No sentences are wasted, though the hyphenated title repetition ('List Athlete Routes -') could be removed to improve density.

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

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

Given this is a simple list operation with good safety annotations, the description adequately covers the privacy/scope domain logic crucial for this API. However, the complete omission of pagination parameter documentation—despite zero schema coverage—creates a significant gap for a tool returning potentially large collections.

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

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

With 0% schema description coverage for the 'page' and 'per_page' parameters, the description fails to compensate by explaining pagination semantics. While the word 'list' implies pagination exists, there is no explanation of parameter purpose, valid ranges, or defaults, leaving the agent to guess how to traverse results.

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

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

The description clearly identifies the resource (routes) and scope (created by the authenticated athlete). It uses specific verbs ('List', 'Returns') and distinguishes this from sibling tools by focusing on athlete-created routes versus segments, clubs, or gear. However, it does not explicitly differentiate from segment exploration tools (exploreSegments) which might seem similar.

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

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

The description provides implicit usage constraints by noting that private routes require a token with 'read_all' scope, which hints at when data will be available. However, it lacks explicit guidance on when to prefer this over exploring public segments or other route-discovery methods, and does not mention pagination requirements.

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

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

Annotations confirm read-only safety; description adds critical context beyond annotations: subscription requirement and ownership scope ('owned by the authenticated athlete'). 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.

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

Two sentences, efficiently structured. Leading fragment 'Get Segment Effort -' restates title and wastes space, but remaining content is dense with constraints (subscription, ownership).

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

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

Adequate for a simple retrieval tool: covers purpose, auth constraints, and subscription requirement. However, lacks parameter documentation critical given 0% schema coverage, and provides no error case guidance.

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

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

Schema has 0% description coverage for the required 'id' parameter. Description implies ID refers to a segment effort via 'Returns a segment effort' but fails to explicitly document the parameter semantics, format, or constraints.

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

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

Clear verb (Returns) and resource (segment effort), with scope constraint (from activity owned by authenticated athlete). Distinguishes singular effort retrieval from plural sibling getEffortsBySegmentId implicitly via 'a segment effort' phrasing, though explicit differentiation is absent.

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

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

States prerequisite (Requires subscription) and ownership constraint, but lacks explicit when-to-use guidance comparing to getEffortsBySegmentId or error handling guidance.

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

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

Annotations declare read-only safety, while the description adds the visibility filtering constraint (Everyone only). This is useful behavioral context not present in structured fields, though it could further clarify what statistical aggregations are returned.

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

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

Two sentences, but the first unnecessarily restates the tool title ('Get Athlete Stats -'). The second sentence about visibility is valuable and efficiently placed, though the title repetition wastes front-loaded space.

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

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

Adequate for a simple single-parameter tool with safety annotations, but the lack of parameter documentation and output description leaves gaps that could confuse users about what ID to provide and what data structure to expect.

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

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

With 0% schema description coverage, the description fails to compensate by explaining what the 'id' parameter represents (presumably athlete ID). No parameter semantics are provided in the description text.

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

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

States specific action (Returns activity stats) and resource (athlete), and the visibility constraint helps scope the data. However, it doesn't clearly distinguish from sibling tools like getLoggedInAthlete or specify the nature of the stats versus raw activities.

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

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

Includes important behavioral constraint that data is limited to 'Everyone visibility' activities, which informs usage. However, lacks explicit guidance on when to use this versus other athlete-related tools like getLoggedInAthlete.

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