get_cost_anomalies

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

The description adds useful behavioral context: it returns an empty list when no anomaly monitors are configured, and includes root causes and impact. With no annotations provided, the description carries the behavioral burden, but does not disclose max_results handling, pagination, permission requirements, or error cases.

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 redundant content. The main action and scope come first, the edge case behavior is appended second, avoiding waste. 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?

For a relatively simple list tool with only 3 parameters. The description states what is returned, the date-range behavior, and an important edge case. The main gap is that it does not describe the output shape in more detail or the meaning of max_results, but the schema partially compensates.

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 schema already documents start and end dates as YYYY-MM-DD and marks them required; the description does not go beyond that. It does not explain max_results, which is the least-documented parameter, so the description leaves a modest gap with no added parameter meaning.

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 ('List') and a distinct resource ('cost anomalies detected by AWS Cost Anomaly Detection'), and adds what the result contains ('root causes and impact'). This clearly differentiates it from sibling tools like get_cost_and_usage or get_cost_forecast.

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 intended use case is implied: call this when you want anomalies found by AWS Cost Anomaly Detection in a date range. It does not explicitly say when not to use it or name alternatives, so the agent must infer that from the description and sibling names.

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