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

Goes well beyond the read-only annotations: it discloses the geocoding step and its source register, the error-with-suggestions behaviour for unknown/ambiguous addresses, the billing model ($0.02, x402/USDC on Base), that failed or ungeocodable calls are not charged, and what a non-x402 client receives. These are exactly the operational facts an agent needs before calling.

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 purpose, then usage, then returns, then cost/source; each sentence carries distinct information. It is dense but not padded, though the payment and licensing sentences could be compressed slightly.

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 spell out return fields, yet it still clarifies the two useful extras (per-result distance in metres, meta.geocode). Combined with the billing, error, and data-source notes, nothing material is missing for correct invocation.

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 the schema already carries parameter definitions, giving a baseline of 3. The description adds real meaning on top: what the address string is matched against, the concrete example format, and what meta.geocode returns after matching.

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 (Find), resource (NSW development applications), and scope (within 2 km of a street address or lat/lng, nearest first), which cleanly separates it from the radius-free sibling nsw_da_search_applications. An agent can tell what it does and how it orders results 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?

Gives clear selection logic between the two input modes ('Pass address ... or pass lat and lng') and explains that lodged_from narrows to recent applications. It never explicitly says when to prefer this over nsw_da_search_applications or nsw_da_resolve_address, and lists no exclusions, so it stops short of a full when/when-not guide.

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