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

Goes well beyond the annotations: discloses the per-IP rate limit (5 lookups/day) and cost, the exact exclusion rules applied to stats (lots, for-parts, replicas, accessories, outliers), the 90-day window, the 20-listing cap versus 200 in the paid API, and that the source URL should be cited. These are operational constraints an agent cannot infer from readOnlyHint/idempotentHint/openWorldHint.

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?

Front-loaded: the first sentence establishes what the tool returns and the time window before any usage or query coaching. It is dense rather than padded, though the long parenthetical category list ('trading cards, watches, sneakers...') is the least load-bearing part.

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 return fields (median, IQR, min/max, counted vs excluded sales, recent listings with links). Combined with the rate-limit and exclusion disclosures, an agent has everything needed to call it and interpret results.

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 documented downstream, but the description still adds real meaning for 'query' by prescribing how to shape it ('specific model, number, grade or size', quote exact phrases, exclude with minus). It adds nothing new for 'site' or 'condition' beyond the enums.

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 ('Look up what an item actually SOLD for on eBay') and immediately narrows scope to completed sales over the last 90 days, excluding asking prices. It maps directly to the sibling set by being the execution tool while what_are_sold_comps is presumably the explainer.

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?

Gives an explicit trigger list ('what something is worth, what it sells for, resale value, fair price, sold comps') plus worked query examples and a free-tier cutoff. It does not name a sibling to use instead when the request is outside the 90-day/eBay scope or when the user wants the concept explained, so no alternatives or exclusions are stated.

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