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 real context beyond that: the data originates from the athlete's wearable (Garmin Coach) and functions as the source of truth for runs. It omits behavioral edge cases such as what happens when no plan exists or data is stale, but for a read-only getter this is adequate.

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 leads with what the tool returns and follows with the enumerated payload. Dense but every clause carries information; the trailing ownership sentence is the only slightly indirect part.

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-value explanation is not required, and the description correctly covers the data's origin. However, for a tool with an undocumented parameter and an open-world external data dependency, it should state the days_ahead window and the empty/no-plan case.

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 one parameter, days_ahead (default 7), with 0% schema description coverage, and the description never mentions it. It refers to 'upcoming workouts' without tying that window to days_ahead, so an agent must guess at the parameter's semantics and defaults.

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 resource (Garmin Coach plan from the wearable) and enumerates its contents: phase, week number, event date, today's and upcoming workouts with HR/pace targets, and run consistency. An agent knows exactly what it gets. Sibling differentiation is only implicit via the note that 'the coach plan owns the runs; plan stations and classes around it' — no sibling tool is 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 ownership statement ('plan stations and classes around it'), suggesting this is the anchor when planning other sessions. There is no explicit when-to-use/when-not, no mention of what to do if no coach plan is connected, and no routing to alternatives like get_training_summary or get_progress.

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 meaningful behavioral context beyond them: the response is orientation/capability material, not raw data, and it should shape how later data is interpreted ('its traps and how to record sessions on it'). No pagination or freshness/rate details, but for a zero-arg meta tool that is minor.

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 what the tool reveals and followed by the call-first instruction. The parenthetical capability list is dense but each item earns its place by telling the agent what signals are available before it queries them.

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 no explanation, and with zero parameters there are no argument gaps. An agent knows what it gets, when to call it, and how to use the result, which is everything needed for this orientation tool.

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

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

The tool takes zero parameters, so there are no semantics to document and the baseline is 4. The description correctly spends no space on arguments.

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 concrete resource and enumerates its contents specifically: connected wearable provider, its supported signals (readiness, sleep, HRV, coach plan, fitness trends), and its coaching guidance including traps and session recording. This clearly distinguishes it from siblings like get_readiness or get_coach_plan, which each return one slice of that data.

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?

'Call this first in a conversation and follow the guidance when interpreting data' gives an explicit sequencing rule and a downstream obligation, which is exactly the usage context an agent needs. It stops short of naming exclusions or contrasting with specific siblings, so it sits just below the top band.

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 genuine behavioral context beyond that: every metric carries an improving/stable/declining verdict, and metrics the provider does not compute are explicitly listed as missing, which tells the agent to expect partial results rather than treat gaps as 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?

The core purpose and time window are front-loaded in the first clause, and the long metric enumeration is dense but each item names a distinct return field, so it earns its space. Minor redundancy in the final sentences about verdicts and missing metrics.

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 spell out return structure, and it still previews the metric set and the verdict/missing-value conventions. The only gap is the thin treatment of the single input parameter's valid range.

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 only one parameter and schema description coverage is 0%, so the description must carry the meaning of 'weeks'. It does define the semantics as the trailing window ('improving over the last N weeks'), but it gives no default, permitted range, or minimum lookback, leaving the agent to guess sensible values.

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

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

The description states a specific resource (athlete progress trends over the last N weeks) and enumerates the metrics returned — VO2 max, predicted race times, endurance/hill/lactate scores, running impact, station progress — which clearly separates it from readiness or training-summary tools. It stops short of naming a sibling, but the scope is unmistakable.

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 'improving over the last N weeks / Coach-style' framing, so an agent can infer this is the trend-analysis call rather than a point-in-time check. However, there is no explicit when-to-use versus get_readiness or get_training_summary, and no prerequisites or exclusions 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 the safety profile is covered. The description adds nothing behavioral beyond that — notably it doesn't say what happens if no race has been set (empty result vs error) or note that data may be external/open-world.

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 compact sentence with no filler. It is front-loaded with the returned content rather than the action, which slightly weakens scanability, but there is no padding.

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 field enumeration is largely redundant with structured data, and the description leaves out the two things an agent most needs: what happens when no race profile exists and how this differs from set_race_profile. Adequate but with clear 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 the baseline is 4; there is no parameter semantics to explain and nothing misleading is stated.

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 is a noun-phrase inventory of returned fields (race date, days to go, phase, division, goal, format, station standards) rather than a statement of what the tool does. Combined with the name get_race_profile the intent is inferable, and it implicitly contrasts with set_race_profile, but it never says 'returns the athlete's race profile' 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?

No guidance on when to call this versus get_coach_plan, get_readiness, or set_race_profile. It also doesn't state a precondition such as 'call after a race profile has been configured', which matters given set_race_profile exists as a sibling.

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=true, openWorldHint=true). The description adds real value beyond them by disclosing the aggregation content, the default-to-today behavior, and the enumeration of the readiness signal values (ready_for_hard / easy / rest_or_very_easy) with reasons. It doesn't mention degraded cases such as missing provider data, which keeps it from a 5.

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 purpose, then the enumerated payload and the pairing advice. Dense and largely waste-free, though the long comma-laden enumeration of fields is slightly harder to scan than a structured list.

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 needn't be explained, and annotations cover safety, so remaining burden is light. The description covers purpose, payload contents, and signal semantics well; the only gap is the accepted date format for the lone parameter.

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

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

The single parameter has 0% schema description coverage, so the description must carry it. It does say the tool is 'for a day' and defaults to today, which explains intent and default behavior, but it never states the accepted format for 'day' (e.g., ISO date), leaving the only input partially specified.

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 ('Recovery and readiness for a day, default today') and then enumerates the concrete data it returns: readiness score, limiting factors, sleep, HRV vs baseline, resting HR, Body Battery, last hard session. This is far more than the name restates and lets an agent distinguish it from get_training_summary or get_progress.

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

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

Explicitly routes the agent: 'Pair it with get_coach_plan to decide today's session', which names the sibling and the downstream purpose. It gives clear context for use but no explicit when-not condition or exclusion rule, so it stops short of 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 safety is covered. The description adds meaningful context by noting that load balance and acute:chronic ratio are only present 'when available,' which signals conditional/missing fields, but it says nothing about the provider dependency (openWorld) beyond that hint or about empty/partial results.

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, front-loaded with the core 'week-by-week training' payload and with the conditional metrics placed last. Dense but every clause maps to a returned field, so little is wasted; it reads as a fragment rather than a full sentence.

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?

Return values need no explanation given the output schema exists, and the description complements it by naming the notable metrics. For a read-only single-parameter tool that's close to sufficient, but the unexplained `weeks` semantics and absent sibling-routing guidance leave 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 single `weeks` parameter has 0% schema description coverage, so the description must compensate and largely doesn't — it never explains that `weeks` controls the lookback window (default 4). Worse, mentioning 'the provider's 4-week load balance' could mislead an agent into thinking that figure scales with the `weeks` argument.

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 enumerates the resource precisely: week-by-week run km and count, hybrid/class sessions, hours, training load, hard sessions, plus 4-week load balance and acute:chronic ratio. It's a noun-list rather than a verb phrase, so the action ('retrieve') is implied, but the content scope is clear enough to distinguish it from siblings like get_readiness or get_coach_plan.

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 indication of when to prefer this over get_progress, get_readiness, or get_coach_plan, and no prerequisites or exclusions are stated. An agent seeing overlapping-sounding siblings gets no routing help.

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?

readOnlyHint and openWorldHint already cover the safety profile, so the description's job is lighter; it does add ordering ('newest first') which is behavior the agent needs. However it introduces 'has_note' as if it were an available filter/output, which does not appear in the schema and could mislead an agent trying to use it. The 'days' window, which governs how far back 'recent' stretches, is never explained.

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, front-loaded sentences with no filler; the core behavior and the interesting filter semantics come first. The dangling 'has_note' clause is the one sentence that doesn't earn its place, since the field isn't in 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?

An output schema exists, so return shape needn't be described. Still, for a two-parameter listing tool with zero schema descriptions, the missing explanation of 'days' and the phantom 'has_note' reference leave gaps an agent would have to guess around.

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%, so the description must compensate. It does good work on 'kind' by spelling out the accepted values ('run', 'hybrid' for HIIT/classes/strength, 'other') since no enums exist in the schema. But 'days' is completely unaddressed, leaving the recency window's meaning and default (14) unexplained.

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 plainly that this returns recent sessions in reverse-chronological order, which is a specific enough resource+scope for an agent to recognize a listing tool. Sibling tools (get_progress, get_training_summary) are summaries rather than raw session listings, but the description doesn't explicitly draw that line.

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 statement of when to call this versus get_progress or get_training_summary, and no prerequisites or exclusions. Usage must be inferred from the phrase 'recent sessions' 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=false, destructiveHint=false, openWorldHint=false, so the write profile is known. The description adds genuinely useful non-schema context — storage is local-only and never sent to the wearable provider — but says nothing about whether writes are idempotent, what happens on duplicate day entries, or validation failures.

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 tight sentences, front-loaded with the purpose and the phone-only storage caveat before the extraction instruction. Dense but every clause carries information; no filler.

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

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

An output schema exists, so return values need no explanation, and the write-safety story is covered by annotations plus the local-only note. The remaining gap is the unexplained activity_id parameter and the unstated format for day.

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?

Top-level schema coverage is effectively 0%: 'text' and 'activity_id' have no descriptions and 'day' has no format stated. The description rescues 'day' (defaults to today) and clarifies the text/stations split, but 'activity_id' — how to link a note to an existing session — is completely undocumented in both schema and description.

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?

Uses a specific verb (Save) with a clearly scoped resource (a session note for what the wearable cannot see), and explicitly distinguishes this from the wearable-sourced data that siblings like get_training_summary and list_sessions return.

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?

Gives concrete invocation guidance: extract structured stations from the athlete's words, keep verbatim text in 'text', and default to today when no day is given. No explicit when-not conditions or named alternatives, but the 'wearable cannot see' framing implicitly tells the agent which sessions this applies 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description still adds real value: '(stored locally)' clarifies there is no remote side effect, and 'Only the fields given are changed' discloses merge semantics rather than replace semantics. It stops short of saying what happens to omitted fields on a fresh profile or whether any validation is applied to division.

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 purpose and storage note are front-loaded, then the parameter details follow in a tight sequence with no filler. The division list is long but earns its place since the schema carries no enum.

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 values need no explanation, and the local-mutation nature is disclosed. However, for a four-parameter mutation with zero schema coverage, leaving race_date's format (ISO date? natural language?) and location's meaning unaddressed is a real gap an agent could stumble on.

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 all four parameters are undocumented in the schema, so the description has to compensate. It does well for two of them (the full division enumeration, goal as free text with example values) and for null/omission behavior, but 'location' and especially 'race_date' get no format or constraint guidance at all.

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: 'Set the athlete's race details', and the sibling get_race_profile makes the write-vs-read split inferable from the verb alone. It doesn't explicitly name the sibling, but a competent agent can distinguish the two without opening a 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?

Usage is implied by the mutation verb and by 'Only the fields given are changed', which tells the agent it can call it for partial updates. There is no explicit statement of when to prefer this over get_race_profile or when a profile must exist first, so the guidance is only adequate.

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