Google Health Demo

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds context about returning example payloads but does not disclose additional behavioral traits beyond what annotations provide. Since the annotation burden is met, a score of 3 is appropriate—the description adds some value but not rich behavioral 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 that is front-loaded with the key action and resource types ('Returns realistic Pixel-Watch-style example payloads...'). Every part of the sentence is informative, and there is no redundant or unnecessary 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 demo tool with one optional parameter and no output schema, the description provides the core information: what it returns (example payloads for three specific APIs) and why (to show the contract). However, it does not mention the response_format parameter or give a hint about the output structure. A brief note about the available formats would improve completeness, but the description is mostly adequate.

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 should compensate by explaining the parameter. However, the description does not mention the 'response_format' parameter at all. The schema provides an enum and default, but the description adds no meaning beyond that. This is a significant gap for a tool with only one parameter.

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 tool returns example payloads for three specific Google Health API calls. The verb 'Returns' paired with the specific resource types (e.g., google_health_daily_summary) makes the purpose unambiguous and distinguishes it from sibling tools that perform real API calls.

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 implies the tool is for previewing contract shapes before calling real APIs ('so agents see the contract before calling real Google Health APIs'). However, it does not explicitly state when to use this tool versus alternatives like directly calling the real tools, nor does it provide exclusions or conditions. The usage guidance is present but implied and incomplete.

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