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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds substantial context beyond them: the single shared snapshot date across all AVMs, the fact that the ratio is only a discount where sale and valuation are close in time, the drift of the series to ~0.44 in 2016-2019 being house-price growth rather than deeper discount, and the `min_lots` suppression behavior reported through `meta.sufficient`. This is unusually rich interpretive disclosure for a read-only tool.

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 headline and the interpretive warnings are front-loaded effectively, but the passage spends real estate on competitor positioning ('EIG covers 530+ auctioneers to our six and sells API data, but runs no AVM') that does not help an agent select or invoke the tool. Several interpretive sentences earn their place; the marketing framing does not.

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?

An output schema exists, so return values need not be described, and the description covers the key interpretive pitfalls (temporal alignment, sufficient-sample gating, series drift). It is nearly complete for a 5-param statistical tool, missing only an explanation of `is_commercial` and explicit sibling routing.

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 0%, so the description carries the full burden and largely delivers: `months` is bounded with a reason (~60), `min_lots` is explained as headline suppression, and `postcode_area`/`postcode_district` are clarified as postcode-based geography rather than area_id. Only `is_commercial` is left unexplained, so it falls short of a 5.

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 states a specific verb+resource: an achieved hammer price against an AVM of the same property, yielding an auction-to-valuation discount ratio. It implicitly separates itself from the sibling auction tools (auction_comps, auction_stats, auction_lots) via the 'valuation join is the product' framing. The competitor comparison and headline stats dilute the core statement somewhat, but the purpose is unmistakable.

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?

It gives clear operational context: read `by_year` before quoting the headline, read `meta.sufficient`, and don't widen `months` past ~60 because that measures the market rather than the auction. However, it never names an alternative tool (e.g. auction_comps/auction_stats) or the condition that would route the agent elsewhere, which keeps it below a 5.

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