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

Beyond the readOnly/idempotent annotations, the description discloses the critical cross-state caveat that the states are not one series and cannot be summed or compared, that figures are new-bond medians rather than advertised rents, that many figures rest on few bonds, and that answers carry their own quarter and source limits. That is exactly the kind of non-obvious caveat an agent needs before quoting numbers.

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?

The core purpose is front-loaded, but the body is a dense run-on of clauses with internal redundancy (the 'new-bond medians, not advertised rents' point is effectively made twice) and no structural break between purpose, state differences, and parameter rules. Most sentences do work, but the packing makes it harder to scan than its content warrants.

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 high-complexity tool spanning three publishers with divergent geographies and classifications, the description covers sourcing, comparability limits, fallback behavior, and refusal semantics; with an output schema present it does not need to explain return shape. The one real gap is what happens when area and council are both provided.

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 the baseline is 3, but the description adds genuine meaning: it explains the default when neither area nor council is supplied (state-level figure), and that unspecified dwelling_type/bedrooms yields every publisher-reported breakdown rather than an aggregate. It stops short of stating precedence if area and council are both passed, which keeps it out of the top band.

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?

The opening sentence names the exact measure (median weekly rent of new bonds lodged in the latest quarter, all dwellings), the accompanying figures (bond count, year-on-year change), and the per-call scope (one state per call), plus the publisher behind each state. It also explicitly routes Victoria elsewhere ('Victoria is in vic_rents'), so an agent can separate this from a sibling without opening the schema.

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?

Strong on when-to-use conditions and exclusions within its own domain: one state per call, NSW uses postcode/council while WA uses locality, and 'with neither, the answer is the state's own figure'. It also states refusal behavior for unpublished dwelling/bedroom combinations. It does not, however, position itself against rent_check or market_indicators, so sibling selection outside vic_rents is left to inference.

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