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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: statistics come from live listings, cover both sale and rental (via the example queries), and prices are quoted in euros – all operational details an agent cannot read off the annotations.

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 purpose and the metric inventory are front-loaded in the first sentence, with the query examples following as supporting evidence. It is dense but not padded; the enumerations are long yet each item maps to an actual output field, so little could be cut without losing information.

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 5-parameter, 3-enum tool with a full schema and an output schema, the description supplies context the structured fields cannot: data provenance (live listings), currency (euros), and the breadth of statistics returned. The one missing element is explicit sibling routing against realistimo_market_index and realistimo_estimate_price.

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 documents every parameter, including the location syntax, room-count semantics and the propertyType enum glosses; baseline is 3. The description reinforces the geographic scope ('an oblast capital … or one of its квартали') and implicitly the SALE/RENT split through its examples, but adds little the schema does not already say.

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?

It states a specific verb and resource – asking-price statistics derived from Realistimo's live listings – and enumerates the returned metrics (price/m², P10–P90, median, listing counts, price-cut share, 12-month trend, rental yield, sales/mortgage counts). That is far more specific than a title restatement. It does not, however, explicitly distinguish itself from siblings like realistimo_market_index or realistimo_estimate_price, so it stops short of a 5.

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?

Four concrete user questions ('колко струва квадратен метър в Лозенец', 'цени на апартаменти във Варна', 'наеми в Пловдив', 'доходност от наем') clearly delimit the situations this tool serves. No exclusions or named alternatives are given (e.g. when to prefer realistimo_estimate_price for a single property), but the contextual triggers are unambiguous.

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