get_metric_trend

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

The description discloses that the tool returns daily values and L7/F7 means, which is a basic behavioral summary. However, with no annotations provided, the description carries the full burden and does not mention operational facts like computation of the means, time range, or output shape beyond the schema. It adds some value by defining what is returned, but not enough for a mutation-free read-only 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?

The description is a single sentence with no filler, and it front-loads the principal output ('Daily values') before the aggregate details. Every phrase contributes to clarifying the data set. It is concise without losing useful information.

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?

Despite having an output schema, the description leaves important gaps: the 'audience' parameter is doubly unexplained (schema also has no description), the L7/F7 definitions are not expanded, and the expected date range is not indicated. The combination of a missing parameter explanation and no annotations makes the description incomplete for a confident invocation of this tool.

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 description does not explain the actual parameters: 'audience' is solely mentioned in the schema, and the description's phrase 'one numeric DayRow metric' maps vaguely to 'metric'. With schema description coverage at 0%, the description was responsible for compensating, but it does not define either parameter or how the audience filter affects the output. This leaves the agent unable to correctly choose the metric or understand the audience scope beyond guessing from enum names.

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's output ('Daily values' for a metric plus L7/F7 means), which maps to a specific verb-resource: retrieving a metric trend. It does not explicitly say 'returns' or 'retrieves', but the tool name and described outcomes make the purpose clear. It is also distinct from the sibling tools about health scores, claims, risks, and expansion, which improves clarity.

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 does not provide any guidance on when to use this tool versus the sibling tools. It implies the result is daily metric data but never states 'use this when you need a daily trend' or names any alternative. An agent must infer that this is the only tool for metric trends, which is left to inference rather than explicit direction.

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