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

Annotations already declare readOnlyHint true and destructiveHint false, but the description adds substantial behavioral context: the paid cost per call (0.05 USDC), the provenance of archive data (third-party, partly unverified), and the guarantee that archive is returned separately so it never blends with curated data. These details go well beyond annotations and inform the agent about cost and data trustworthiness.

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 dense and information-rich; every sentence adds value—cost, scope, series definitions, and provenance warnings. It is long but not wasteful, front-loaded with the paid note and core purpose. It earns a 4 for efficiency given the complexity it must convey.

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 tool with six parameters and complex output (curated vs archive), the description fully explains the output structure: the fields of 'months' (avg, open/close, high/low, days, source) and the archive's content and provenance. It also notes the historical depth. No output schema is provided, so the description carries the full burden, and it covers cost, data ranges, and separation—nothing essential is missing.

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 100%, so the description does not need to explain parameters. The description does not add any additional parameter semantics; it focuses on output structure. Per the baseline rule, this scores 3.

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 states a specific verb (get monthly history) and resource (one instance type), and clarifies scope (calendar months, back to 2014 for legacy AWS). It also distinguishes the curated series from the archive, and the mention of 'rolled up from the daily series' differentiates it from daily/hourly siblings. This is clear and unambiguous.

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 explains the structure and separation of 'months' and 'archive', and notes the archive is returned separately to avoid silent blending. However, it does not explicitly state when to prefer this tool over spot_daily or spot_hourly, though the name and context imply the right use case. It provides clear context but no explicit exclusions or alternatives.

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