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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds important context beyond them: result granularity, returned fields, rolling five-year coverage, excluded regions, and a pointer to data_as_of/coverage_note in the response.

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 description is front-loaded and information-dense: purpose first, then result shape, commune guidance, examples, and coverage limits. Every sentence earns its place, though the result-field enumeration is lengthy.

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 no output schema, the description steps in to define result granularity and returned fields, and it flags critical coverage limits. Together with annotations covering safety and schema covering all parameters, this leaves no major gaps 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 coverage is 100%, so the baseline is 3. The description still adds value by expanding on commune matching (e.g., 'Lyon' matches all 9 arrondissements; 'Paris 11e Arrondissement') and by explaining that date range and property type are optional filters.

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 and resource: listing recorded French property-transfer prices (DVF) for a commune or postcode. Clear scope and filters, but it never distinguishes itself from sibling tools such as fr_property_sale or fr_property_stats.

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?

Provides concrete usage examples ('property sales in Paris 11e in 2025', 'recent house sales in Annecy') and notes the rolling five-year coverage and geographic exclusions. It does not explicitly say when to choose this tool over siblings, but the context is clear.

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