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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral detail beyond them: the stale flag semantics (true when the latest fetch failed and the price is the last verified one) and the error-object response for unknown ids. It stops short of noting caching or freshness windows, which would have made it a 5.

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?

One dense, front-loaded sentence that leads with what is returned and only then qualifies with the stale/error cases. Nothing is wasted, though the parenthetical example list makes it longer than strictly necessary.

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?

There is no output schema, and the description compensates by enumerating the returned fields (secondary prices, USD/EUR equivalents, spec, source URL, verified_at, stale flag, other listings) and the error case. That is everything an agent needs to call and interpret this single-parameter read tool.

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% and the schema already documents sku_id with an example. The description supplies additional example id formats (vps/ovhcloud/..., llm/anthropic/...), but that largely restates the schema's format hint, so the baseline 3 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?

States a specific verb and resource (current list price of one SKU) plus the exact granularity, and the mention of 'other listings of the same model' and 'stale flag' clearly distinguishes it from get_history (historical) and search_skus (discovery). An agent can pick it out of the sibling set without opening the schema.

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?

Implicit usage: it clearly takes an id 'as returned by search_skus' and covers the unknown-id error case, but it never explicitly says when to prefer get_history, cheapest_for_spec, or estimate_cost. The agent must infer the current-vs-historical boundary from the word 'current'.

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