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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful behavioral detail by listing what is included and noting that map polylines are removed, which is a meaningful data omission. It does not discuss auth or rate limits, but that is a lower burden given 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?

Two sentences, front-loaded with the main purpose and then a compact field list. The removal note is useful and every clause earns its place.

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?

Because an output schema exists and annotations cover safety, the description need not explain return values in full. It provides enough scope and field coverage for an agent to understand the tool, though it omits prose guidance on include_efforts and sibling routing.

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 50%: include_efforts is richly documented in the schema, while activity_id has no description but is obvious from 'one activity'. The main description itself does not mention include_efforts or add parameter-level meaning, so it neither compensates for the gap nor harms understanding.

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 clear verb+resource: 'Full detail for one activity', and it enumerates concrete returned fields such as calories, gear, laps, splits, heart rate, and power. It distinguishes itself from list-style tools by emphasizing a single activity, though it does not explicitly differentiate from specialized siblings like get_activity_laps or get_activity_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 'Full detail for one activity' implies when to use it, but there is no explicit guidance on when to choose it over siblings such as get_activity_laps, get_activity_zones, or get_activity_streams. The usage context is 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.

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

Annotations already establish that this is a read-only, open-world retrieval operation. The description adds useful content about what each lap includes, but does not disclose pagination, ordering, rate limits, or other behavioral traits beyond the output schema.

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 short sentences with no filler. The resource and returned metrics are front-loaded, followed by a concise usage context.

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 one-parameter read tool with an output schema, the description covers purpose, returned per-lap data, and typical use. The main gap is the undocumented required parameter, but the overall definition is nearly 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?

Schema description coverage is 0%, so the description should explain the required activity_id parameter. Instead it only says 'one activity' without clarifying that a numeric activity ID is required or what it identifies.

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 as laps of a single activity and lists the per-lap metrics returned, distinguishing it from activity summary or stream tools. It does not explicitly name sibling tools, but the resource 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?

It gives a clear use case: interval sessions and races split by lap. It does not state when not to use it or name alternatives such as get_activity_streams, so it falls short of full 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious behavior: streams are evenly downsampled so they align point-for-point, and each stream reports its original_size, which tells the agent to expect truncated data and how to detect it. It omits nothing critical, though rate/limits and default key set are left to 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.

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

Three tight sentences: what the data is, what to use it for, and the original_size caveat, all front-loaded with no filler. Slightly could be trimmed since the stream list overlaps the schema.

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 an output schema present, return values need not be explained, and the description covers the sampling contract and the original_size field that an agent needs to interpret truncated results. The only gap is the absence of routing guidance relative to nearby activity 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?

Schema coverage is 67% and the keys parameter already enumerates all valid streams, so the description's mention of HR/power/cadence/etc. largely restates the schema. It does add meaning for max_points by framing the downsampling contract ('point for point'), but activity_id remains undocumented in both places. Baseline 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 states a specific resource and content: second-by-second streams (HR, power, cadence, altitude, speed, position) for one activity, plus the downsampling guarantee. That is far more informative than the bare name and implicitly separates it from summary tools like get_activity and get_activity_laps. It stops short of naming a sibling or stating the boundary explicitly.

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?

'Use it for pacing, heart-rate drift, or interval analysis' gives concrete analytical contexts, so usage is more than implied. However, there is no guidance on when NOT to use it or which sibling to prefer (e.g., get_activity_laps for lap-level splits, get_activity for summary metrics), leaving tool selection to inference.

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 and openWorldHint, so safety is covered. The description adds genuinely useful non-schema context — that Strava may gate this data behind a subscription — but says nothing about what is returned or how a gated/failed request surfaces to the caller.

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 short sentences, both front-loaded and free of padding: the first defines the payload, the second flags the access caveat. Nothing to trim.

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?

An output schema exists, so return structure need not be explained, and annotations carry read-only semantics. Still missing is how to obtain a valid activity_id and what happens on subscription-gated access, which matters for a per-entity lookup on a third-party API.

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 0% and the description adds no explanation of activity_id, so the agent relies entirely on the self-explanatory parameter name being a Strava activity identifier. With a single obvious integer key, that is adequate but no more.

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 a specific resource and scope: per-activity time-in-zone for heart rate and power. The phrase 'during one activity' implicitly separates it from the sibling get_athlete_zones, which covers athlete-level zone configuration, though that sibling is never named.

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?

Usage is implied by the data type returned, but there is no explicit 'use when' framing and no mention of the alternative get_athlete_zones or get_activity_streams for raw zone data. The agent must infer the choice from the tool name alone.

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 and openWorldHint=true, so the safety profile is covered. The description adds only the 'connected athlete' framing, implying an authenticated single-user context, but says nothing about error behavior when no athlete is connected or about response shape/pagination.

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 preamble or filler. The field enumeration is the only content and it is delivered immediately.

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 with an output schema present, the description does what is needed: it identifies the resource and gives a preview of the payload. The remaining gap is that it never clarifies the boundary against the overlapping gear/club/stats siblings.

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 takes zero parameters, so the baseline is 4. There is nothing for the description to clarify about inputs, and it correctly spends no words on them.

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 a specific resource (the connected athlete's profile) and enumerates its contents — name, location, sex, weight, FTP, measurement preference, bikes, shoes, clubs. That is clear and concrete, but it does not differentiate itself from siblings like get_athlete_stats, get_athlete_zones, get_gear or list_clubs, whose data appears to overlap with the bikes/shoes/clubs mentioned here.

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?

There is no when-to-use or when-not-to-use guidance. With three get_athlete* siblings plus get_gear and list_clubs in the set, an agent gets no signal about why it should pick this tool for gear or club information rather than the dedicated 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context: the exact time windows, metric set, and the important caveat that Strava only counts activities visible to Everyone.

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 front-loaded with the result set and follows with the visibility caveat. It is slightly dense but every clause adds useful information about what is returned.

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 parameters and an output schema present, the description does not need to explain return structure. It still supplies the key semantic caveat about activity visibility, making it complete for correct invocation and interpretation.

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 takes zero parameters, so there is no parameter semantics to explain. Baseline is 4 for a parameterless tool, and the description correctly does not invent parameter details.

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 resource (connected athlete statistics) and enumerates the returned activity types, time windows, and metrics. It is clearly distinguishable from siblings like get_athlete, list_activities, and get_activity.

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?

Usage is implied by the resource and metrics, but the description does not explicitly say when to use this instead of get_athlete or list_activities. No alternatives or exclusions are named.

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 and openWorldHint=true, so the safety profile is covered. The description adds useful data-unit context (bpm, watts) but does not disclose authentication needs, rate limits, or other behavioral traits 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?

A single concise sentence with no wasted words, front-loading the resource being returned. It is appropriately sized for a zero-parameter retrieval 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?

With an output schema present and no parameters, the description need not explain return values in detail. It states what the tool returns and for whom, though it could say a bit more about when to choose it over sibling zone 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?

The tool has zero parameters, so there are no parameter semantics to explain; baseline 4 applies. The description correctly adds nothing unnecessary about 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 names a specific resource — the connected athlete's heart-rate and power zones — with units, and implicitly distinguishes it from sibling get_activity_zones by scoping to the athlete rather than an activity. It lacks an explicit verb, but the resource 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?

There is no guidance on when to use this tool versus alternatives such as get_activity_zones or get_athlete_stats. The connected-athlete scoping hints at usage, but no explicit context or exclusions are 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the returned field set, but with an output schema present that is redundant, and it says nothing about behavior for invalid or missing gear ids. With annotations carrying the load, a 3 is appropriate.

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

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

Two short sentences with no filler, leading with the return contents and following with id provenance. The fragment-style opening ('One bike or pair of shoes:') is slightly clipped but not wasteful.

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 one-parameter read tool with an output schema and read-only annotations, the description covers what it returns and where the id comes from. Only error behavior for bad ids is missing, which is a minor gap at this complexity.

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%, so the baseline is 3, but the description adds semantics beyond the schema by decoding the id prefix convention: 'b... for bikes, g... for shoes'. That mapping is only hinted at by the schema's examples, so it is genuine added meaning for the single parameter.

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 the exact resource (a single bike or pair of shoes) and enumerates the returned attributes (brand, model, nickname, total distance in meters), so an agent can tell this is a single-gear lookup rather than a list. It lacks an explicit verb ('get'/'retrieve'), but the resource and scope are 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?

It tells the agent where the required input comes from — 'gear_id on activities and in get_athlete' — which is direct prerequisite guidance and implicitly routes to the sibling tools that produce the id. It doesn't state when NOT to use it or contrast with other retrieval tools, keeping it below a 5.

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 and openWorldHint=true, so the read-only, external-data nature is covered. The description adds that athlete PR data is pulled in (an implicit auth/athlete-context dependency), which is useful, but it says nothing about rate limits, missing segments, or errors.

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 that moves from purpose to payload contents with no filler. The long comma-separated field list is dense but each item earns its place.

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 an output schema present, the description need not detail return values, and it still summarizes them. For a one-parameter read tool this is close to sufficient; only behavior on unknown segments is unaddressed.

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 0% and the single parameter segment_id has no description, but its name and integer type make its meaning self-evident and the description does not need to compensate much. No format, range, or lookup hints are provided.

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 a specific verb (get detail) and resource (one segment), then enumerates the fields returned, so an agent knows exactly what it retrieves. It does not explicitly differentiate itself from siblings such as list_segment_efforts, and the meaning of 'PR (athlete_segment_stats)' is unclear without domain knowledge.

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 singular 'one segment' implies use when a specific segment_id is known, versus list_segment_efforts for effort listings, but no alternative is named and no prerequisites are given. Usage is inferable rather than stated.

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 and openWorldHint, so safety is covered; the description goes well beyond that with non-obvious behavior. It discloses the ordering quirk ('newest first, but oldest first when `after` is set') and the pagination signal (`more_available` is true when the page came back full), both of which an agent would otherwise misread. Those are exactly the kind of behavioral traits annotations cannot express.

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 short sentences, zero filler. Scope and field list come first, then the two behavioral quirks, then the alternative-tool routing at the end. Every sentence carries information an agent needs.

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 paged listing with an output schema present, the description need not explain return structure, yet it still summarizes the field set helpfully. Combined with ordering, pagination, and alternative-tool guidance, nothing an agent needs to call this correctly is 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 coverage is 100%, so both the pagination params and the ISO date bounds are already documented, giving a baseline of 3. The description adds real meaning on top by tying `after` to a change in result ordering and by explaining how the page-full signal interacts with paging. It doesn't add format details for `before`/`per_page` beyond the schema, so it lands at 4.

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 opens with a specific verb and resource ('The connected athlete's activities as compact summaries') and then enumerates the actual fields returned (sport, distance, moving time, heart rate, power, etc.). It clearly separates itself from get_activity, which returns full detail for a single activity, so an agent can pick the right tool without opening either schema.

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?

It explicitly names the sibling alternative and the condition that selects it: 'Use get_activity for one activity's full detail.' It also tells the agent how to continue paginating ('more_available is true when the page came back full, so ask for the next page'). It stops short of full when/when-not coverage (e.g., no guidance on list_starred_segments or segment efforts), so a 4 rather than a 5.

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 and openWorldHint=true, so the safety profile is covered. The description adds the returned fields (sport type, location, member count), but does not explain pagination behavior or any authorization requirements beyond what the schema and annotations provide.

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 efficiently conveys the core resource and its returned fields.

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?

An output schema exists, parameters are fully documented, and annotations cover safety characteristics. For a simple read-only list operation, the description is nearly complete; only minor operational context like pagination behavior is absent but already covered by the schema.

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 both pagination parameters are fully documented in the schema. The description adds no parameter-level semantics, which is acceptable given the schema baseline.

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 the connected athlete belongs to) and the data returned (sport type, location, member count). It does not explicitly use a verb like 'list', but the meaning is unambiguous and it is distinguishable from the athlete/activity/segment siblings.

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?

There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The usage context is only implied by the resource phrase 'clubs the connected athlete belongs to'.

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 and openWorldHint=true, so the agent knows this is a safe external read. The description adds the returned fields (distance, elevation gain, type, estimated time), but says nothing about pagination behavior, ordering, or empty results — pagination is only discoverable from the schema defaults.

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 compact sentence that front-loads the scope ('routes the connected athlete created') before enumerating returned attributes. No filler, nothing that could be trimmed without losing 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?

An output schema exists, so the description need not explain return values, and parameters are fully covered by the schema. What remains missing is sibling differentiation and any note about pagination limits or ordering — minor but not zero gaps for a list tool in a crowded namespace.

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% and both parameters (page, per_page) are fully documented in the schema, so the baseline 3 applies. The description adds nothing about pagination semantics or the 200-item cap, but it doesn't need to since the schema carries that 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 names the resource (routes) and scopes it to the connected athlete, plus lists the returned attributes, so the agent knows what it retrieves. It never explicitly states the verb 'list' and does not differentiate this from siblings like list_starred_segments or list_activities, which also enumerate route-adjacent 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 phrase 'the connected athlete created' implies a scope — the athlete's own routes, as opposed to starred segments or club data — which gives implicit guidance on when to pick this tool. There is no explicit when-to-use, no exclusions, and no reference to an alternative tool for related route 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?

The annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds the non-obvious access caveat that 'Strava may require a subscription for this data', which is real behavioral context that an agent needs in order to interpret empty or error responses. It does not cover pagination behavior, though per_page is at least schema-documented.

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, front-loaded with the scope and the returned fields, then the access caveat. The 'track progress on a climb or sprint' clause is mildly motivational but does convey intent, so there is no glaring waste.

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?

Because an output schema exists, the description does not need to enumerate return values, and its mention of elapsed time, heart rate and power is a helpful preview rather than filler. Combined with the subscription caveat and the athlete-scoped framing, an agent has enough to call the tool correctly, though guidance on handling empty results or pagination is 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 coverage is 75%: the schema documents per_page, start_date_local and end_date_local, but not segment_id. The description only indirectly implies the required segment_id ('on one segment') and adds no format or filtering detail beyond what the schema provides. 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 states a specific resource (a single segment's efforts) with an explicit scope: it returns only the connected athlete's efforts, plus the data fields (elapsed time, heart rate, power, source activity). This distinguishes it from get_segment, which returns segment metadata rather than efforts. The verb is only implicit in the name, and no sibling is named, which keeps it just below a 5.

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?

'so you can track progress on a climb or sprint' implies the intent (performance tracking over repeated efforts) but never says when to call this tool versus alternatives such as get_segment or list_activities. There are no explicit exclusions, such as guidance on retrieving another athlete's efforts or on what to do when the subscription requirement blocks the response.

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 and openWorldHint=true, so the safety profile is covered. The description adds the returned field set, but since an output schema exists that information is largely redundant, and nothing is said about pagination limits or auth scoping beyond 'connected athlete'.

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 tight sentence with the resource and its return fields front-loaded and zero filler. Nothing could be removed without losing 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?

For a simple paginated read with full annotation and output-schema coverage, the description supplies what an agent needs: what is listed and what comes back. Only minor gaps remain around paging behavior and differentiation from sibling segment 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?

Schema description coverage is 100% with only two params (page, per_page), both documented in the schema including the 200-item cap. The description adds no parameter detail at all, so the baseline 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?

States a specific resource ('segments the connected athlete has starred') plus the key fields returned (distance, grade, elevation, location, PR), which reads clearly as a list operation. It does not explicitly name how it differs from siblings like get_segment or list_segment_efforts, so it falls just short of top marks.

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?

Usage is implied only: the description scopes results to 'starred' segments for 'the connected athlete', which hints at when the tool applies. There is no explicit when-to-use/when-not guidance and no mention of alternatives such as get_segment for a single segment or list_segment_efforts for efforts.

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