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

With no annotations provided, the description carries the full burden and does a good job: it discloses the output format ([ts, min_price_per_gpu_hr, median_price_per_gpu_hr, offer_count]), the bucketing behavior for different time ranges, and accepted offer_class values. It doesn't discuss error cases or auth/rate limits, but for a read-only historical query this is reasonably transparent.

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 compact, front-loaded with the core purpose, and every sentence adds useful information: naming requirement, offer_class constraint, output schema, and bucketing behavior. There is no filler or repetition.

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?

While the description richly explains output shape and bucketing, it leaves key invocation details unresolved: what gpu means, how gpu_model differs, what hours represents, and which parameters are actually expected. Without annotations or output schema and with four undocumented parameters, an agent cannot reliably construct a correct call.

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 0%, so the description must compensate. It clarifies offer_class values and gives an example for GPU model naming, but it does not explain the meaning of the gpu parameter, the gpu_model parameter, or the hours parameter. The ambiguity between gpu and gpu_model is especially problematic because both exist as separate fields with empty defaults.

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 that this tool returns price history for a single GPU model, with a concrete example ('RTX 4090') and specifies the output is a per-provider time series. It is distinguishable from siblings like market_stats or idle_history, though it does not explicitly name or contrast those alternatives.

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 the tool by requiring an exact GPU model name from search_offers/market_stats and by constraining offer_class to on_demand or interruptible. However, it does not explicitly state when not to use it or which sibling tool should be chosen for other kinds of price/market queries.

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