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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower. The description adds useful behavior beyond them: how results aggregate across variants, and that an unknown slug yields a not-found error. It does not mention pagination beyond 'a page', but the added context is solid.

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, front-loaded with the return payload, then parameter provenance and edge-case behavior. No filler; every clause carries operational information.

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?

For a read tool with an output schema, the description needn't detail return values, yet it usefully summarizes them and flags the not-found failure mode. Combined with 100% schema coverage and annotations, an agent has enough to invoke it correctly; only richer pagination/response guidance is absent.

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 already 100%, so the baseline is 3, but the description adds meaning the schema lacks: omitting canonical_product_id aggregates across every variant, and the condition enum is explicitly tied to reverb_search's listing condition. This clarifies parameter interaction rather than merely restating field docs.

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 (Returns) and resource (one gear model's Reverb Price Guide detail), and enumerates exactly what the payload contains: finish/year variants, monthly average sale-price history, and a page of recent sales. It is clearly distinguishable from reverb_price_guide_search.

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?

Explains the upstream dependency by naming reverb_price_guide_search's models[].slug as the source of the required slug, which implicitly routes the agent to search first. It also pre-empts confusion by clarifying that this condition enum is separate from reverb_search's listing condition, but it does not state explicit when-not/exclusion conditions.

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