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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses pagination semantics (`total` is counted before `limit`/`offset`), flat pricing per call, and the returned data attributes. It stops short of discussing errors, rate limits, or data freshness beyond the 3-year window, but these are not critical for a basic call.

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 description is compact and front-loaded: the first sentence states exactly what is returned, and the second paragraph adds only the essential pagination and pricing details. Every sentence earns its place without redundancy.

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 moderately simple paginated list tool with an output schema, the description covers the core call details: the time window, the fields returned, the pagination mechanism, and the flat pricing behavior. An agent has enough information to call this tool correctly and interpret the response.

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 67%, covering `limit` and `offset` with clear documentation in the schema. The description adds context around the `suburb_name` concept by mentioning the suburb, but it does not clarify the accepted format or provide examples for that parameter. Overall the description is adequate but does not add substantial meaning beyond the schema.

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 description clearly states the resource and scope: individual properties sold in a suburb over the last 3 years, with specific fields like beds/baths, land size, price, date, and coordinates. This differentiates it from aggregate summary tools like suburbs_sales_summary, though it does not explicitly name any sibling.

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 description gives clear context for when to use the tool: to retrieve a paginated feed of recent property sales for a suburb. It also explains how to page through the full feed using the `total` count strategy, and includes a pricing consideration. It does not explicitly state when not to use it or name alternatives.

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