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

Annotations already cover read-only/idempotent/non-destructive, and the description adds real behavioral facts beyond them: prices are in AUD, totals include GST, non-Australian addresses are refused outright, and quoting matches checkout pricing. It does not discuss fee thresholds or whether unpublished/oversized jobs degrade to manual quotes, 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?

Three tight sentences, front-loaded with the outcome before the constraint and currency notes. The mid-sentence clause 'because Printdash delivers within Australia only' repeats the preceding restriction and could be trimmed without loss.

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, return values need no explanation, and the description covers the two things an agent actually needs to decide and call: geography limits and currency/GST treatment. Minor gap: it does not state that partially specified jobs are tolerated and reported back, though the schema covers that.

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 description coverage is 100%, so all three parameters are already documented, and the description mostly restates them ('given the jobs being ordered', postcode or saved address). The only added nuance is that the fee depends on the order's value, which is already in the schema's jobs description. Baseline 3 is appropriate.

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 outcome: eligibility for an Australian postcode or saved address plus the delivery fee and delivered total for a set of jobs. It distinguishes itself in substance from price_job/prepare_checkout by framing the result as 'priced the way checkout prices it', but it never names the sibling it replaces, so an agent must infer the split.

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 clear conditions: Australian postcodes only, anything else is refused, and signed-in callers may pass address_id instead of postcode. It does not explicitly say when to prefer price_job (job pricing without delivery) or where in the checkout flow this belongs, so the alternative selection is left implicit.

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