get_price_history

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

Annotations already declare readOnly, openWorld, and idempotent hints. The description adds valuable behavioral details: the data granularity (weekly averages), the partial week caveat for the last point, and the uncertainty about city-specificity. This goes beyond the structured hints and gives the agent realistic expectations about the data's nature and limitations.

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 two short paragraphs, front-loaded with the main purpose. Every sentence contributes either data characteristics or a caveat. There is no redundancy or filler, making it highly efficient for an agent to parse quickly.

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 the output schema already defines the return structure, the description covers all essential behavioral aspects: what the data represents, the partial week caveat, and a pointer to the current price. It is complete for a simple retrieval tool, leaving no critical information missing for correct invocation.

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 describes both parameters with 100% coverage, including defaults and formats. The description adds a semantic note about the `city` parameter by warning that city-specificity is unconfirmed, which informs how to interpret results by city. This is a modest but useful addition beyond the schema.

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 clearly states the tool provides weekly average selling prices for a product, with the specific resource being the price history card on DNS. It distinguishes itself from current-price retrieval by explicitly noting the last point is not the current price and referencing `current_price_rub`, which differentiates it from sibling `get_product`.

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 guides usage by clarifying that the returned data is historical weekly averages, not the current price, and points to `current_price_rub` as the source for current price. However, it does not explicitly name an alternative sibling tool or state when to choose this tool over `get_product`, leaving some inference to the agent.

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