Inspect wellness data coverage

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

With no annotations, the description carries full behavioral burden and does well: it states the tool reports existence/absence of data, discloses unresolved errors, and explicitly warns that missing data is never interpreted as rest or a health outcome. It does not state side effects, but 'Report' strongly implies a read-only operation.

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 with no filler. The primary output is front-loaded, the critical interpretive caveat about missing data is included, and the cross-tool dependency is stated compactly. Every sentence earns its place.

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?

The description covers purpose and the most important semantic caveat, but with no output schema and no annotations, it leaves gaps: optional parameter behavior (default date ranges, default metrics), output shape, and how unresolved extraction errors are reported. An agent could call it correctly with the required athleteId, but may not know how to narrow or interpret 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 description coverage is 0%, so the description must compensate, but it only explains athleteId provenance ('from list_athletes'). It does not clarify startDate/endDate semantics, default date ranges, or what metrics are covered, leaving the agent to infer from the schema's enums 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 uses a specific verb ('Report') with a clear resource scope ('present and missing dates for curated wellness/training metrics') and adds the unique output of 'unresolved extraction errors'. This distinguishes it from siblings like read_series or describe_data, which focus on values rather than coverage gaps.

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 clearly conveys this tool is for coverage inspection, not for analyzing trends or values, and it explicitly routes the agent to list_athletes for the required athleteId. It lacks explicit 'do not use when...' exclusions, but the purpose statement is strong enough to suggest appropriate use.

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