Multiple aggregations over a relative range

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral detail beyond that: the computation happens in a single request, defaults are supplied for range and sampling, and the return shape is one series per aggregator. No contradiction with the annotations.

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 opens with a crisp summary, then gives two concrete use cases, an Args summary, and a Returns line. It is front-loaded and readable; the Args bullet list is somewhat redundant with the schema, but it serves as a quick reference without bloating the description.

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 an 8-parameter tool with a nested tags object and no output schema, the description is sufficiently complete: it explains the purpose, provides realistic examples, summarizes defaults, and states the return shape ('One series per aggregator with statistics'). The schema covers the remaining parameter-level details.

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 high (88%), so the schema carries most parameter meaning. The description's Args section mostly restates names, defaults, and simple labels ('Tag filters', 'Time range', 'Computation window') without adding deeper semantics beyond what the schema already provides.

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 first sentence names a specific verb (Computes), a specific resource (KairosDB metric aggregations), and the key scope (multiple aggregations in a single request over a relative time range). This clearly differentiates it from siblings like kairosdb_query_absolute, kairosdb_query_range, and kairosdb_last_value without needing to open their schemas.

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 two use cases ('Give me the min/max/avg CPU usage... over the last 7 days' and 'Daily request latency statistics over the last 30 days') give an agent concrete, recognizable situations for using this tool. It does not explicitly state when not to use it or name alternatives, but the relative-range and multiple-aggregation context is clear enough to route a query.

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