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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the safety profile is covered; the description adds real context beyond that: the upstream data provider (Géorisques), the 2 km radius for ICPE, and the important interpretive caveat that a missing row is not evidence of no risk. It stops short of noting data freshness, coverage gaps outside France, or how partial results behave.

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-loaded with the core question, followed by source, then the anti-duplication warning, then the caveat — a sensible order with no filler. The second sentence re-enumerates covered risks already implied by the first (argiles, risques de la commune), which is mild redundancy.

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 values need not be described, and the description covers purpose, source, scope, and the key negative-result caveat. The remaining gap is geographic/parameter-selection guidance for a four-parameter, zero-required tool where the agent must decide which identifier to supply.

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 0%, so the description must carry the burden; it partially does by framing the input as 'cette adresse ou cette commune', which signals that adresse and code_insee are alternatives rather than something the schema states. It says nothing about lat/lon, precedence when several identifiers are supplied, or expected string formats (INSEE code shape, address syntax).

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?

The description opens with a specific question and resource: natural and technological risks affecting an address or commune, then enumerates the covered domains (inondation, argiles, cavités, radon, sites pollués). It also names the source (Géorisques) and the exact datasets returned (commune risks, sismicité, ICPE at 2 km, Littoral), which lets an agent distinguish it from toise_contraintes without opening the schema.

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?

It gives an explicit when-not: 'Déjà inclus dans toise_contraintes : ne pas cumuler sans besoin', routing the agent to the sibling for combined analyses. It does not, however, state the reciprocal case (when to call this one standalone rather than toise_contraintes), nor how to choose between adresse, code_insee, and lat/lon.

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