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

Beyond the readOnly/idempotent annotations, it discloses credit accounting (uncharged for items with no range), partial-failure semantics (priced items returned, `batch.truncated` names the rest), plan-based caps, and the auth requirement. These are behavioral facts an agent cannot get from structured fields and that materially affect call strategy.

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?

Four tight sentences with no filler: what it is, what an item looks like, what it costs, what happens on truncation, and what's required. The cost and truncation facts are front-loaded where they matter most.

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?

With no output schema, the description still names the key response field (`batch.truncated`) and explains the partial-return shape, and it covers limits, billing, and auth. Nothing essential to calling this correctly is left unstated.

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 67%, and the description supplies the missing semantic layer: an item can be a bare string or an object carrying 'its own q/category/country/state', which implies per-item override of the top-level defaults — a relationship the schema's oneOf does not spell out. It still doesn't state precedence or what happens when an item object omits country.

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?

First sentence names the exact resource ('get_sold_comps') and the batching transformation ('for a list of items in one call'), so the agent can distinguish it from the single-item sibling without opening a schema. It also states the two accepted query shapes inline.

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 makes the economics explicit ('each item costs one valuation lookup, exactly as if sent alone'), which tells the agent when batching is worthwhile versus looping single calls. What's missing is an explicit 'use get_sold_comps for a single item' routing statement, so the alternative is implied rather than named.

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