Google Health Daily Rollup

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds a small behavioral detail that aggregation happens over 'civil days' using Google Health dailyRollUp, but it does not describe pagination behavior, date-range semantics, or privacy/redaction behavior beyond what the schema exposes.

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 focused sentence that front-loads the core purpose and then gives concrete use-case examples. No words are wasted, and it is appropriately sized for the level of detail it intends to convey.

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 tool with 10 parameters, output schema, and a large sibling family, one sentence is insufficient. The description omits how start_date/end_date relate to civil-day windows, the role of window_size_days and page_size, the privacy_mode/raw behavior, and when to choose this over google_health_rollup or google_health_daily_summary. Although annotations and schema carry some of the burden, the overall context for correct invocation is incomplete.

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 only 50%, with start_date, page_token, window_size_days, data_source_family, and explicit_user_intent lacking descriptions. The tool description does not compensate for these gaps: it only lists example data types, which are already enumerated in the data_type schema. An agent would not learn the meaning of window_size_days, page_token, or the date semantics from either the description or those parameter schemas.

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

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

The description clearly states the operation ('Aggregate a data type over civil days') and identifies the resource and use cases ('steps, distance, calories, active minutes, weight and heart summaries'). It does not explicitly differentiate from close siblings like google_health_rollup or google_health_daily_summary, but the dailyRollUp reference makes the intent reasonably distinct.

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 'Useful for steps, distance, calories, active minutes, weight and heart summaries' implies common use cases but provides no explicit guidance on when to prefer this tool over google_health_rollup, google_health_daily_summary, or google_health_list_data_points. There are no exclusion criteria or alternative tool mentions, so usage guidance remains inferred rather than stated.

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