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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered; the description adds genuinely new behavior: it errors when the id is no longer listed, exposes data freshness via attribution.data_updated, and flags the risk analysis as non-legal-advice. It omits auth/rate or pagination behavior, keeping it short of a 5.

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 the core action and keyed on the id, then a single long enumeration of returned fields. Dense but every clause maps to real content (lots, deposit, deadline, mode, place, risk analysis, links, freshness); the official-channel caveat at the end is short and useful.

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, return-value explanation is optional, yet the description still previews the payload, states the error condition, identifies the freshness field, and redirects bidding/payment to official urls. Nothing an agent needs to call this correctly is missing.

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% and the pattern already constrains the id format, so the baseline is 3. The description adds meaning beyond the schema by decoding what the two id prefixes represent (court auctions vs State sales), helping the agent validate provenance.

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 (retrieve full record) and resource (one listing), scoped by id, and immediately distinguishes itself from the sibling search_listings by requiring an id that came from that search. The id prefix conventions (SUB-… court auctions, BOE-B-… State sales) further pin down the resource type.

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?

Explicitly frames the call as a follow-up to search_listings and gives the exact id forms it accepts, so an agent knows when this tool applies. It does not spell out an exclusion case (e.g. what to do instead when the id is unknown) beyond noting an error is returned.

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