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 ordering guarantee ('newest first'), which is genuine behavioral context not in the schema, but says nothing about pagination, default limit of 10, or how many records are returned when the range is large.

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 ordering fact is front-loaded, which is good, but the bulk of the text is a long enumeration of return fields that largely duplicates the existing output schema. The one genuinely useful sentence about activity_type is buried at the end.

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 metric enumeration is redundant, and the real gaps — date format for start/end and limit semantics — are left open. An agent can probably call it with defaults, but any date-bounded query is guesswork.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it explains only activity_type (with concrete example keys). start and end are undocumented strings with no expected format (ISO date? epoch?), and limit's default of 10 and any cap are unaddressed.

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 clearly that this returns a list of activities ordered newest first, with an explicit roster of the metrics included and an activity_type filter. It never clarifies how it differs from the sibling 'activity' (singular) or from 'daily'/'training_load', so an agent must infer which one 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?

Usage is only implied: an agent can infer this is the tool for browsing many activities, and the activity_type example ('running, cycling, virtual_ride') suggests filtering by sport. There is no explicit when-to-use vs. 'activity' for a single record, no guidance on combining start/end with limit, and no 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the response is a Garmin summary DTO, but it does not disclose error behavior, authentication needs, or how much detail 'full' actually includes.

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 efficient sentence with no filler. It is front-loaded with the core purpose, though the parenthetical 'Garmin's summary DTO' is somewhat redundant with the earlier 'Garmin detail'.

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

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

With no output schema and undocumented parameter semantics, the description is too thin to fully guide invocation. It should at least clarify the activity_id input or the shape of the returned summary DTO.

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 required parameter, activity_id, with 0% schema description coverage. The description implies a single activity is identified but does not explain the parameter's format, source, or constraints beyond what the bare schema type 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 that the tool retrieves full detail for one activity and notes the Garmin summary DTO return type. The singular 'activity' implicitly distinguishes it from the sibling 'activities' list tool, but the verb is not explicit and the differentiation is not spelled out.

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 'one activity' implies this is for fetching a single known activity rather than listing activities, but there is no explicit when-to-use guidance, no prerequisites, and no direct reference to the 'activities' 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 read-only and open-world, and the description adds genuinely non-obvious behavior: a server-side allowlist, a 404 failure mode for off-allowlist paths, and a named list of what is unavailable (Training Readiness/Status, PRs, workouts, badges). It does not mention auth, rate limits, or the response shape, which keeps it below 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?

Front-loads the verb and purpose, then packs examples and the failure mode into three sentences with little waste. The path list is dense but each entry is informative rather than 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?

Given no output schema and an arbitrary-JSON return, the description doesn't need to enumerate fields, but it never says the response is raw API JSON or how errors other than 404 manifest. For an open-world generic caller that is the main remaining gap, and everything else an agent needs to form a call is 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 0% for both parameters, so the description must carry the load. It compensates for `path` by showing templated examples with {start}/{end}/{date} placeholders, which conveys the syntax well, but `params` (query string object) gets no explanation at all — no mention of keys, encoding, or whether values are raw or form-encoded.

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: a raw GET against the Personal API, positioned as the escape hatch for 'data without a tool', and gives four concrete example endpoint paths. That distinguishes it from the typed siblings (activities, timeseries, daily, etc.) by implication, though no sibling is named 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?

'For data without a tool' clearly frames when to reach for this rather than the structured siblings, and the examples show the intended shape of call. It stops short of an explicit 'prefer the typed tool when one exists' rule, so the agent must infer the fallback ordering.

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 externally. The description adds only the shape of the returned data; it says nothing about the 14-day default window, what 'end' anchors, timezone handling, or that results come from an external fitness provider (relevant given openWorldHint).

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

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

A single compact sentence that front-loads the resource and enumerates the returned fields. It is efficient, though the enumeration of return fields is only marginally useful without any usage or parameter guidance.

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 two-parameter, zero-coverage schema with no output schema, the description should explain the date range semantics and default window. It describes the return payload instead, leaving the agent to guess what 'end' and 'days' do and how averages are computed.

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

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

Schema description coverage is 0% and neither of the two parameters is documented anywhere: 'days' has only a default of 14 and 'end' is an untyped nullable string. The description's use of 'Daily' and 'averages' faintly implies a multi-day window but never explains either parameter, so it does not compensate for the coverage gap.

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

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

The description names a specific resource (daily calories burned) and enumerates the breakdown it returns: active, resting, total, and from recorded activities. That is far more informative than the bare name 'calories'. It stops short of differentiating from siblings like daily, timeseries, or list_metrics, which likely also return daily health metrics.

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 use this tool versus daily, timeseries, list_metrics, or dashboard_data, all of which plausibly return overlapping daily metric data. No prerequisites, no data-source notes, no exclusions 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 covered. The description adds useful behavioral details: the output is an image, the panel cap is 6, and certain metrics get special rendering. It stops short of stating the return mechanism (image content vs. path), the failure mode when more than 6 metrics are supplied, or how the rolling mean window is chosen.

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 output format is front-loaded in the first clause, and rendering rules follow logically. The example metric sets are dense but genuinely informative rather than filler. Slightly list-heavy, but no sentence is wasted.

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 0% schema coverage, no output schema, and four parameters, the description should define the time-window (days/end) and smoothing semantics, plus valid metric names (perhaps pointing at list_metrics). It covers only the panel limit and rendering style, so an agent cannot confidently set the date range or smoothing window from the definition alone.

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

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

Schema description coverage is 0%, so all four parameters (end, days, smooth, metrics) rely entirely on the description for meaning. The description only addresses metrics (max 6) and alludes to the rolling mean without naming or quantifying the 'smooth' parameter. days and end — the entire time window control — are never mentioned, leaving the agent to guess defaults and formats.

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 precisely what is produced: a PNG chart of up to 6 daily metrics rendered as stacked panels on a shared date axis, with points/bars for raw values and a line for the rolling mean. This clearly distinguishes it from data-returning siblings like timeseries and dashboard_data. Metric-specific rendering notes (HRV balanced band, readiness_est showing Garmin scores) further pin down the output.

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 'Good sets' examples give concrete usage hints about which metrics combine sensibly, which is real guidance beyond the schema. However, it never says when to pick chart over timeseries, dashboard_data, or weekly_report, nor any exclusions (e.g. what happens above 6 metrics). Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description's contribution is the enumeration of returned metrics, which is useful context, but it says nothing about how many days are returned by default, how 'end' bounds the window, or the ordering/granularity of 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 front-loaded sentence with no filler; the metric list is dense but every item adds information. It would be slightly stronger if it ended with scope or usage rather than only a comma-separated enumeration.

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 format need not be explained, but for a two-parameter tool sitting among many near-duplicate siblings the definition omits parameter meaning and selection guidance. That leaves an agent unable to decide between this and timeseries/list_metrics without opening the schema.

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

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

Schema description coverage is 0% and the description never mentions either parameter. 'days' (default 7) and 'end' (nullable string) are left entirely unexplained, so the description fails to compensate for the low-coverage schema; 'per day' only weakly hints at daily granularity.

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 phrase 'Everything known per day' plus a metric list conveys that this returns a daily aggregate of many body metrics, but there is no verb (get/fetch) and no differentiation from overlapping siblings such as timeseries, list_metrics, dashboard_data, training_load, hrv_night, or calories. An agent can guess the domain but not the exact operation relative to those alternatives.

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

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

There is no statement of when to use this versus the 21 siblings, several of which return the same metrics (hrv_night, calories, training_load, timeseries, dashboard_data). No prerequisites, no mention of date-range defaults or authorisation needs 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 safety and external-fetch behavior are covered by structured data. The description adds genuinely new behavioral context: the payload is compact and series values are null where Garmin has no data, which prevents misreading gaps as zeros. It stops short of describing cost/latency for what is clearly an aggregate over many upstream calls.

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?

Purpose is front-loaded in the first clause, followed by a contents list and a short usage directive. The long enumeration of sections is load-bearing since there is no output schema, though it could be tightened into grouped phrasing rather than a comma chain.

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 explaining return values and does list the major sections, which is adequate. But the one parameter is undocumented, the '30 days' versus 'default 90' tension is unresolved, and there is no hint about payload size or upstream call cost for an aggregate tool pulling many endpoints.

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

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

Schema description coverage is 0% and the single 'days' parameter (default 90) is never mentioned in the description. Worse, the description says the bundle includes 'the last 30 days of activities,' which reads as a fixed window and creates ambiguity about whether 'days' controls that section or only the series. The agent has no guidance on what changing 'days' actually affects.

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 artifact ('compact JSON bundle for building a dashboard') and enumerates its contents: snapshot, daily series, weekly rollups, load focus, activities and power profile. That is far more concrete than a tautology and implicitly separates it from single-metric siblings like timeseries or chart. It does not explicitly name a sibling for differentiation, 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?

The sentence 'Embed it as data in the page rather than re-deriving numbers' gives one clear usage directive and implicitly steers away from calling chart or timeseries repeatedly. However, there is no statement of when NOT to use it, no prerequisites (does it require a configured athlete or prior sync?), and no comparison to daily/weekly_report which likely overlap in content.

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 does add one piece of return-value context — that it includes the changes that would lower fitness age — but omits data-source/freshness requirements and any hint about response shape for a tool with no output schema.

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

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

A single front-loaded sentence with no filler; the primary payload (fitness age) leads and the secondary payload (HR zones) follows. Nothing in it is 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-param, read-only tool with no output schema, the description is the only source of truth about the return payload, and it gives just a phrase rather than documenting the structure of fitness age, its delta, or the zone breakdown. Minimum viable but thin.

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 schema baseline of 4 applies and there is nothing for the description to compensate for. No conflicting or missing parameter information.

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

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

Names two specific resources (Garmin fitness age and heart-rate zones), which is concrete enough that an agent can distinguish it from siblings like power_profile, training_load, or readiness_history. It lacks an explicit verb ('return'/'get') and does not state that it differs from those siblings by being fitness-age-specific.

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 prerequisites (e.g. requires a linked Garmin account or prior sync), and no pointer to alternatives such as training_load or power_profile for related profile metrics. The agent must infer applicability purely from the metric names.

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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds granularity context (5-minute readings), which is genuinely useful, but says nothing about how many readings come back, what date range a 'night' spans, or what happens when data is missing.

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 waste and the key distinguishing detail front-loaded. It reads as a fragment rather than a complete sentence, but nothing is padded.

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 no output schema, the description covers the purpose but leaves the one parameter and the return shape (readings array? timestamps?) entirely unexplained. Adequate as a label, thin as a specification.

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 'day' parameter has 0% schema description coverage, so the description is the only place that could explain accepted formats ('today', ISO date, relative offsets) — and it never mentions the parameter at all. A caller cannot tell from either source what date syntax is valid.

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 (a single night's HRV) and adds a concrete scope detail — it includes the 5-minute readings, which distinguishes it from coarser siblings like daily or readiness_history. The verb is only implied ('in detail'), and no sibling is named explicitly, so it stops 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?

There is no statement of when to use this versus alternatives such as intraday, timeseries, or readiness_history, all of which could plausibly return HRV-adjacent data. The agent must infer from the name alone that this is the single-night, high-resolution option.

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 this is a read-only, open-world operation. The description adds useful behavioral detail beyond that: the heart_rate mode includes resting/min/max plus samples roughly every 12 minutes, and body_battery includes level plus Garmin charge/drain events, which tells the agent what data granularity and event semantics to expect.

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 definition is short and front-loads the core purpose, then defines the key parameter. The inline quoting and 'what:' phrasing are slightly awkward, but there is little wasted text.

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 with annotations covering safety, the description is mostly sufficient: it explains the two data modes and their contents. However, without an output schema and with zero schema descriptions, it should also clarify the 'day' parameter's format and timezone behavior.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does this well for 'what' by defining both allowed modes and their contents, but it says nothing about 'day' beyond the schema default of 'today' – no date format, timezone, or historical range guidance.

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

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

The description states a specific resource and scope: an intraday curve for one day, with two named metric modes. It is clear what the tool returns, though it does not explicitly distinguish itself from siblings like daily, timeseries, or hrv_night.

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 by the purpose: fetch intraday data when you need a curve for a single day. There is no explicit when-to-use, when-not-to-use, or routing to alternatives such as timeseries or daily.

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

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

The readOnlyHint and openWorldHint annotations already establish the safety and openness profile. The description adds some scope context by saying the metrics are daily and usable by specific sibling tools, but it does not explain auth needs, rate limits, or other behavioral traits beyond that.

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

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

The description is a single short sentence with no wasted language. It is somewhat telegraphic and lacks an explicit action verb, but it remains compact and front-loads the core resource.

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

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

For a zero-parameter read-only tool with an output schema and annotations, the description gives enough context to know it concerns daily metrics used by timeseries, chart, and dashboard_data. It could be more complete by explicitly stating 'call this to discover available metric names,' but no critical information 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?

The tool has zero parameters, so there are no parameter semantics to document. The baseline for a parameterless tool is 4, and the description does not introduce anything misleading about inputs.

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 identifies the resource as daily metrics and ties them to timeseries, chart, and dashboard_data, so an agent can infer this is a listing tool for available metrics. However, it does not use an explicit verb and does not clearly distinguish itself from the related sibling tools it names.

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 'available to timeseries, chart and dashboard_data' implies the tool should be used when discovering metrics for those tools. But there is no explicit when-to-use guidance, no exclusions, and no direct comparison to alternative siblings such as daily or timeseries.

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 does add one genuinely useful behavioral note — that the values are 'approximate' — which warns the agent not to treat these as exact measurements. It says nothing about units, aggregation window semantics, or what happens when data is missing, so the added context is real but thin.

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 sentence that puts the resource name and the three output categories first, with the time-window qualifier last. No filler, though the awkward line break and the 'approximate' hedge sitting ambiguously before the label slightly blunt the front-loading.

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 does the minimum by enumerating the three load categories, and readOnly annotations cover safety. But it never states units, whether values are absolute load or relative percentages, or how the 28-day default interacts with returned data — gaps an agent would notice when interpreting results.

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 carry the parameter alone, and it does clarify that `days` is the lookback window over which load is aggregated. However, it omits the default of 28 and any guidance on sensible ranges or what an overly large window does, so it only partially compensates for the coverage gap.

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

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

The description names a concrete resource (Garmin Load Focus) and decomposes it precisely into low aerobic, high aerobic and anaerobic training load. That's specific enough to know what comes back, but it never distinguishes itself from the sibling `training_load` or `power_profile`, which an agent will plausibly confuse it with.

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 use this versus `training_load`, `fitness_profile`, or `weekly_report`, and no exclusions or prerequisites. Usage is only implied by the words 'training load,' leaving the agent to guess among several overlapping siblings.

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

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

Annotations already declare non-read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: local storage, the calibration model (offset at first, fitted slope from 4 scores), and the decay-after-workout rationale for timing. It stops short of describing what is returned or how a duplicate/overwritten entry behaves.

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

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

Four short sentences, front-loaded with what it records, then the storage/calibration rationale, then usage timing. Efficient overall, though the calibration parenthetical is more detail than an invocation decision strictly needs.

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

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

With no output schema and clear annotations, the description covers purpose, timing, and downstream effect well enough to call it. The gap is the undocumented 'day' and 'note' parameters, which leaves an agent guessing about backfilling past dates and attaching 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?

Schema description coverage is 0%, so the description must carry parameter meaning and it largely does not. It conveys the score's valid range (0-100) but says nothing about 'day' (defaults to 'today') or 'note', leaving two of three parameters undocumented anywhere.

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 (record) and resource (the Garmin Training Readiness score, 0-100) and adds that it is stored locally. The calibration clause separates it from read-only siblings such as readiness_history, so an agent can tell which one to pick without opening the 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?

Gives an explicit trigger ('whenever the user mentions their Garmin readiness') and a timing constraint ('log it close to when it was read' because readiness drops after workouts). No 'when not to use' or named alternative is given, which keeps it just 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 only declare readOnlyHint and openWorldHint, so the description adds genuine value: it discloses that the readiness figure is a model shaped like Garmin's and that Garmin's real Training Readiness is absent from the API, plus that 'today' is evaluated live and counts this morning's workouts. The main omission is cost/latency behavior for a tool that aggregates many metrics.

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 content enumeration is front-loaded and each item is informative for a composite tool, but the nested parentheticals (acute/chronic ratio, fitness/fatigue/form, the readiness component list) make it dense and slow to scan. The closing calibration sentence is valuable yet long-winded relative to the single instruction it carries.

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 return-value burden and does so well by listing what comes back and flagging that the readiness score is an estimate rather than Garmin's. The remaining gap is date-parameter behavior, which matters because past days are clearly supported by the schema.

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

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

The single `day` parameter has 0% schema description coverage and a bare default of 'today'; the description only obliquely implies date semantics via 'For today it is evaluated now'. It never states the accepted format for `day`, whether relative terms like 'yesterday' work, or how a past date changes the result (snapshot vs. live evaluation).

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 concrete resource — a composite recovery snapshot — and enumerates its contents (sleep, HRV, resting HR, Body Battery, recovery hours, training load, calories, stress, readiness), which is far more specific than a restatement of the name. It is distinguishable from siblings like readiness_history or training_load because it bundles them, though it never says explicitly 'use this instead of those'.

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 one explicit routing rule with a condition: when the user mentions their Garmin readiness score, call log_garmin_readiness so the estimate calibrates. That is real when-to-use-else guidance. However, there is no guidance on when to call morning_check versus readiness_history, daily, or training_load, so the agent must infer the boundary.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: how FTP is derived when unset (95% of best 20-min power), that W/kg appears only when weight is set, and that a fixed last-28-day window is reported alongside the `days` window. It does not discuss cost, empty-data behavior, or units of return aside from watts.

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 led by 'Cycling power' with everything else in service of describing the output. Dense with nested parentheticals, but every clause adds information and nothing is 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?

A read-only one-parameter report tool with no output schema; the description effectively serves as the output contract by enumerating the metrics returned. Only missing elements are the `days` default and behavior on missing weight/FTP data beyond the estimation rule.

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

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

With one parameter at 0% schema coverage, the description must carry the burden, and it does: `days` is identified as the lookback window for the best-power curve, distinguished from the fixed 28-day window. It does not state the default of 90 or acceptable ranges, but the core semantics are conveyed.

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 (FTP, best powers, W/kg, Coggan zones, ratios), so an agent can tell this is a cycling power report. But it is a noun phrase with no verb (compute/return) and gives almost no differentiation from siblings like fitness_profile or load_focus. The only routing aid is the set_athlete reference for FTP.

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 statement of when to use this tool versus fitness_profile or load_focus, and no exclusions. The only guidance-adjacent content is that FTP comes from set_athlete or a 95%-of-20-min estimate, which hints at a prerequisite but does not tell the agent when to pick 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 safety is covered. The description adds genuinely useful behavioral context the annotations do not: the row grain is one estimate per morning at wake, rows are aligned with their model inputs and any externally logged Garmin scores, enabling comparison. It does not mention default window behavior (days=21) or what happens when no Garmin score exists for a morning.

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 dense sentence with no filler, leading with the resource grain before the comparative purpose. The phrase 'next to its main inputs' is slightly awkward but does real work by describing row alignment.

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 detail is not required, and annotations cover the safety profile. For a history/range tool, though, the missing window semantics (default 21 days, valid range, date format for 'end') and the absent pointer to log_garmin_readiness as the counterpart leave the agent guessing on invocation.

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

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

Schema description coverage is 0% for two parameters (end, days), and the description supplies no interpretation of either — not the default 21-day window, not whether 'end' is a date string bound or inclusive/exclusive, not the expected format. With 2 undocumented params the description is the only channel available and it says nothing.

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

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

The description names the specific resource (per-morning readiness estimate at wake) and what accompanies it (model inputs and logged Garmin readiness scores), making it distinguishable from the write sibling log_garmin_readiness. It never uses an explicit verb like 'returns' or 'lists', so the action is inferred from the noun phrase 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 stated purpose — 'to judge how well the model tracks Garmin' — implies model-validation usage, but there is no explicit guidance on when to pick this over daily, morning_check, hrv_night, or the write-side log_garmin_readiness. The agent must infer that this is the read/history counterpart rather than being told.

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

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

Annotations already establish that this is a non-read-only, idempotent, non-destructive, local operation. The description adds that values are stored locally and used for power zones and W/kg, but it does not clarify overwrite-vs-merge semantics or what happens when fields are null or omitted.

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. The core action and purpose are stated immediately.

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

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

For a simple two-optional-parameter local setter with annotations and no output schema, the description covers the high-level intent. However, with both parameters nullable and not required, the agent still lacks guidance on partial updates and null clearing, which are important for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It identifies the concepts of FTP and body weight, but adds no detail on units, optionality, or the critical behavior of nullable fields (e.g., whether null clears a 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?

The description names a concrete action (store) and the specific data stored (FTP and body weight), plus its downstream purpose (power zones and W/kg). It does not explicitly differentiate this tool from similarly named siblings, but the core purpose is clear.

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 parenthetical 'used for power zones and W/kg' implies when accurate FTP/weight values matter, but it never states when to call this tool versus alternatives or what prerequisites exist. Usage is only indirectly 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?

The description says the tool refreshes local history, which implies updating or writing local state, while the annotations declare readOnlyHint=true. That is a direct contradiction of the tool's side-effect profile, and the description does not disclose what the force parameter does or what a refresh overwrites.

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

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

The description is two tight sentences with no waste. The core purpose is front-loaded, followed immediately by the usage condition and the contrast with sibling tools.

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 sync tool with no output schema, the description gives enough context to understand the main use case. However, it leaves the force parameter unexplained and its refresh-local-history wording conflicts with the readOnlyHint annotation, so an agent still lacks important behavioral 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains days partially by saying the last `days` days and giving a 365-day backfill example, but it does not mention the default of 210 or explain the force parameter 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 states a specific verb and resource: refresh the local history for a bounded number of days. It also distinguishes this tool from siblings by noting that other tools sync on their own, which clarifies the tool's unique role.

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

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

It explicitly specifies when to use this tool: for a first long backfill such as 365 days, or after watch syncs. It also names the normal alternative behavior, that other tools sync on their own, giving clear routing guidance.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description's job is to add substance beyond that — and it does, spelling out the rolling-mean behavior and the exact per-metric summary/trend payload. Since there is no output schema, this return-shape disclosure is valuable. Gaps remain on default behavior (days=60, smooth=7), how sparse/unaligned days are handled, and what `end` defaults to.

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 primary resource and output shape, followed by a compact metric-name list. The list is long (11 items) but earns its place given 0% schema coverage and no enum on `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?

For a read-only data-retrieval tool with no output schema, the description does well on return content, but it omits the time-window parameters (`days`, `end`) that determine what slice of the series is returned, and says nothing about default values. An agent can call it, but only by guessing at the windowing semantics.

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

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

Schema description coverage is 0% across all four parameters, so the description must carry the load. It explains `smooth` ("optional rolling mean of `smooth` days") and points to `list_metrics` for `metrics`, but `days` and `end` are never mentioned — their meaning, format, and defaults must be inferred from bare property names.

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 concrete verb+resource: "Aligned daily series for chosen metrics," and enumerates the derived outputs (rolling mean, per-metric last/mean/min/max, weekly linear trend). It gives concrete metric examples (hrv, rhr, sleep_score, load, acwr, ctl, tsb), so an agent knows exactly what data comes back. It stops short of differentiating itself from siblings like `daily` or `chart`, which also return time-ordered 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?

The parenthetical "(see list_metrics)" is genuinely useful routing advice for discovering valid metric names, but there is no guidance on when to pick this over `daily`, `chart`, or `dashboard_data`, and no exclusions. Usage is implied by the described output 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 the safety profile is covered. The description adds genuine interpretive context — the 0.8-1.5 ACWR band and the CTL/ATL/TSB naming — but says nothing about how the window is computed, what the default 42-day period means, or how open-world data freshness affects 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?

It is a single dense sentence that front-loads the resource name, which is good, but it degenerates into a comma-separated inventory of output fields. The list is informative yet poorly structured — a short lead sentence plus a grouped breakdown would be easier to parse.

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 must carry the return-value burden, and it does so thoroughly by naming every metric family returned. But for a tool with two unlabeled parameters and overlapping siblings, missing window/date semantics and usage guidance leave it only partially complete.

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

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

Schema description coverage is 0% for both parameters: 'end' has no type clarity beyond anyOf string/null and no format hint, and 'days' is described nowhere. The description mentions 'daily load' and 'weekly totals' but never explains that 'days' sets the lookback window or what format 'end' expects (ISO date?), so the parameters are effectively undocumented.

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

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

The description clearly identifies the resource — training load metrics — and enumerates the specific contents (acute load, ACWR, CTL/ATL/TSB, weekly totals, zone breakdowns). However, it never contrasts itself with overlapping siblings such as load_focus, fitness_profile, or timeseries, so an agent must infer the boundary 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?

No when-to-use, when-not-to-use, or alternative guidance is provided. With siblings like load_focus, fitness_profile, and timeseries covering adjacent ground, the absence of routing guidance is a real gap.

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 genuinely useful semantics (Monday week boundary, which values are averaged vs totaled, end-of-week snapshots), but says nothing about how far back data goes, how partial weeks are handled, or how many weeks are returned by default.

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 dense, front-loaded sentence that puts the granularity and week-start convention first and then enumerates the metrics. Slightly list-heavy and jargon-dense (Body Battery, fitness/form) but no wasted phrasing.

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 metric list is arguably redundant and return-value shape needn't be explained. The gaps that remain — the `weeks` parameter's meaning and the choice against sibling metric tools — are the ones an agent actually needs before calling.

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 and a default of 6, and the description never mentions it — 'week-by-week' implies a multi-week series but not that the caller controls the count. With one undocumented parameter, the description should have compensated and does not.

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 exactly what the tool returns: week-by-week averages of sleep score/hours, HRV, resting HR, stress, Body Battery, active kcal, steps, plus training-hour/load totals and end-of-week fitness/form. That is a concrete resource and scope, so an agent can distinguish it from generic timeseries tools. It does not name a verb or explicitly contrast with the `daily` sibling, keeping it at 4.

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 reach for this over `daily`, `timeseries`, `training_load`, or `readiness_history`, which all live in the same metric space. The Monday-start convention hints at the aggregation granularity but gives no selection criteria or exclusions.

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