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 behavioral context beyond them: hard range caps that differ by data type (14 days for heart-rate, active-minutes, total-calories, calories-in-heart-rate-zone; 90 days otherwise), which is not present in the schema and directly affects call planning. It does not say what happens when the cap is exceeded (error vs truncation), 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?

Three tight sentences, front-loaded with what is returned and the bucketing model before the constraint sentence. No filler. The date-limit sentence is dense but every clause carries a distinct, actionable constraint.

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 4-parameter read tool with no output schema and presence/absence of annotations covering only safety, the description supplies the essentials: bucketing semantics, examples of the per-day vs per-N-days output, and range limits. Remaining gaps are boundary behavior (does an out-of-range request error or clamp?) and timezone handling of startDate/endDate across buckets.

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

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

Schema coverage is 75%, so dataType, startDate, endDate and windowDays are all documented in the schema, including the default-1 and 7-for-weekly behavior of windowDays. The description reinforces this with the "per N days" and "weekly distance" phrasing but adds no new semantics such as unit of the returned values or how partial buckets are handled at range boundaries. Baseline 3 is appropriate.

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

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

The description states a concrete verb+resource: aggregated values bucketed per day (or per N days) for a named data type, with three illustrative examples (steps per day, average heart rate per day, weekly distance). It establishes its role as the trends tool, but never names or contrasts the near-identical siblings get_rollup and get_daily_summary, so an agent cannot fully disambiguate from the text alone.

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?

"Best tool for trends" is a usable when-to-use cue, and the per-data-type max range (14 vs 90 days) tells the agent when the call will fail. However, no alternative is named for point-in-time retrieval, and the relationship to get_daily_summary/get_rollup is left implicit, which is a significant gap given how similar those siblings appear.

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 scoping semantics (all metrics in one call, sleep attributed to the day it ended, date defaults to the user's Google Health time zone) but says nothing about response shape, missing-data behavior, or payload size. With annotations carrying the safety burden, this is adequate but not rich.

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 core purpose and a metric inventory, followed by a concrete usage example. No filler, no repetition of the title.

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

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

For a single-optional-parameter read tool with no output schema, this covers purpose, scope, time-zone defaulting, and entry-point routing well. The only gap is not describing what happens for days with no data or how the metrics are aggregated, which a caller might reasonably want to know.

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

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

Schema coverage is 100% and the single date parameter is fully documented in the schema, including the local-date format and today's default. The description adds only the implicit notion of a bounded single-day window, which is marginal value beyond the schema. Baseline 3 applies.

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

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

The description names a specific verb and resource (one-call overview of a single day) and enumerates exactly which metrics are returned: steps, distance, calories, active zone minutes, floors, resting heart rate, HRV, sleep, and exercise sessions. This enumeration clearly differentiates it from siblings like get_data_points or get_daily_rollup, which imply narrower raw or ranged access.

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 says "Start here for questions like 'how did I do today/yesterday'", giving a clear entry-point rule for day-level questions. It does not explicitly name the alternative to use for multi-day ranges or raw point queries, which is why this falls 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 carries the behavioral load and does so well: result ordering (newest first), the pagination contract ('Pass nextPageToken back as pageToken' — an output field documented nowhere else), and an API quirk that filtering for electrocardiogram treats start as UTC and ignores end. Those are exactly the non-obvious traits an agent needs before calling.

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 dense sentences, front-loaded with what the tool returns before caveats and pagination mechanics. Every sentence carries distinct information — examples, alternative routing, pagination, and the ECG exception — with no restatement of the name or title.

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

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

For a 6-parameter read tool with no output schema, the description covers return ordering, result volume, pagination tokens, and a filtering edge case, which is most of what's needed. Minor gaps remain: no mention of how the advanced 'filter' parameter supersedes start/end, and no guidance on pageSize tradeoffs beyond what the schema states.

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

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

Schema coverage is 67%, and the description fills the most consequential gaps: it explains pageToken's real source (nextPageToken from a prior response, which the schema leaves undocumented) and overrides the schema's 'end defaults to start' with the ECG-specific rule that end is ignored. It does not mention the filter parameter's override of start/end, which remains schema-only.

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 ('Raw records for a data type, newest first') and enumerates the record families it returns (sleep sessions with stages, exercise sessions, weight entries, resting heart rate, HRV, SpO2, ECG). It also positions itself against siblings by naming the rollup tools as the alternative for high-frequency types, so an agent can distinguish it 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 conditional exclusion: for heart-rate and steps, prefer the rollup tools because they produce many points per day. That is real routing guidance, not implied usage. It stops short of covering the other siblings (get_daily_summary, list_data_types) or when raw-vs-summary is otherwise preferred.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description contributes the non-obvious trait that buckets are anchored to physical elapsed time rather than calendar boundaries, which materially affects interpretation. It does not discuss how gaps, partial buckets at range edges, or empty windows are handled, which is the remaining behavioral unknown for a time-bucketing tool.

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

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

Two sentences, zero filler: the first defines the operation and its scope, the second handles disambiguation. The examples do real work rather than padding, and the alternative is placed after the definition where it is most useful.

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

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

There is no output schema, so the description is the only place the return shape could be characterized, and it never says what a result looks like (buckets with timestamps, units, empty periods). For a four-required-parameter aggregation tool with an open-world enum, this leaves a meaningful gap for correct interpretation of 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 75%, with unit examples already inline for startTime/endTime and windowMinutes, so the schema carries most of the load. The description reinforces the windowMinutes meaning through the "60 minutes" example but adds nothing about the dataType enum or how it interacts with bucket size. Baseline 3 is appropriate.

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

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

"Aggregated values over physical-time windows" states a specific operation (aggregation) plus the axis of aggregation (physical-time windows), and the two parenthetical examples make the concept concrete. The final sentence explicitly routes away from get_daily_rollup, so an agent can distinguish the two without opening either schema.

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

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

It names one alternative (get_daily_rollup) and the condition that selects it (per-day vs sub-day windows), which is genuinely actionable routing. It gives no guidance for the other paths an agent might take — e.g. raw points via get_data_points versus aggregated windows — so the exclusion set is incomplete.

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 description's main remaining duties are the shape of the response and any auth or account-scoping caveats. It lists content categories but not how they are returned or what happens if no account/identity exists, adding little beyond the annotation profile.

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, front-loaded with the main categories, with no redundant wording. The missing verb is a content gap rather than verbosity, so it stays efficient.

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-argument read with no output schema, the description gives a reasonable inventory of what comes back, but it does not map fields to the profile/settings distinction or explain the relationship between the returned user IDs and other tools. Adequate to call correctly, thin on result interpretation.

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

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

The tool takes zero parameters, so the baseline is 4; the description correctly presents this as an identity-scoped lookup with nothing to pass in. The mention of user IDs is a small extra hint that the response is keyed to an authenticated account.

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 resources involved (Google Health identity, profile, settings) and gives concrete examples (age, height, units, time zone, goals), which distinguishes it from siblings like get_daily_summary or list_paired_devices. However, it is a bare noun phrase with no verb, so it never states that the tool retrieves/returns this data rather than, say, updating it.

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 at all: nothing says to call this first to obtain user IDs before calling data-point tools, and no exclusions or alternatives are named. The agent must infer usage from the name and sibling list alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral value by disclosing what the response contains (data types, which tools support them, max rollup range), which is exactly the context needed to use the output. It does not mention response size or pagination, keeping it just short of 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?

A single sentence that front-loads the primary fact (it lists all data types) and appends the two secondary facts an agent needs. No filler, no restatement of the name or title.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so adequately by naming the three things returned. For a zero-parameter read-only catalog tool this is nearly complete; only the exact shape/format of the response is left unstated.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. Nothing in the text conflicts with the empty schema.

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 gives a specific verb and resource ("Lists every readable Google Health / Fitbit data type") and goes further by naming the payload contents: tool support and maximum rollup range. That clearly separates it from the data-fetching siblings like get_data_points or get_rollup, 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?

There is no explicit statement of when to call this versus the sibling retrieval tools. The usage is only implied — an agent must infer it is a discovery step to run before get_data_points or get_rollup, and no exclusions or alternatives 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 real value by disclosing the return payload (battery level, last sync time) and hedges with 'when available', signalling that these fields may be null or absent — useful for an agent parsing results. It stops short of noting auth requirements or what happens with no paired devices.

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: resource first, concrete examples second, return fields last. Nothing is padded and nothing an agent needs is buried.

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 parameterless read with no output schema, the description covers what the call does and roughly what it returns, while annotations carry the safety profile. A brief note on empty-result behavior or the absence of arguments would close the remaining gap.

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

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

The tool takes zero parameters, which is the baseline-4 case: there is nothing for the description to disambiguate and no schema gaps to compensate for. It would earn a 5 only if it explicitly told the agent the call requires no 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?

The description names the resource precisely (devices paired to the account) and gives concrete examples (Fitbit Air, Pixel Watch), so an agent knows exactly what comes back. The verb 'list' is only implied by 'Devices paired to...', and it does not explicitly distinguish itself from the sibling retrieval tools.

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 content: an agent calls this when it needs the user's paired hardware. There is no explicit statement of when to prefer it over alternatives or of any prerequisite such as an authenticated account, though the sibling tools cover unrelated data domains so overlap risk is low.

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