Google Health Wellness Context

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

Annotations already declare the tool as read-only, openWorld, idempotent, and non-destructive, so the description doesn't need to repeat those. It adds the normalization target but provides no additional behavioral details such as live data fetching, caching, or error handling. This is acceptable given the annotations cover safety traits, but the description offers limited extra context.

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 sentence with no redundant words. It conveys the core action, input, and output in a compact form, earning its place without being verbose.

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?

Although an output schema exists, the description is too brief for a tool with six parameters and a normalization role. It omits how parameters like soreness or injury_flags affect the output, whether data is pulled live from Google Health, and how the normalized shape is used downstream. This gap makes the tool under-specified for an agent to invoke confidently.

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 33% (only days and timezone have descriptions). The description mentions no parameters at all, leaving notes, soreness, injury_flags, and response_format unexplained. With low schema coverage, the description should compensate, but it fails to do so.

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 uses a specific verb ('Normalize') and identifies the input ('Google Health activity/sleep context'), output ('shared wellness_context shape'), and purpose ('for recommendation engines'). This clearly distinguishes it from sibling tools focused on demos, rollups, or data inventory.

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

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

The description provides clear context: this tool is for normalizing data into a shared wellness context specifically for recommendation engines. It implies when to use it but stops short of explicitly stating exclusions or naming alternative tools, so it doesn't fully meet the 'when-not-to-use' bar.

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