get_sales_history

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond the schema: the credit-cost rule per month of history, the weekly aggregation of the response array, and the requirement to ask the user for the range. It does not detail response shape or pagination, but the core invocation behavior is well disclosed.

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 longer than average but well structured with paragraph breaks: purpose, use cases, and cost rule. Most sentences earn their place. The 'time machine' analogy is slightly extra but aids understanding of the tool's positioning. Front-loaded with the core purpose before the detail.

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 read-only tool with three documented parameters and no output schema, the description covers what an agent needs to select and invoke it: metrics returned, weekly aggregation, cost behavior, and default guidance. It could mention more about the response structure or limitations, but the core decision-making context is present.

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 coverage is 100%, so parameters are already documented in the schema. The description adds valuable semantics on top: the cost implication of history_range, the recommendation to default to 3 months, and the fact that weekly data is returned. This goes beyond the schema's enum defaults and justifies a score above baseline.

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 opens with a specific verb and resource: 'Retrieve a product's historical performance over up to 12 months' with weekly aggregated trends. It explicitly names the tool as the deepest competitive-intelligence tool and contrasts it with get_product_detail for simple price checks, clearly differentiating it from siblings.

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?

It gives explicit use cases (trend forecasting, seasonality analysis, conversion-rate estimation, due diligence) and an explicit non-use case ('Do NOT use it for a simple current price check'), naming the cheaper alternative. It also provides a clear default behavior ('default to 3 months') and instructs to ask the user about the history range.

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