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

Annotations declare readOnlyHint=true, so the agent understands this is a safe read operation, lowering the burden on the description. The description adds minimal context that the tool targets a single activity and returns 'detailed' data, but does not disclose specifics like whether segment efforts are included by default or how the response is structured. 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?

The description is a single, front-loaded sentence with no filler. It states the action and scope efficiently, earning every word.

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?

With no output schema and many sibling tools, the description is too sparse to fully orient an agent: it does not define what 'detailed data' includes, how it differs from strava_activity_summary, or the effect of includeAllEfforts. The required parameter and read-only nature are covered elsewhere, but the return value and selection context are missing.

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 description coverage is 100%, with both 'id' and 'includeAllEfforts' already described meaningfully. The description adds no parameter-specific information beyond the schema, so the baseline score of 3 is appropriate.

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 uses a specific verb ('Fetch') and resource ('detailed data for one Strava activity'), clearly indicating this returns information about a single activity. However, it does not explicitly contrast with sibling tools like strava_activity_summary or strava_activity_streams, so differentiation relies on the word 'detailed'.

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 choose this tool over its sibling tools. There is no mention of alternatives or conditions, such as using summary for lightweight data or streams for time-series data. The usage context is only implied by the tool name and generic 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?

The readOnlyHint annotation already signals this is a read-only operation, and the description aligns with that by saying 'fetch'. No extra behavioral details like return format or errors are provided, but the basic side-effect profile is transparent and consistent.

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 a single, straightforward sentence with no unnecessary words or repetition. It is as concise as possible while remaining informative.

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 provides enough context for an agent to understand the tool's basic function without ambiguity. It does not specify output details or typical use cases, but for a simple read-only fetch operation, the existing context is adequate.

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?

The single required parameter 'id' is described as 'Strava activity id', which fully clarifies its meaning. The schema description covers the parameter completely, and the tool description does not need to add further explanation.

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 fetches laps for one Strava activity, using a specific verb and resource. It distinguishes itself from sibling tools like activity_detail and activity_streams by focusing on laps specifically.

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 implies when to use it: when laps data for a single activity is needed. It does not explicitly name alternatives or conditions, but the purpose is clear enough that an agent would select this tool over others for lap-specific queries.

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 readOnlyHint annotation already indicates a safe read operation. The description adds no further behavioral details (e.g., pagination, rate limits, caching behavior). Given the annotation, the description meets a baseline but does not exceed it.

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 a single, concise sentence that packs all essential filter dimensions without fluff. It is well-structured and immediately understandable.

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?

There is no output schema, and the description does not specify what the search returns. While the name 'activity_search' implies activity objects, the absence of any return format description leaves some ambiguity.

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 coverage is 100% with descriptions for each parameter. The tool description does not add additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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 verb 'search' and the resource 'activity history', and specifies the filter dimensions (name, sport type, gear, distance, elevation). It does not explicitly contrast with sibling tools like strava_recent_activities, but the purpose is unambiguous.

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 gives no guidance on when to use this tool versus alternatives. It does not mention that it is appropriate for filtered/bounded searches or that strava_recent_activities might be simpler for unfiltered lists.

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 read-only safety profile is covered. The description adds a little context by scoping what stream types are available, but it does not disclose response shape, payload size implications, or the raw-vs-sampled behavior beyond what the input schema already says.

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?

A single, front-loaded sentence with no filler. It names the action, the resource, and the key data types efficiently.

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?

For a tool with five parameters and no output schema, the one-liner is minimally sufficient but incomplete: it does not describe the response structure or how raw streams and sampled streams differ in practice. The schema covers parameter meanings, but return semantics are left implicit.

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 description coverage is 100%, so the schema already documents all parameters. The description mostly repeats the default stream key list already present in the `keys` parameter description and adds no additional semantics for `maxPoints`, `keyByType`, or `includeRaw`.

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 an imperative verb ('Fetch') with a specific resource ('activity stream samples') and enumerates the stream types: time, distance, altitude, heartrate, cadence, watts, and lat/lng. This makes it clearly distinct from sibling tools like strava_activity_detail or strava_activity_laps even without naming them.

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 does not explicitly state when to use this tool versus alternatives or provide exclusions. It implies usage when stream-level sample data is needed, but the agent is left to infer the decision from the resource name rather than receiving explicit routing 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?

The annotation readOnlyHint=true already covers the read-only nature. The description adds no further behavioral context such as pagination limits, caching behavior, or rate-limit implications. It does not contradict the annotation, but also does not go beyond the annotation to enrich transparency.

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 a single, focused sentence that conveys the core functionality without any redundant words or tangential information. It is well-structured and directly to the point.

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 has 8 parameters and no output schema, the description does not explain what the summary output contains (e.g., specific metrics like distance, time, count). The purpose is clear, but without an output schema or further detail, an agent may not fully understand the return structure. This is a moderate gap in completeness.

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?

Every parameter has a description that adds meaning beyond the schema types and enums. For example, 'after' explains it is required to avoid accidentally fetching full history, 'maxPages' clarifies the default and purpose, and 'sportTypes' lists example values. This high coverage and semantic detail make parameter usage clear.

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 summarizes activities by day, week (Monday-start), or month within a bounded date range. This specifies a verb (summarize), a resource (activities), and distinct grouping options, distinguishing it from sibling tools like recent activities or search.

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 does not provide explicit guidance on when to use this tool versus alternatives such as strava_recent_activities or strava_activity_search. While the aggregation focus is implied, there is no direct contrast or recommendation, leaving the agent to infer the appropriate use case.

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 annotation readOnlyHint: true is present and covers the read-only behavior. However, the description does not disclose any additional behavioral aspects such as rate limiting, pagination, error handling, or output format. Since the annotation already provides the minimal behavioral note, the description adds no extra transparency.

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 a single, clear sentence with no unnecessary words or complexity. It is well-structured and concise.

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 nature of the tool (one required parameter, no output schema), the description is largely complete. However, it does not specify whether the zones refer to heart rate, power, or other types, which could be contextually ambiguous for some users. Still, it is sufficient for most use cases.

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?

The schema description covers 100% of the parameters (the 'id' parameter has a description). The tool description does not add additional semantic meaning beyond the schema, so the baseline score of 3 applies.

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 uses the specific verb 'Fetch' and identifies the resource as 'zone distribution for one Strava activity', which is clear. It also distinguishes itself from other activity tools by focusing specifically on zones, though it doesn't explicitly mention the type of zones.

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 is provided on when to use this tool versus alternatives like activity_detail or activity_laps. There is no mention of prerequisites, context, or conditions under which this tool is preferred.

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 readOnlyHint annotation already indicates no side effects, and the description's 'Fetch' aligns with that. However, no additional context such as authentication requirements or rate limits is provided, so the description adds minimal value beyond the annotation.

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

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

The description is a single, concise sentence with the action and object clearly front-loaded. No unnecessary words or filler.

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?

For a simple read-only fetch with no parameters and no output schema, the description is fully complete. It leaves no ambiguity about what the tool does.

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?

The schema has zero parameters, so coverage is 100% vacuously. The baseline of 3 applies because there is no parameter information to supplement, and no need for further explanation.

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 verb 'Fetch' and the specific resource 'authenticated Strava athlete profile', which is distinct from sibling tools like zones, stats, or activities. The scope is unambiguous.

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 is given on when to use this tool versus the sibling tools. Although the resource is specific, there is no explicit mention of suitability or alternatives, leaving the agent to infer context.

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 readOnlyHint annotation already communicates the read-only nature, and the description's use of 'Fetch' is consistent. The phrase 'aggregate stats' adds a small amount of context about the returned data being summarized, but it does not disclose what specific stats are included or any behavior beyond the annotation.

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

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

The description is one concise sentence that immediately states the resource and scope. There is no fluff, and every word earns its place for a tool with a single parameter.

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 schema and readOnlyHint, the description is minimally sufficient, but it leaves a gap: 'aggregate stats' is vague and could overlap with sibling tools like strava_athlete_zones. Without an output schema, more detail on what stats are returned would improve completeness.

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 description coverage is 100%, so the parameter is fully documented in the schema. The description merely restates 'Strava athlete id' without adding any new meaning, format guidance, or usage nuance.

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 action ('Fetch') and resource ('aggregate stats for a Strava athlete id'). It distinguishes the tool from siblings like athlete_profile and athlete_zones by focusing on aggregate statistics, though it does not explicitly name alternatives.

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 is provided on when to use this tool versus the many sibling tools, such as strava_athlete_zones or strava_activity_summary. The description gives no context for selection or exclusion criteria.

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 readOnlyHint annotation already communicates that this is a safe read operation, and the description's 'Fetch' aligns with that. The description adds the scope of 'authenticated athlete' but does not disclose additional behavioral details like response format or that no parameters are needed.

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 a single, focused sentence that immediately states the verb and resource. There is no filler, redundancy, or unnecessary detail.

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?

For a no-parameter read-only tool, the description fully covers what the agent needs to know to select and invoke it: it fetches heart-rate and power zones for the authenticated athlete. The sibling list provides enough contrast, and the annotation covers the safety profile.

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?

The tool has zero parameters, so there is nothing for the description to explain about inputs. The schema coverage is effectively 100%, and the description still adds meaning by specifying exactly what data is returned.

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 uses a specific verb ('Fetch') and names the exact resource ('the authenticated athlete's heart-rate and power zones'). This clearly distinguishes it from sibling tools like strava_activity_zones, which target activity-specific zones.

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 phrase 'authenticated athlete's' implies this is for the user's own zones rather than activity-level zones, so usage context is somewhat clear. However, it does not explicitly state when to choose this over strava_activity_zones or other athlete-related siblings.

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 readOnlyHint annotation already signals a safe read operation, and the description's 'Show' aligns with that. The description adds useful context that this checks the local cache rather than making a remote API call, but it does not disclose exactly what the returned coverage/metadata contains or whether any refresh behavior occurs.

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?

A single, focused sentence that immediately states what the tool does with no wasted words. The key concept, local cache status, is front-loaded.

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?

For a zero-parameter read-only tool, this description is largely sufficient: an agent knows what it shows and can safely call it. The main gap is that 'coverage and metadata' is somewhat vague, and since there is no output schema, a little more detail about the returned cache information would make it 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?

The tool has zero parameters, so the input schema is trivially complete. With no parameters to document, the baseline of 4 applies.

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 uses a specific verb ('Show') and a specific resource ('local Strava activity cache coverage and metadata'). It clearly identifies this as the cache-status tool among the sibling tools, which are mostly remote-data or sync operations.

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 implies the tool is for inspecting local cache state, so an agent can infer when it is relevant. However, it does not explicitly state when to use it over alternatives such as strava_rate_limit_status or strava_sync_activities, nor does it mention any exclusions.

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 are all false (not read-only, not idempotent, not destructive). The description mentions writing to local files, which is a side effect, but it does not disclose potential overwriting behavior, permissions, or any failure modes. It adds only file type details 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.

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

The description is a single, focused sentence that front-loads the core action and resource. It avoids redundancy and includes essential details (bounded, local, file types) without extra fluff.

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?

For an export utility, the description gives enough context: it specifies the input scope (bounded history) and output format (local raw JSON, compact JSON, CSV). It does not mention how results are returned (e.g., file path), but that may be outside the tool's responsibility. Overall, it is complete for the stated purpose.

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 coverage is 100%, with each parameter described in the schema (e.g., 'after' as Unix timestamp lower bound). The tool description itself adds no additional parameter semantics beyond what is already in the schema, so the baseline of 3 applies.

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 action ('Export') and the resource ('bounded activity history') with destination file types. It is specific enough to distinguish from sibling tools like strava_recent_activities or strava_activity_search.

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 implies a use case (exporting a bounded history to local files) but does not explicitly say when to choose this tool over alternatives like strava_sync_activities or strava_activity_search. No direct comparison or conditional guidance is provided.

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 readOnlyHint annotation already conveys that this is a safe, non-mutating operation. The description adds no further behavioral context such as rate limits or potential side effects, so it meets the baseline but does not exceed it.

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 a single, concise sentence that directly conveys the tool's purpose without unnecessary words. It is well-structured and front-loaded, making it easy for an agent to parse quickly.

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?

For a simple fetch operation, the description is sufficiently complete, indicating the resource and scope. It does not mention return format, but given the triviality of the operation and the absence of an output schema, this is not a significant gap.

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?

The schema already fully describes the 'id' parameter with type and an example format. The description does not add any additional meaning beyond what is in the schema, so the score remains at the baseline for full schema coverage.

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 action (fetch) and the resource (gear detail) with a specific scope (one gear id). It is unambiguous and immediately distinguishes this tool from others like strava_gear_usage, which focuses on usage statistics.

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 does not provide any guidance on when to use this tool over siblings such as strava_gear_usage or strava_activity_detail. It only states what it does, leaving the agent to infer the appropriate context without explicit direction.

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 provide readOnlyHint=true, and the description adds meaningful behavior beyond that: it discloses that results are aggregated by gear id and include mileage, hours, and elevation. This gives the agent a concrete sense of the output shape without contradicting the read-only annotation.

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 a single, front-loaded sentence with no filler. Every word contributes: it names the action, the grouped metric set, the grouping key, and the intended use case.

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?

For a read-only aggregation tool with rich parameter documentation in the schema, the description communicates the core output concept well. It lacks explicit details about return format boundaries or when to choose alternatives, but the schema and purpose statement largely cover what an agent needs to invoke it correctly.

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 description coverage is 100%, so the baseline is 3. The description does not add parameter-level detail beyond what the schema already states, though it does clarify that gearIds relates to the grouping key and that the metrics are mileage, hours, and elevation. This is sufficient but not exceptional.

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 uses a specific verb ('Group') with a clear resource and scope: activity mileage, hours, and elevation grouped by gear id. It clearly distinguishes this aggregation tool from siblings like strava_gear_detail, which would focus on a single gear's details rather than usage summaries.

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 implied usage context ('service-interval audits') but does not explicitly state when to prefer this tool over alternatives such as strava_activity_search or strava_gear_detail. There are no when-not-to-use instructions or sibling comparisons, leaving some selection reasoning to the agent.

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 description reveals a key behavioral trait: the data comes from the process's last observation, implying no live API call is made. This adds context beyond the readOnlyHint annotation, clarifying the source of the information. However, it does not specify what happens if no observations exist yet.

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 a single, direct sentence with no unnecessary words. It is well-structured, placing the action verb first and followed by the specific resource and source. Ideal for a simple tool.

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 there are no parameters and no output schema, the description is largely complete. It specifies the data source ('last observed by this MCP process') which is valuable context. It could optionally mention the output format, but that is not critical for understanding the tool's function.

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?

There are no parameters, so the schema coverage is 100%. Per the rubric, this yields a baseline score of 3. The description adds nothing about parameters because none exist, which is appropriate.

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's function: showing Strava API rate-limit headers as last observed by this MCP process. It uses a specific verb 'Show' and names the resource, distinguishing it from other tools like strava_cache_status. No ambiguity about what the tool does.

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 does not provide any guidance on when to use this tool versus alternatives. It does not mention that it should be used to check rate limits before making API calls, nor does it contrast with similar diagnostic tools like strava_cache_status. Users must infer its purpose from the name and 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?

Annotations include readOnlyHint=true, so the safety profile is already disclosed. The description adds modest context by specifying the activities belong to the authenticated athlete, but it does not describe response format, ordering, or pagination behavior beyond what the schema already documents.

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 a single, front-loaded sentence with no filler. It states the key action and resource efficiently, and every word contributes to the tool's meaning.

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?

For a simple read-only listing tool with fully documented optional parameters and readOnlyHint annotation, the description is largely complete. It identifies the actor ('authenticated athlete') and scope ('recent activities'). The only notable omission is guidance for choosing this over sibling tools, but that is a usage-guideline concern rather than a core invocation gap.

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 description coverage is 100%, so every parameter (page, after, before, perPage) already has meaningful documentation. The description adds no additional parameter semantics, which is acceptable since the schema carries the full burden.

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 verb 'List' and the resource 'authenticated athlete's recent Strava activities,' making the tool's basic function unambiguous. However, it does not explicitly distinguish itself from sibling tools like strava_activity_search or strava_activity_summary, so differentiation is left to the agent.

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 gives no guidance on when to use this tool versus alternatives such as strava_activity_search or strava_export_activities. There is no mention of prerequisites, filtering intent, or why one would choose 'recent activities' over the search or export tools.

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 are all false, so they already signal that this is not read-only, not idempotent, and not destructive. The description adds that the effect lands in a 'local ignored activity cache,' which is useful side-effect context. However, it does not disclose whether repeated calls overwrite or append, whether Strava rate limits or pagination are consumed, or what happens to existing cached entries.

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?

One concise sentence with no filler; the key action and destination are front-loaded. The short length is a virtue even though additional behavioral context would be welcome.

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?

With no output schema and only sparse annotations, the description carries a heavy burden, but it does not explain return values, cache-update semantics, or how this differs in use from strava_export_activities or strava_cache_status. An agent can call it with correct parameters thanks to the schema, but cannot predict the result or side effects. The missing behavioral and usage context makes this incomplete for a sync tool.

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 description coverage is 100%, so the input schema already fully documents 'after', 'before', and 'maxPages'. The description adds no parameter-specific details beyond the word 'bounded', which weakly aligns with the after/before bounds. A baseline of 3 is appropriate because the schema does the heavy lifting.

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 names a specific verb ('Fetch'), a bounded resource ('Strava activity history'), and a destination ('local ignored activity cache'). This clearly differentiates it from sibling read tools like strava_recent_activities and strava_activity_detail, which fetch data back to the agent rather than writing into a cache. The qualifier 'ignored' is slightly jargon-heavy but does not obscure the core action.

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 gives no explicit when-to-use or when-not-to-use guidance, and it names none of the 15 sibling tools as alternatives. The cache-writing phrasing implies an internal sync operation, but with so many nearby Strava tools an agent must guess whether this is a prerequisite or a user-facing query. There is no stated exclusion or routing rule.

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