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

Annotations already indicate readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes beyond that by disclosing the underlying source APIs, the monthly snapshot granularity, and the core outputs (utilization, coverage, net savings), which gives the agent useful behavioral context without contradictions.

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 concise and front-loaded, starting with the main action and resource. All three sentences contribute useful information: data source, aggregation, metric semantics, and API mirror. It is appropriately sized, though slightly dense and could be trimmed without losing value.

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?

Given no output schema, the description reasonably explains what the tool returns—utilization/coverage snapshots and net savings vs on-demand—and references the mirrored REST endpoint. It does not describe exact response fields or pagination, but for a parameterless read-only list tool, this is sufficient for an agent to call it correctly.

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 tool has no parameters and schema description coverage is 100%, so the description is not required to explain parameter meaning. The description does add relevant account/month framing, but since there are zero parameters, the baseline of 4 applies.

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 identifies a clear resource: Reservation (RI) and Savings Plan utilization/coverage snapshots. It also adds distinguishing context about the data source (AWS Cost Explorer APIs) and aggregation (one snapshot per commitment type per month), but it does not explicitly contrast itself with related siblings like list_savings_recommendations.

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 implies when to use this tool: when an agent needs RI/SP utilization, coverage, or savings vs. on-demand snapshots. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, so the guidance is more implicit than explicit.

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