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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive, open-world write, so the safety profile is covered externally. The description adds only that the target is the athlete's training calendar; it does not say whether duplicate events are allowed, what permissions are required, or what happens on a date collision.

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 the verb and resource first and the clarifying examples after. Nothing is padded and nothing needs to be re-read.

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 7-parameter mutation with no output schema, the description is thin: it says nothing about the created object's return shape, error behavior, or whether category choices alter required fields. Annotations cover the safety side, but the description leaves a real gap around mutation outcomes.

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 (category enum, ISO date pattern, distance/duration units) is already documented in the schema. The description contributes no additional parameter meaning, which is the expected baseline when 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?

States a specific verb ('Create') and resource ('event on the athlete's training calendar'), with parenthetical examples (planned workout, race, note) that make the intent unambiguous. It implicitly separates itself from read-side siblings like get_event/list_events, though it never names them 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?

There is no when-to-use guidance, no mention of prerequisites, and no routing between this and siblings such as update/delete or bulk list operations. The parenthetical gives event kinds but not the conditions under which an agent should call this tool.

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 behavioral context — that the default result is a compact summary and that `fields` unlocks other metrics — which goes beyond the annotations, though it stops short of explaining the cost/size tradeoff.

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 tightly written sentences, front-loaded with purpose and the return-shape caveat. Minimal waste, though the first clause partly echoes the name/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?

For a simple read tool with full schema coverage and annotations, the essentials are present. The notable gap is routing: with so many get_activity_* siblings, the definition does not equip an agent to confidently select this tool over the specialized ones.

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 activity_id and fields are already fully documented in the schema (including the 30-vs-184 field detail). The description restates the fields behavior at a high level without adding syntax or examples beyond 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?

States a specific verb (get) and resource (activity) plus the lookup key (by its ID) and return scope (detailed information). However, it does not differentiate itself from the many get_activity_* siblings (streams, intervals, power_curve, weather), so an agent cannot tell from the description alone which of these to choose.

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 when-to-use context and never names an alternative, despite numerous sibling tools that fetch activity-related data. Nothing tells the agent when this core-record tool is preferred over get_activity_streams or the other specialized variants.

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 genuinely useful constraint that the stream must exist on the activity and that exactly one of duration/distance is required, but says nothing about the shape or ordering of returned efforts. With annotations carrying the safety burden, 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 sentences, zero filler, with the core purpose and its examples front-loaded and the calling constraint second. 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?

For a read-only computation with no output schema, the description covers what the tool computes and the constraints needed to invoke it. It could optionally sketch the returned entity (e.g. per-effort duration/distance/value) to complete the picture, but nothing essential to a correct call 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%, giving a baseline of 3, and the schema already documents each field richly (units, examples, the 'pace is NOT valid' caveat). The description goes beyond the schema by stating the mutually-exclusive constraint 'exactly one of duration or distance', which the schema's required list does not encode. That is real added semantic value.

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?

Names a specific verb ('Find') and resource ('best efforts within an activity') and grounds it with two concrete examples (peak 5-min power, fastest 1km), so the agent knows exactly what is computed. It does not explicitly distinguish itself from near-siblings such as get_activity_power_curve or get_activity_intervals, which describe overlapping peak-effort concepts.

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 supplies a real precondition ('Requires a stream to measure and exactly one of duration or distance'), which tells the agent how to call it correctly. It gives no guidance on when to prefer this tool over get_activity_power_curve or get_activity_intervals, so usage against alternatives is only implied.

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 safety is covered. The description adds genuinely useful behavioral context beyond that: laps have 84 fields, a compact subset is returned by default, and the response is organized into icu_intervals and icu_groups. It stops short of noting pagination or other limits, but that gap is minor against the annotation coverage.

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

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

Two sentences, zero padding. The purpose is front-loaded in the first sentence and the non-obvious nested-field scoping caveat follows 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?

With no output schema, the description carries the burden of describing returns; it names the top-level result keys (icu_intervals, icu_groups) and the default compact shape, which is enough for an agent to call it correctly. A note on what the default 24 fields actually contain would close the remaining 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 coverage is 100%, so baseline is 3. The description goes further by clarifying the scope of `fields`: it applies to the individual laps nested inside icu_intervals and icu_groups, not to top-level records. That is real meaning the schema's generic 'Fields to return' text does not convey.

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 and resource: 'Get the lap/interval breakdown for an activity.' This is clearly distinct from the plain get_activity sibling, though it never names that sibling or any other alternative explicitly. An agent can infer the distinction from the resource scope.

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 only implied: you call this when you need lap/interval detail rather than an aggregate activity record. No when-to-use condition, no exclusions, and no pointer to get_activity or get_activity_streams for related 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the bar is lower. The description adds the specific meaning of the returned data ('mean maximal power curve'), but says nothing about return format, units, or whether the curve is time-windowed. With no output schema, a bit more behavioral detail would help.

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 is efficiently sized, though notably under-specified rather than deliberately minimal.

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 single-parameter read tool with annotations covering the safety profile, the essentials are present. The main gaps are the lack of distinction from get_power_curves and no indication of what the returned curve contains at a high level, which matters since there is no output 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 coverage is 100% for the single activity_id parameter, so the schema fully documents it. The description adds no syntax, format, or sourcing guidance for the ID, leaving the baseline 3 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?

States a specific verb ('Get') and resource ('mean maximal power curve') scoped to 'a specific activity', which is clearer than a bare title restatement. However, it offers no differentiation from the sibling get_power_curves, so an agent cannot tell from the description alone which of the two power-curve tools to pick.

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 when-to-use context, no prerequisites, and does not name or distinguish itself from the obvious alternative (get_power_curves). Usage must be inferred entirely from the name.

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 cover safety (readOnlyHint, openWorldHint), and the description usefully adds what they cannot: the payload is large, channels are silently downsampled to 500 points by default, and finer resolution is opt-in. It stops short of describing the return shape or ordering.

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, front-loaded with purpose then behavior then guidance, with no filler. Slight redundancy with the schema's own types/max_points descriptions keeps it off 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?

For a read-only, three-parameter tool with no output schema, the description covers size, downsampling semantics, and filtering well enough to call it correctly. The one gap is that the shape of the returned stream data (per-channel series, timestamps vs values) is left entirely unstated.

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 optional parameters already document their defaults, bounds, and the 'omit for all channels (much larger)' behavior. The description largely restates that and adds only rationale (size/resolution tradeoff), which lands at the baseline for fully-covered schemas.

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 precise verb+resource ('Get time-series data streams for an activity') and enumerates the channel types returned, which cleanly separates it from summary tools like get_activity. It never names a sibling, however, so an agent must still infer the boundary against get_activity_intervals or get_activity_power_curve on its own.

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?

Offers real efficiency guidance — pass types to limit channels, and raise max_points 'only when you genuinely need finer resolution' — but this is parameter-level advice, not tool-selection advice. Nothing tells the agent when to prefer this over get_activity_intervals or get_activity_power_curve, which return overlapping time-series 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, conveying the safe-read and external-data profile. The description adds nothing beyond that — no indication of whether weather data may be unavailable, what units/fields the summary contains, or any latency/caching behavior for an external lookup.

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 wasted words. It is efficient, though arguably too terse to be maximally helpful.

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 whose annotations cover the safety profile, the description is minimally adequate. With no output schema, it could reasonably say what the 'weather summary' includes, which is the main remaining 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?

Only one parameter (activity_id) with 100% schema description coverage, so the schema does the work. The description adds no meaning beyond the schema, which is the baseline expectation at this coverage level.

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') and resource ('weather summary for an activity'), so an agent knows exactly what this returns. It is naturally distinct from siblings like get_activity_streams or get_activity_power_curve, though it does not explicitly differentiate itself.

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 the many other get_activity_* siblings, nor any prerequisite or exclusion noted. Usage is only implied by 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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses concrete behavioral traits: the default is a compact 21-field-ish subset, the sportSettings payload is ~10 KB, credentials are always withheld, and email/DOB are gated behind explicit request. These are exactly the privacy and payload-size facts an agent needs and cannot get from 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?

Three tight sentences, front-loaded with what the tool returns, followed by the default/payload-size behavior and then the privacy caveats. No filler and no restatement of 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?

There is no output schema, so the description carries the full burden of describing returns, and it does: it explains the default vs. expanded shape, approximate sizes, and which fields are withheld. For a single-optional-parameter read tool, nothing material 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 already 100% for the single `fields` parameter, so the baseline is 3. The description nonetheless adds value beyond the schema: it names a concrete useful field ('sportSettings') with its contents and rough size, and flags that certain fields (credentials, email, DOB) behave specially when requested.

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 and resource ('Get the athlete profile: identity, physiology and account info'), which is far more informative than the tautological title. It does not, however, differentiate itself from the sibling get_athlete_profile, leaving the agent to guess which of the two retrieves what.

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 implies when to use which field selection ('pass fields ["sportSettings"] for per-sport FTP... or ["*"] for everything'), but gives no explicit guidance on when to prefer get_athlete over get_athlete_profile, nor any exclusion conditions. 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=true and openWorldHint=true, so safety and boundary behavior are covered by structured fields. The description adds only that the profile is 'public', which is modest extra context but does not disclose return shape, pagination, or field availability.

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 that front-loads the verb and resource with no filler. The '(name, bio, location, etc.)' parenthetical is useful illustration, though the 'etc.' is slightly loose.

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-param read tool with annotations carrying the safety profile and no output schema, the description is minimally adequate. It never explains the difference from the similarly named sibling get_athlete, which is the main completeness gap an agent would care about.

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, which is the baseline-4 case. The schema has no parameters to document, and the description correctly implies no inputs are needed, so nothing material is missing.

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 (get) and resource (athlete public profile), plus an enumeration of what fields come back (name, bio, location). It does not differentiate from the sibling get_athlete, which appears to be a closely related tool, so it falls short of 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?

No when-to-use guidance and no exclusions. In a family that contains a sibling named get_athlete, the description never tells an agent which of the two to call or under what circumstances, leaving selection to guesswork.

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. Beyond that, the description discloses return-shape behavior the annotations do not: a compact summary is returned by default, and the full structured workout requires passing fields ['*'] or naming workout_doc. This is useful behavioral context, though permission/auth and error behavior remain unstated.

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 tight sentences with zero filler; the primary retrieval purpose is front-loaded and the non-obvious return-shape caveat follows 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?

With no output schema, the description correctly carries the burden of explaining what comes back, and it does so by contrasting the default compact summary against the full record. It could go further on what the compact summary contains or how IDs are obtained, but it covers what an agent needs to call 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, but the description adds a field name not present anywhere in the schema ('workout_doc') as a way to pull the structured workout, giving an agent domain-specific guidance beyond the schema's generic '["*"] for everything'.

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 and resource ('Get a specific calendar event by ID'), which separates it from list_events and from get_activity/get_workout. It never names a sibling tool explicitly, so an agent must infer the boundary rather than being told, keeping it just short of 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?

Usage is implied by 'by ID' (you call this when you already hold an event ID), but the description offers no explicit when-to-use versus list_events or search-adjacent retrieval tools, and states no prerequisites for obtaining the ID.

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 this is a read-only, open-world call, so the bar is lower. The description adds genuinely useful behavioral detail beyond them: the shape of each returned curve (`secs`/`values`) and the non-obvious default that the bulk `activities` lookup map is stripped unless fields ["*"] is passed.

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 sentences, front-loaded with the core purpose, and each sentence carries distinct information (scope, response shape, default field filtering). No padding, though the abrupt parameter references ('`secs` and `values`') assume the reader has already seen a response.

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, the description takes on the return-value burden and does explain the curve structure and the omitted activities map. It leaves minor gaps, such as what curve windows ('42d', 'all') mean or how dates bound the aggregation, but the essentials for calling the tool correctly are present.

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 five parameters, including field selection and defaults; baseline 3 applies. The description's note about the omitted `activities` map adds a small amount of meaning to `fields`, but it largely restates what the schema's ["*"] wording already conveys.

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 and resource ('Get the athlete's best mean maximal power curves') and adds the scope 'across activities of one sport', which implicitly separates it from the single-activity sibling get_activity_power_curve. It never names that sibling explicitly, so the agent must infer the distinction from the 'across activities' phrasing.

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 guidance and no alternatives named. The only conditional text ('unless you pass fields ["*"]') describes a parameter behavior, not a situation for choosing this tool over get_activity_power_curve or get_activity_best_efforts.

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 nothing beyond that: it does not say what happens on a missing/invalid ID, whether the result includes nested route data, or any rate-limit/access behavior.

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 short sentence with the key qualifier ('by ID') front-loaded and zero filler. It is efficient, though the brevity comes partly from under-specification rather than tight editing.

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 full schema coverage and read-only annotations, the core information is present. However, with no output schema, the description never hints at what a route object contains, leaving the return shape entirely unexplained.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents route_id fully. The description's 'by ID' merely restates the parameter; baseline 3 applies since the schema does the work.

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) and resource (route) with the retrieval key (ID), so an agent knows it fetches a single route rather than a collection. It does not explicitly name list_routes or search_activities as the alternatives, so it is clear but not sibling-differentiating.

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 when-to-use guidance, no prerequisites, and no mention of when to prefer list_routes or another sibling. The agent must infer that this is for single-route lookup by identifier.

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 nothing beyond them: no indication of what a wellness record contains, whether a missing date returns empty or errors, or any auth/quota context. It does not contradict the annotations, it simply adds no behavioral value.

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 short, front-loaded sentence with zero filler. It is efficient rather than padded, though the brevity leaves no room for the routing or return-shape context an agent would benefit from.

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 single-parameter read tool with full schema coverage this is close to adequate, but with no output schema the description does not tell the agent what a wellness record actually holds. Minimal but defensible.

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 the single date parameter is fully documented with a regex pattern and YYYY-MM-DD guidance. The description cannot add meaning beyond the schema here, 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?

Clear verb+resource ("Get the wellness record") narrowed by scope ("for a specific date"), which distinguishes it from the range-oriented list_wellness and the mutating update_wellness. It stops short of naming those siblings explicitly, so the differentiation is inferable rather than stated.

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 "for a specific date" — a single-record fetch — but the description never says when to prefer it over list_wellness or what to do for a range. No prerequisites, no exclusions, no named alternative.

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 nothing beyond that: no note on behavior for an unknown ID, no indication of what a workout record contains, and no scope constraints on 'library'.

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 short sentence with no filler, and the resource and lookup key are front-loaded. It is efficient, though the extreme brevity leaves room for a useful clause about the identifier's origin or failure behavior.

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 single-parameter read tool with annotations covering the safety profile, the essentials are present. With no output schema and no description of the returned workout structure or error behavior for a bad ID, an agent still lacks some operational context.

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 is a single required parameter and schema description coverage is 100%, so the schema fully documents workout_id. The description only restates that the lookup is by ID, adding no format or sourcing detail beyond the schema; 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 verb and resource ('Get a specific workout from the library by ID'), which is unambiguous about what the tool returns. It doesn't explicitly name the sibling list_workouts to contrast retrieval of one item vs enumeration, so sibling differentiation is implied rather than stated.

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 'by ID' implies the caller must already have an identifier, which is the natural precondition for use. However, there is no explicit when-to-use guidance or routing to alternatives such as list_workouts or search_activities.

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 that results are a compact summary by default, but that same fact is already spelled out in the `fields` schema entry, so the added behavioral value is thin. Nothing about pagination or the `limit` ceiling of 500 is surfaced.

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 tight sentences with the list/date-range scope front-loaded and no filler. The second sentence largely restates the `fields` schema description, which slightly dilutes its 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?

For a read-only list tool with a fully documented schema and no output schema, an agent has what it needs: scope, defaults, and how to expand the payload. Only pagination behavior and the relationship to search_activities are 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 coverage is 100% and each parameter carries its own description, so the baseline is 3. The description points at `fields` but adds no syntax or default detail beyond what the schema already provides.

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+resource (list activities) with scope (for a date range), which cleanly separates it from get_activity, get_activity_streams, and other single-activity siblings. It does not explicitly name search_activities as the alternative, so differentiation is implied rather than stated.

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 date-range framing implies when this tool applies, and the hint about `fields` steers parameter choice, but there is no explicit when-to-use versus search_activities or the get_* siblings, and no prerequisites or 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 already cover the safety profile (readOnlyHint, openWorldHint), yet the description adds genuinely useful behavior: the default response is a compact summary that omits the structured-workout document, and fields can change that. This non-obvious default would otherwise surprise an agent. It stops short of 5 because it says nothing about result ordering, result caps, or pagination for large ranges.

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, zero waste, and the core purpose plus the most surprising behavior (default compact projection) are both front-loaded. Nothing 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?

For a list tool with no output schema, the description covers purpose, scope, and the return-shape default, and annotations cover read-only safety. It is missing only operational detail such as pagination or whether very wide date ranges are truncated, which keeps it from a 5.

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 fields, oldest, and newest all documented in the schema (including the compact 14-field default and the ["*"] escape hatch), so the schema carries the load. The description restates the fields behavior but adds no syntax or format detail beyond it, making the baseline 3 correct.

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 (List) and resource (events on the athlete's training calendar) scoped to a date range, which an agent can readily distinguish from the singular get_event sibling. It does not explicitly name a sibling or carve out what it is not, so it falls just short of 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?

Usage is only implied: the date-range framing suggests bulk retrieval versus get_event for a single event, but no when-to-use or when-not-to-use guidance is given. No mention of alternatives, prerequisites, or limits on range size.

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 nothing beyond that: no indication of pagination, result size, whether retired/inactive gear is included, or that it is scoped to the authenticated athlete (leaving that to inference).

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 short sentence with the resource front-loaded and the scope trailing. Nothing is padded or redundant.

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 list tool with annotations covering safety and no output schema, the description is sufficient to call it correctly and even sketches the return contents ('bikes, shoes, etc.'). It stops just short of noting athlete scoping/auth and whether all gear or only active gear is returned.

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 per the rubric the baseline is 4. There is no parameter surface for the description to explain or omit.

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 + resource ('List all gear') with concrete examples (bikes, shoes) and an explicit scope ('for the athlete'). No sibling tool covers gear, so there is nothing to confuse it with, though it does not explicitly differentiate itself from the get_/list_ activity and event family.

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 rather than stated: 'for the athlete' signals it returns the authenticated athlete's equipment, and there are no alternative gear tools to route between. No when-not conditions or prerequisites (e.g., auth/scope requirements) are given.

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 known. The description adds only the vague 'saved' qualifier and athlete scoping; it says nothing about result volume, ordering, or pagination behavior for what is presumably an unbounded list.

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 short, front-loaded sentence with no waste. It is efficient, though arguably under-specified rather than crisply 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?

The tool is simple (no params, no nested objects), but with no output schema the description should at least hint at what a 'route' list contains and whether it is paginated. It is minimally adequate rather than 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 takes zero parameters, so the baseline is 4. There are no parameter semantics for the description to clarify.

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 and resource ('List saved routes') with athlete scoping, so the agent knows this is a retrieval of persisted routes. It does not explicitly distinguish itself from the sibling get_route (singular) or list_activities, leaving the list-vs-single distinction implicit.

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 on when to use this versus get_route or the activity-listing tools, and no mention of filtering, pagination, or prerequisites. Usage must be inferred entirely from the name.

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 a useful inventory of what the records contain (fitness model, HRV, sleep, subjective scores), which helps an agent judge relevance. It says nothing about volume, pagination, cost, or how sparse/missing data behaves, so it adds only modest behavioral context beyond the annotations.

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

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

A single sentence that front-loads the verb and resource, then qualifies with the date-range scope and the returned data. Every clause carries information and there is no filler or redundancy.

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, the description usefully compensates by enumerating the categories of data returned, letting an agent confirm the tool covers the metrics it needs. What is missing — cardinality of results, whether missing days are returned as nulls, ordering — is minor for a read-only list call with two required date params.

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 oldest/newest formats (YYYY-MM-DD) and the fields selector (compact 23-field default, ["*"] for all ~47) are already fully documented in the schema. The description only restates that a date range is required and does not add syntax or defaults beyond that, 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?

Names a specific verb (List) and resource (wellness records) and scopes it to a date range, then enumerates the metric families returned (CTL/ATL, HRV, resting HR, sleep, weight, mood). It does not explicitly distinguish itself from the get_wellness sibling, which is the closest alternative, so it falls short of 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?

Usage is implied by the phrase 'for a date range' — an agent can infer this is the multi-day retrieval tool as opposed to the single-record get_wellness. However, there is no explicit when-to-use statement, no guidance on choosing between list_wellness and get_wellness, and no mention of prerequisites or limits.

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, and the description adds essentially nothing beyond them apart from the word 'all'. It says nothing about result volume, pagination, or whether the full library is always returned, so it does not enrich the safety profile the 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?

A single front-loaded sentence with no filler or repetition. It is efficient, though arguably so terse that it forgoes any of the extra context a list tool could usefully carry.

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 list tool with annotations covering read-only semantics, this is close to sufficient. With no output schema to describe returns, however, the description omits any hint of result shape or pagination, leaving minor gaps.

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 nothing for the description to disambiguate and the baseline of 4 applies. No param-level meaning is missing.

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 (List) and resource (workouts) and scopes it to the athlete's workout library, so the agent knows what it retrieves. It does not, however, distinguish itself from the sibling get_workout, which also targets workouts.

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 guidance, no statement of when to prefer get_workout, and no mention of prerequisites or the absence of filtering. The listing intent is only implied by the verb in the name.

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 safety is covered, but the description adds no behavioral context of its own — no result volume, no default limit note, no pagination or match semantics. It essentially restates the schema's parameter description.

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 short sentence with no filler and the core action up front. It is efficient, though so terse that it borders on under-specification rather than true conciseness.

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 two-parameter read tool with no output schema, the description is minimally sufficient. The notable gap is disambiguation from list_activities and get_activity, which an agent needs to route correctly among the many activity 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?

Schema description coverage is 100%, so both parameters (query, limit) are already documented in the schema. The description repeats 'name or tag' without adding syntax, matching rules, or guidance on the limit parameter, 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 verb (search) and resource (activities) and scopes it to name or tag matching. However, it does not differentiate itself from the sibling list_activities, so an agent cannot tell from the description alone which one to pick when browsing vs querying.

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 explicit when-to-use guidance and no mention of alternatives such as list_activities or get_activity. Usage is only weakly implied by the phrase 'by name or tag'; nothing tells the agent what to do when it lacks a query term.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description usefully adds patch semantics (only changed fields), which helps the agent avoid blanking fields, but it does not explain what happens to omitted fields, the destruction risk, or the return.

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, front-loaded with the action and scope, with the partial-update rule second. No filler or redundancy.

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 15-parameter destructive update with no output schema, the description is minimal but adequate: it establishes purpose and patch behavior. It leaves the return value and the fate of omitted fields unstated, which is a real gap for a destructive mutation.

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 all 15 parameters are already self-documenting. The description adds no parameter-level meaning beyond the schema, which is the expected 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?

States a specific verb+resource ('Update the wellness record') and scopes it to a specific date. It is distinguishable from the read siblings list_wellness/get_wellness, though it does not explicitly name 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?

'Only supply the fields you want to change' gives clear how-to-use (partial update) guidance. However, there is no when-to-use context, no exclusions, and no routing to alternatives such as the get_/list_wellness siblings.

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