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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: it discloses that results are historical-only and do not imply availability, and it names privacy exclusions (broker contact details, account identifiers), which matters for downstream use of the data. It stops short of describing result shape or whether the list is paged.

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 with zero filler. The scope statement is front-loaded, followed by the availability caveat and then the privacy boundary — a sensible ordering that lets an agent stop reading after the first sentence if it only needs the purpose.

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 shape need not be explained, and the description covers scope, the availability caveat, and data exclusions. The one meaningful omission for a list tool is the limit/truncation behavior at the 25-record cap, which an agent needs to know before interpreting results as exhaustive.

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?

The single parameter 'limit' has zero schema description coverage — only default 10 and max 25 are present structurally. The description says nothing about the limit, the silent 25-record ceiling, truncation behavior, or pagination, so it does not compensate for the coverage gap on a list tool where result-set size directly affects correctness.

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 ('List') and a well-scoped resource ('historical apartment records matching the connected renter's saved requirements'), with a clear qualifier that separates it from live/current listing tools. It never names a sibling tool directly, so it falls just short of explicit differentiation from tools like list_alerted_listings or get_search_preferences.

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 sentence 'These records do not establish current or future availability' implies when this tool is the wrong choice, which is useful negative guidance. However, no alternative tool is named and there is no explicit statement of when an agent should reach for this versus the sibling listing/preference tools, leaving the routing to inference.

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