Cyclones dans le sud-ouest de l'océan Indien

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses provenance (CMRS La Réunion bulletins republished by GDACS), the out-of-season fallback (reports the last system and the season's systems rather than failing), a scope constraint that it never names an individual school, and an attribution obligation for Météo-France records ("jamais à rundata.re"). These are non-obvious behaviors an agent could not infer from structured fields.

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 core scope is front-loaded, but the body is a single sprawling run-on clause with parenthetical lists, and the trailing English sentence largely duplicates the French content instead of adding information. It is dense rather than bloated, yet the bilingual restatement and the long enumeration of cyclone stages cost readability for an agent parsing it quickly.

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 carries the full burden of describing returns and does so thoroughly: stage classification, wind, pressure, position, distance and bearing, movement, official forecast, closest approach, alert level, and per-level school/university consequences. It also covers the past-cyclone return shape (station-by-station rain and gusts, records) and the off-season case, so nothing essential is left for the agent to guess.

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 both parameters are documented at length in the schema, including the enumerated available past cyclones and the free-text/coordinate forms for lieu, so the baseline is 3. The description's only addition is the example query "combien de pluie pendant Garance ?" which illustrates the nom mode, but adds no syntax or constraint beyond the schema.

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 names a specific resource (active tropical systems near Réunion) and enumerates the exact fields returned: stage, mean wind, pressure, position, distance/direction, movement, official forecast, closest approach, plus the préfecture alert and its ORSEC school implications. It also states the past-cyclone mode keyed by name, which lets an agent distinguish it from generic weather siblings like meteo_actuelle or prevision_meteo.

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 supplies concrete trigger queries ("il y a un cyclone en ce moment ?", "elle va passer près de Saint-Philippe ?", "école fermée demain avec le cyclone ?") that map cleanly to the two usage modes, and it states out-of-season behavior explicitly. What is missing is an explicit exclusion: it never says to use prevision_meteo or meteo_actuelle instead when the question is ordinary weather rather than a cyclone.

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