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

The annotations only declare readOnlyHint, but the description adds substantial behaviour: available-only filtering by default, ascending price sorting, a reliability indicator that can trigger check_availability, a prohibition on inventing or relaxing criteria, and UX rules about displaying the list directly without copying it. These are concrete operational constraints beyond 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?

Front-loads purpose, then usage trigger, defaults, reliability handling, safety rules, and next-step behaviour. The length is justified by the 13-parameter scope and high-stakes UX constraints; each sentence carries a distinct rule.

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 read-only search tool with no output schema, the description covers the trigger, default filtering, sorting, reliability handling, no-result relaxations, anti-hallucination rules, and follow-up actions. Nothing essential for correct invocation or user-facing behaviour 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 description coverage is 100%, and all 13 parameters already have descriptions, defaults, formats, or enums. The description groups buyer criteria into search concepts and mentions default availability and sorting, but adds little per-parameter syntax or meaning beyond the schema, so the baseline 3 is appropriate.

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?

Starts with a specific verb, 'Recherche', and a specific resource, 'logements neufs (lots)', in the partner catalogue, and states that it returns a list. It also distinguishes this broad search from sibling actions such as check_availability, get_lot, compare_lots, and list_promoters.

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?

Gives an explicit trigger: 'Utiliser dès qu'un acquéreur décrit un projet', followed by the buyer criteria city, typology, budget, surface, outdoor space, delivery date, and promoter. It also states the default available-only behaviour, forbids relaxing criteria unilaterally, and routes follow-up actions to get_lot, compare_lots, contact, or check_availability when reliability is low.

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