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

Annotations already declare it as a safe, idempotent read, so the description's real value is the operational constraints it adds: prices must be relayed verbatim, currency is AUD, GST is included, and delivery is Australia-only. The 'relay exactly as returned' instruction is a non-obvious behavioral rule an agent would otherwise get wrong. It stops short of saying whether engine errors or unpriceable combinations come back as partial results.

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 with what is priced and at how many quantities, then the delivery and currency constraints in a short follow-up sentence. Four compact sentences with little waste; the AUD/GST sentence and the Australia-only sentence could be merged since they cover the same ground.

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 an output schema present, the description need not explain return values, and it does supply the key regional and formatting constraints. The one real gap is routing: an agent looking at both price_job and price_quantities gets no signal about which one fits a single-quantity versus ladder request.

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 80%, so the schema already documents postcode format, the 8-quantity cap, and the nested configuration fields. The description reinforces the quantity cap and the postcode-versus-address_id choice but adds no format or constraint detail beyond the schema; the basic baseline of 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+resource+scope: prices one job across up to 8 quantities, with an optional delivered price for an Australian postcode. It never distinguishes itself from the sibling price_job, which is the most likely source of confusion for an agent choosing between them.

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?

Usage is implied by the quantity ladder and the postcode/address options, but there is no explicit when-to-use-this-vs-price_job or vs estimate_delivery guidance, and no stated prerequisites such as needing a product_id from get_product and ids from size/stock fields.

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