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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds a concrete filtering behavior: only active auctions, with OR-ed criteria (postal code, or use + province + price band). It does not describe return format or edge cases, but the annotation coverage makes this acceptable.

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?

A single compact sentence front-loads the resource (active auctions) and then gives the matching conditions. There is no filler or redundant repetition of the tool name.

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 simple two-parameter read tool with safety annotations, the description covers the core behavior and matching criteria. It leaves the response shape and the effect of limit implicit, but the schema provides the limit default and the purpose is clear enough for correct invocation.

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 must compensate. It implies bien_id is the reference property ('la dada') but never names or explains limit, and the price criterion is not tied to a parameter. This is only partial compensation for the missing schema-based parameter documentation.

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 the operation as returning active auctions similar to a given property, with explicit similarity rules (same postal code, or same use in the same province with ±20% price). This clearly distinguishes it from sibling search/compare tools by focusing on a reference property and similarity matching.

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 implies this tool is for 'find similar properties/auctions to this one' requests, and the 'a la dada' wording signals a prerequisite bien_id. However, it does not explicitly mention when to prefer this over buscar_inmuebles or comparar_inmuebles, nor any exclusion conditions.

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