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

With no annotations, the description carries the disclosure burden and does add real value beyond the schema: the 1 km radius, the near-vs-in-zone semantics, and the 15¢ per-call cost. It does not describe output shape or empty-result behavior, but with an output schema present and a simple tool, these aren't critical omissions. No contradiction with annotations since none are provided.

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 short sentences, each earning its place: the resource, the critical semantic warning, and the price. The most important caveat is front-loaded immediately after the resource phrase, with no filler.

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?

Given an output schema, return values needn't be re-explained; the description covers the non-obvious facts: the proximity radius, the `on_property` interpretation pitfall, and the cost. The main leftover gap is `gnaf_id` semantics, which is minor since it appears to be a standard identifier across this API family.

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 50%: `geojson` is fully documented in the schema, and the description's 1 km phrasing aligns with it. But `gnaf_id` is the single required parameter and the description never explains what it is, leaving the agent to infer its meaning from the sibling tool family.

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?

Identifies the resource (bushfire-prone-area overlays within a 1 km radius) and the `on_property` clarification removes the most likely misreading of the data — a row means found nearby, not in-zone. Lacks an explicit verb and doesn't name a sibling, which keeps it just under the top score.

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?

The `on_property` warning is genuinely useful operational guidance — it tells the agent how to interpret results before trusting them, which is at least as important as tool selection here. But there is no explicit statement of when to choose this tool over `properties_risks_flood`, `suburbs_risks_bushfire`, or the umbrella `properties_risks_all` tools.

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