get_durability_trend

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioral fact beyond them: 'No prediction is made', telling the agent the output is descriptive rather than a forecast. It says nothing about aggregation windows, behaviour on empty ranges, or units.

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 short sentences with no filler, and the core capability is stated first. The second sentence ('No prediction is made') is a caveat rather than structure, but it carries real 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?

An output schema exists, so return values needn't be described, and annotations cover the safety profile. However, with two completely undocumented date parameters, the definition leaves an agent guessing about accepted date formats and default window, which matters for correct invocation.

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% and both start_date and end_date are bare strings with no format, timezone, or default guidance in the schema. The description never references these parameters at all, so it fails to compensate for the documentation gap on a date-bounded tool.

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?

States specific verbs (summarise, compare) against a specific resource (runs over time, latest runs vs this runner's earlier runs), which distinguishes it from a plain listing tool. It does not name the sibling tools list_durability_runs or get_durability_indices, so the differentiation is left partly to inference.

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?

Usage is only implied: one would reach for this when wanting a time-series summary or a self-comparison rather than a raw run list. There is no explicit when-to-use/when-not statement and no pointer to the alternative siblings, so an agent must infer the routing.

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