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

Annotations already establish that this is a read-only, idempotent, open-world lookup, so the description's job is to add context — which it does: 5-minute refresh cadence, source list, prefecture releases, and the important caveat that route_du_littoral is a dated media announcement, not a measurement. It doesn't discuss result volume or pagination, keeping it from a 5.

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, cadence, sources, and field list are front-loaded, and the bilingual closing sentence is efficient. The enumeration of eight media outlets plus the field list is dense but each element earns its place; length is justified by the tool's breadth.

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 compensates by listing what each item contains (time, media, title, first sentence, communes/places, relevance to the requested place, link). That is sufficient for an agent to call and interpret results, though it omits result-set size and ordering.

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%, so all three parameters are already documented. The description restates the place/subject semantics and adds the useful clarification that a place is matched by being *named* in the item, but contributes little parameter detail beyond the schema baseline.

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?

Names the specific verb/resource (aggregated live local news of Réunion, refreshed every 5 minutes) and enumerates the sources and the per-item fields returned. It is clearly distinguishable from siblings like resume_du_jour, evenements, or transports, which cover daily summaries, events, and transit rather than media headlines.

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?

Concrete example queries ('il y a des blocages à Saint-Pierre ?', 'route fermée ?', 'dernières infos sur le cyclone') make the intended use obvious, and the place/subject framing tells the agent how to scope a call. It stops short of saying when to prefer a sibling such as resume_du_jour or evenements instead.

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

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

The annotations already establish a safe read-only, idempotent, open-world lookup, so the description need not repeat that. It adds useful behavioral context by naming data sources (service-public.fr, FINESS, OpenStreetMap, TCO) and noting freshness/coverage constraints such as monthly fuel prices, live bin status, and the limits around on-call pharmacies.

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 every major clause is relevant, but it is a dense wall of text with repeated parentheticals, multiple source lists, and many example queries. For a two-parameter tool it could be much more scannable with structured bullets or shorter examples.

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 broad read-only lookup with two parameters and no output schema, the description covers scope, sources, limitations, and example use cases well. Its main gap is that it does not describe result formatting or whether results are grouped, paginated, or ranked, though this is a minor omission given the tool type.

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, but the description adds real value by enumerating accepted `quoi` vocabulary (“carburant”, “pharmacie”, “urgences”, “marché”, “déchèterie”, “collecte”, “enfants”, etc.). It also clarifies `lieu` usage with examples like “rue Labourdonnais, Saint-Paul” and the street-plus-commune pattern.

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 precise list of covered resources (addresses, opening hours, phones, websites for public services in Réunion) and enumerates additional domains such as fuel prices, pharmacies, markets, waste collection, and children's places. It also distinguishes one overlapping case explicitly by routing Christmas or night markets to the sibling tool `evenements`.

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 multiple concrete example queries (“horaires de la mairie de Saint-Paul ?”, “prix de l'essence ce mois-ci ?”) and maps many `quoi` keywords to intended lookups. It also states clear exclusions: on-call pharmacy is only available via 3237.fr/32 37 and emergencies go through 15, while certain market events belong to `evenements`.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered; the description adds value beyond that by stating the data is operator-sourced live state (Freshmile, EZDrive, E.Leclerc), listing the per-point fields returned, and noting that an empty place means the whole island. It does not state data refresh cadence or coverage limits for 'en direct', which keeps it below 5.

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 resource statement and live-status claim are front-loaded, followed by example queries, which is a sound ordering. The French and English halves largely duplicate each other, but that is defensible for a bilingual public-data tool and the English summary is kept to one line.

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 only two fully documented optional parameters, no output schema, and complete annotations, the remaining burden is describing what comes back — which the description does by enumerating status, power, plugs, hours and network. It is essentially complete for an agent to call it correctly; only freshness/limits of the live data are unstated.

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 (lieu, rapide) already carry bilingual definitions and formats, so the schema does the heavy lifting. The description reinforces `lieu` through town-name examples, but it also uses the word 'libre' in an example query while no availability filter parameter exists, which could briefly mislead an agent into looking for one.

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 concrete resource (bornes de recharge publiques pour voiture électrique à La Réunion) and a concrete payload (live per-charge-point status, power, plugs, hours, network), and quantifies scale (136 stations, 400+ points). No sibling tool covers EV charging (velos_libre_service is bikes, transports is transit), so the resource is unambiguously separable from the rest of the catalog.

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?

Three quoted example queries (« borne de recharge libre près de Saint-Gilles ? », « où recharger rapidement à Saint-Pierre ? », « bornes au Tampon ? ») give concrete, realistic usage contexts, including a fast-charging scenario. However there is no explicit when-not-to-use or pointer to any complementary tool, so routing guidance is implicit rather than complete.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered; the description then adds domain-specific behavior beyond that, notably that the calendar is austral and differs from the metropole, that 20 December (Fèt Kaf) is included, and that no output format is described. It does not discuss caching or rate limits, so it is solid rather than exhaustive.

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 lead sentence front-loads the resource and its component data, and the example queries follow as compact routing aids. The trailing English summary duplicates most of the French content and lengthens the block without adding new information, which keeps it from a 5.

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 single optional parameter with no output schema and full annotation coverage, the description supplies enough: the four data categories it returns and the default 'tour de l'île' behavior are stated. The only real gap is the shape of the returned data across those mixed categories, which matters more because no output schema exists.

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 the single `lieu` parameter is documented in detail there (commune, beach, cirque, summit, or 'lat, lon'; empty = whole island). The description only echoes this by saying sun times are computed at the 'lieu demandé', adding the useful nuance that the place mostly affects sunrise/sunset rather than holidays, but that is a small increment over 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 and enumerates exactly what it returns: school holidays for the Réunion academy (austral calendar), public holidays including 20 December, today's date, and sunrise/sunset at a given place. That scope clearly separates it from weather siblings like meteo_actuelle, prevision_meteo, or maree, which never return calendar data.

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 provides concrete trigger phrasings (« c'est quand les vacances ? », « prochain jour férié ? », « à quelle heure se lève le soleil au Maïdo ? »), which gives an agent clear context for routing. It stops short of naming exclusions or pointing to alternatives (e.g., use maree for tides, meteo for forecast), so it is strong but not fully explicit about when not to use it.

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

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

Annotations already establish read-only/safe/idempotent, and the description adds genuine behavioral context well beyond them: how the secteurs_complets flag must be interpreted, the prohibition on inferring a street is unaffected, and the instruction to hand back the full-notice link. This is exactly the kind of failure-mode disclosure annotations cannot carry.

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?

Purpose is front-loaded and every later sentence carries an operational rule, but the long enumeration of communes and operators is dense and reads as a run-on, making the text heavier than strictly necessary for scanning.

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 one-parameter, annotation-covered read tool with no output schema, the description covers scope, covered operators, empty-input behavior, sibling routing, and reporting constraints — an agent can call and report on it correctly without further information.

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% and the single 'lieu' parameter is fully documented there (commune, beach, quartier, cirque, summit, or lat/lon). The description only restates the empty-value behavior (all recent notices), so it adds little beyond the schema; baseline 3 applies.

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 verb+resource in both languages: water-cut and do-not-drink notices from Réunion's water distributors, listing exactly which operators/communes are covered (Dionéo, La Créole, CISE, runéo, Est communes). It explicitly distinguishes itself from qualite_eau (ARS analysis conformity) and gives concrete example questions it answers.

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 explicit usage cues: example phrasings, the rule that an empty 'lieu' returns all recent notices, and routing to qualite_eau for ARS conformity. It does not, however, differentiate from the closely related sibling restrictions_eau, leaving one obvious alternative unaddressed.

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

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the bar is lower. The description still adds real value beyond them: 5-minute refresh cadence, 29 monitored stations, per-river granularity, trend and historical-flood context. It does not describe response shape or coverage gaps, which keeps it from a 5.

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 the core capability, then examples, then a bilingual restatement. The safety reminder about not crossing a submerged radier is domain-relevant but slightly tangential, and the FR/EN duplication adds length, though both are defensible for a public-safety service.

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?

No output schema exists, yet the description conveys what comes back: per-river vigilance, water height and flow, trends, historical flood references, and station coverage. Combined with annotations covering the safety profile and a fully documented single parameter, an agent has enough to invoke it correctly.

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?

With a single optional parameter at 100% schema description coverage, the schema already explains that it accepts a river or place name and that empty means the whole island. The description's example place names echo this but add no new syntax or matching behavior beyond the schema, so baseline 3 applies.

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 precise verbs and resources: Vigicrues Réunion flood vigilance per river, plus water height and flow measured every 5 minutes at 29 stations, with trends and historical flood benchmarks. An agent can clearly separate this from vigilance_meteo (weather alerts) or maree (tides) because the river/ravine domain is named explicitly.

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 example queries ("la rivière des Galets est en crue ?", "niveau de la ravine Saint-Gilles ?") that show the intended trigger conditions well. It stops short of explicitly naming when to prefer a sibling tool or when not to call it, so not quite a 5.

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

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

Beyond the readOnly/idempotent annotations, the description discloses off-season behavior ('Hors saison : le dit, avec le dernier système'), a hard scope boundary ('jamais une école en particulier'), and sourcing/attribution rules ('citer la prévision du CMRS telle quelle, jamais de trajectoire inventée ; renvoyer aux consignes de la préfecture'). These are genuine behavioral traits an agent needs and that no structured field carries.

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 purpose is front-loaded in the opening clause, but the body is a dense run-on that packs parameters, alerts, school rules, sourcing policy and example queries into comma-chained fragments, plus a redundant trailing English one-liner. Every element is useful, but the packaging lacks structure and would be easier to scan if split.

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 two-optional-parameter read tool with no output schema, the description covers the in-season case, the off-season fallback, the alert/school-implications dimension, the sourcing constraint, and the historical query case. An agent has enough to invoke correctly without guessing.

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%, so both parameters are already documented in depth. The description only adds light framing ('distance et direction depuis La Réunion ou un lieu', and '(nom)' beside the Garance example), so the schema does the heavy lifting and baseline 3 applies.

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 concrete resource (active tropical systems around Réunion), the source chain (CMRS La Réunion advisories republished by GDACS), and enumerates the concrete payload (stage, mean wind, pressure, position, distance/direction, movement, official forecast, closest approach, prefecture alert levels). This is far more specific than the sibling weather tools and makes clear it is not prevision_meteo or vigilance_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 gives explicit trigger queries ('il y a un cyclone en ce moment ?', 'où est la tempête ?', 'école fermée demain avec le cyclone ?', 'combien de pluie pendant Garance ?') that map intent to this tool versus generic weather tools. It doesn't explicitly name which sibling to use instead for non-cyclone weather, so it stops short of 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is met; the description goes further by naming the upstream dataset, disclosing that results carry distance, walking time, exact placement and hour-access vs 24h status. It also embeds a safety obligation (tell the user to call 15/112 and start chest compressions) that an agent could not infer from any structured field.

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?

Core identity, data source and example queries are front-loaded, which is right. It runs a little long — the bilingual restatement and the coverage statistic are slightly padded — but every element (examples, access-hours nuance, emergency instruction) carries information rather than filler.

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 a single optional parameter, no output schema and annotations covering the safety profile, the description still fills the main gaps: where the data comes from, how many devices, what fields come back, and what the agent must tell the user in an emergency. Nothing needed to invoke or interpret the call 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 coverage is 100% and the 'lieu' schema description already enumerates communes, beaches, neighbourhoods, cirques, peaks and 'lat, lon' coordinates, plus the empty-input case. The prose restates the same concept at a higher level without adding syntax or normalization rules, so the baseline 3 applies.

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 states a specific verb and resource — the nearest AEDs (defibrillators) to a place in Réunion — plus the data source (Géo'DAE), the coverage (1 200+ devices across 24 communes) and the returned attributes. No sibling tool covers this domain, and the French/English pairing removes ambiguity for either language of query.

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?

Two concrete example phrasings (« défibrillateur le plus proche de la plage de l'Hermitage », « défibrillateur à Cilaos ») show the exact query shape the tool expects, and the schema's 'empty = whole island' note is echoed. There is no explicit when-not-to-use guidance, but no sibling could plausibly be confused with this one, so the gap is minor.

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

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

Annotations only say readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds what an agent actually needs: reviews are read by a human with no direct reply, a short concrete message is expected, no personal data may be included, and user consent must be obtained first when the content is personal. That is substantive context beyond the structured hints.

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 purpose comes first, then the trigger conditions, then content rules and privacy caveat — a logical front-loaded order. It is somewhat long because of the bilingual duplication, but no sentence is filler.

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 write-style feedback tool with no output schema, the description covers purpose, triggers, message content, privacy constraints and what happens to the submission. An agent has everything needed to decide and to call it correctly.

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% and the enum values are documented, so the baseline is 3; the description goes slightly further by prescribing message content ('quel outil, quel lieu, ce qui manquait'), which ties the 'outil', 'lieu' and 'message' fields together in practice.

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 ('Transmet à rundata.re ... un avis sur ses données') and enumerates the four feedback categories with their meanings. None of the 28 sibling tools share this purpose — all others read municipal data, so the distinction is unambiguous.

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 explicit, self-triggering conditions: use it without being asked when another tool returned nothing, returned something wrong or incomplete, or when the user voices a wish or complaint. It also covers the follow-up case ('dit après coup qu'une information ... était fausse'), leaving no inference required.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds real behavioral context beyond them: 5-minute refresh cadence, EDF as source, and an important coverage caveat that power-cut notices are only relayed for municipalities whose legal notices permit republication (e.g. Sainte-Marie), otherwise it reports no notice or a legal restriction. It stops short of describing response shape or failure modes, so not a 5.

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 topic is front-loaded and the two capabilities are separated by a slash, but the prose is long, quote-heavy and runs together production-mix and power-cut concerns in a single block. It reads as one sprawling sentence chain rather than crisply ordered sections, and splitting the two capabilities would improve scannability.

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 burden of describing returns and does so (per-filière breakdown, renewable share, upcoming peak hours, constrained-grid status, charging advice), plus the coverage limitation for cut notices. Only the actual response structure/pagination remains unstated, which is a minor gap.

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% and the single `lieu` parameter is already documented in detail in the schema (commune, beach, cirque, summit, coordinates, empty = whole island). The description adds nothing beyond what the schema states, so baseline 3 applies.

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 definition names a specific resource — Réunion Island electricity production mix, renewable share, EDF grid signal, and relayed power-cut notices — and explicitly disambiguates from the sibling coupures_eau ("coupures de courant (électricité, pas l'eau : coupures_eau)"). An agent can tell exactly what data comes back 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 spells out trigger questions verbatim for each capability ("d'où vient l'électricité ?", "quand recharger ma voiture électrique ?", "coupure EDF prévue dans ma commune ?") and names the alternative tool for the water case. Use conditions and the exclusion are both explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real value beyond that: data provenance (venues, mairies, CINOR, OpenAgenda, reunion.fr), timezone (heure de La Réunion), and status semantics (ANNULÉ, REPORTÉ, complet, plus statut_d_apres when a local media reports before the organizer). Pagination and result limits are not mentioned.

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 purpose and example queries are front-loaded, which is good, but the long enumerations of venues, town halls and partner organizations (Sportsregions, OpenAgenda, reunion.fr) consume substantial space for marginal selection value. The bilingual duplication (full French rendering plus an English restatement) adds length without new information.

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 correctly carries the burden by listing returned fields (titre, dates et heures, salle, commune, genre, prix, billetterie, statut). Defaults and the 30-day/'a_venir' semantics are also visible in the schema. Only ordering, result volume and pagination behavior remain unspecified.

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 earns a step above it by mapping natural-language questions to parameter combinations (city + weekend → lieu + quand; genre or venue keyword → quoi), which conveys how the free-text filters are meant to be populated beyond the schema's own wording.

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 states a specific resource and scope: upcoming events in Réunion (974), enumerated by genre (concerts, théâtre, danse, festivals, marchés, cinéma en plein air). The example user questions ("concert ce soir ?", "marché forain demain ?", "c'est quand la fête de l'ail ?") make the intended job unmistakable and clearly separate it from weather, transport or news siblings.

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?

Usage context is spelled out through concrete query patterns that map directly onto the parameters (lieu + quand for "que faire ce week-end à Saint-Paul ?", quoi for "concert ce soir ?"). However, no sibling tool is named as an alternative or exclusion — an agent is not told when to prefer 'actualites' or 'calendrier' instead.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a 5-year DVF lookback window, a 500 m radius for landslide/éboulement records, point-level altitude and PPR lookup, and the specific official registries consulted. It does not mention data freshness lag or response size, which keeps it from a 5.

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 opening clause is well front-loaded with the resource, and the example questions are useful. But the middle is an undifferentiated run-on enumeration of nine data domains, and the entire content is then repeated in English, making it long for a one-parameter lookup tool.

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 must carry return-value semantics, and it does so thoroughly by naming every field family the agent will get back. Combined with the annotated safety profile, an agent has enough to call it correctly; only ambiguity about overlap with hazard-monitoring siblings remains.

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% and the single 'adresse' parameter already documents all three accepted forms (address, lieu-dit, 'lat, lon'). The description only adds French example strings that largely duplicate the schema, so the baseline of 3 applies.

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 resource (official records for an address in Réunion) and enumerates the exact data domains returned: cadastral parcel, PLU zoning, altitude, DVF median prices, PPR hazards, disaster decrees, landslides within 500 m, seismicity, radon. No sibling tool covers cadastre/urbanisme/prix, so it is clearly distinguishable from the weather/risk-monitoring siblings.

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 'Pour : « cette parcelle est constructible ? »…' lines give concrete trigger questions that map directly to the tool, which is strong usage context. It stops short of explicit exclusions — an agent unsure whether hazard questions belong here or in volcan_seismes / crues_rivieres / vigilance_meteo gets no routing guidance.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, but the description adds substantial context: data provenance, coverage back to 1900, the yesterday cutoff, granularity limits, and comparison with 1991-2020 normals and records. These are meaningful behavioral constraints beyond the 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 description is long, repeats the full content in English after French, and includes many example questions. The examples help usage, but the bilingual duplication and density reduce conciseness.

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 return-value burden and lists rain, min/max temperatures, sunshine, grey days, gusts, normals, records, and hourly events. It does not specify response format or structure, but it is otherwise complete enough to select and invoke the tool.

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 schema already documents all five parameters. The description still adds useful cross-parameter semantics: daily detail is capped at about two months, month/year granularity applies beyond that, and hourly detail is limited to short recent periods or seven days with detail=heure.

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 resource and scope: past measured weather in Réunion from Météo-France stations, with named variables and temporal coverage. It also distinguishes the tool from meteo_actuelle and 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?

Explicitly routes current conditions to meteo_actuelle and future days to prevision_meteo, while listing many natural-language queries this tool answers. The when-to-use boundaries are clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantial context beyond them: data source and cadence (SHOM gauges, one measurement per minute), computation provenance (rundata, not official prediction), accuracy bounds (~15-20 min and 5 cm), geographic validity radius, and degraded behavior beyond that radius. It even instructs the agent to disclose the precision caveat, which is exactly the behavioral disclosure a downstream agent needs.

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?

Information is front-loaded — data source first, computed-times caveat second, geographic limits third — and every clause carries operational meaning. It is nonetheless long and dense for a one-parameter tool, with some redundancy between the French and English halves and embedded response-writing instructions rather than pure tool description.

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?

There is no output schema, so the description carries the return-shape burden, and it does: current level, rising/falling state, last observed high/low, and next highs/lows over two days, or a reduced payload (nearest gauge height plus SHOM link) for distant places. Combined with the stated precision and coverage limits, nothing an agent needs to call or interpret this tool 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 coverage is 100% and the parameter's own description already explains that 'lieu' selects the nearest gauge and that empty means both. The tool description adds meaning the schema does not: any coastal place is accepted, but places beyond 15 km yield only height data without computed times, which changes how an agent should interpret and phrase results for a given 'lieu'.

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 resource and scope: sea level measured each minute by SHOM gauges at Le Port and Sainte-Marie, current level, tide direction, last observed high/low, plus next highs/lows computed over two days. It goes further by distinguishing itself from the SHOM's official prediction ("CALCULÉES par rundata ... pas la prédiction officielle du SHOM"), which tells an agent exactly what class of data it is getting versus other tide sources.

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 concrete trigger phrases ("la marée monte ?", "c'est quand la marée basse demain ?", "niveau de la mer au Port ?") and explicit applicability conditions: computed times are valid only within ~15 km of a gauge, with the qualifying communes listed. It also states the alternative for distant locations — return the nearest gauge height without times plus a link to official SHOM times — so the agent knows both when to use it and what to do outside its validity envelope.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are dated measurements tagged with station, distance and altitude, plus a microclimate warning when the requested place differs in altitude or windward/leeward aspect, and a radar-rain fallback for places without a rain gauge (Mafate, cirques, Hauts).

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 measured-variables list is front-loaded and every claim is relevant, but the same content is then restated wholesale in English, roughly doubling length with no new information, and the example-question chain is longer than needed. Effective but padded.

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 return-value burden and does it: it names the measured fields, the station metadata (distance, altitude), the rain history block, and the microclimate caveat. An agent can decide to call it and set expectations for the response without further information.

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 earns more by explaining that supplying a lieu switches on the pluviometer mode (hourly rain over 12–24 h, time of last rain, total since midnight) whereas an empty value returns a whole-island sweep. That meaningfully extends the schema's one-line free-text definition.

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+resource (measured current weather) and enumerates the exact quantities returned: temperature, rain over the last 6 minutes and last hour, humidity, wind/gusts, pressure, present weather. It also names the sibling it is not (prevision_meteo for future weather), so an agent can separate it from prevision_meteo and historique_meteo without opening a 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?

Gives concrete user-question triggers ('quel temps fait-il à Saint-Denis ?', 'il pleut à Cilaos ?', 'combien est-il tombé cette nuit ?') and an explicit exclusion with the alternative: for later today or the coming days, use prevision_meteo. The dual mode of the lieu parameter (with a place = add pluviometer data; empty = island tour) is also framed as usage guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description still adds real context beyond that: it is a model forecast not an observation, every answer is labelled as such with stated limitations (microclimates invisible), and the confidence field is ensemble agreement of 51 ECMWF scenarios rather than a probability. It does not describe latency or failure behavior when a place name is ambiguous.

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 statement (forecast, model, scope, contents) before examples and edge cases. It is long and the French/English duplication plus four quoted phrasing examples are somewhat redundant, but each block still carries decision-relevant information.

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 return-shape burden and does so: daily granularity, 3-hour slices, altitude-adjusted temperatures, UV, confidence levels and the conditional mer_de_nuages block. Caveats (label as forecast, cyclone handoff) close the remaining gaps for a read-only forecast tool.

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 nevertheless adds meaning the schema does not: temperatures are re-scaled to the location's altitude, and in the Hauts above 800 m an extra 'mer_de_nuages' block with 6–9 h and 9–12 h windows is returned. That clarifies how 'lieu' changes the response shape, not just its 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?

States a specific resource (weather forecast), its source (numerical model, not a measurement), its scope (a place in Réunion, tonight through 7 days) and its output content (sky, min/max temps adjusted to altitude, rain, wind/gusts, per day and 3-hour slices, UV, per-day confidence). It explicitly separates itself from meteo_actuelle for current conditions.

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 concrete user-phrasing examples ('will it rain tomorrow in Saint-Denis?', 'this weekend in Cilaos?') that map directly onto the tool, plus a named alternative (meteo_actuelle) for present conditions and a routing rule (cyclone → Météo-France official vigilance). When-to-use and when-not-to-use are both explicit.

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

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

Annotations already establish this as read-only, idempotent, open-world, and non-destructive. The description adds useful behavioral context beyond annotations: data source Atmo Réunion, 1–6 ATMO scale, today/tomorrow coverage, pollutants reported, and whole-island fallback when no place is supplied.

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 with the core resource and scope, then examples, fallback behavior, and a short English summary. Despite covering several details, every element is useful and there is no filler.

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 one-parameter read tool with rich annotations and no output schema, the description is complete enough: it explains what is returned (ATMO index and pollutant), temporal coverage, geographic scope, scale, and default behavior when no location is given.

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 the single lieu parameter is fully documented with free-text place types and coordinate format. The description only reinforces the empty-value behavior ('Sans lieu : toute l'île') and adds no meaningful parameter semantics 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 states a specific resource and scope: ATMO air-quality index in Réunion by commune, for today and tomorrow, with the responsible pollutant. It is clearly distinguishable from siblings such as qualite_eau or meteo_actuelle because it names the air-quality domain, provider, scale, and temporal coverage.

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 concrete usage examples, including pollution at a named commune and whether outdoor sport is advisable, and explains that an empty location means the whole island. It does not explicitly state when not to use it or name alternative sibling tools, so it falls short of full routing guidance.

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

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

Annotations already cover read-only/idempotent/safe, and the description adds substantial operational context on top: data provenance (ARS), freshness semantics (dernière analyse, 6 months), per-sample granularity, and, critically, a safety rule that the agent must never assert a site is shark-free, risk-free, or open today and must defer to the on-site flag. It also flags where the 'do not drink' verdicts live (coupures_eau), which is exactly the kind of cross-tool caveat annotations cannot express.

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 resource and scope, then triggers, then the safety caveat — a sound ordering with no filler argument. It is on the long side and the trailing English gloss plus repeat of the 'baignade' caveat add modest redundancy, but every clause carries information.

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 still conveys what comes back (last analysis, compliance, germs/parameters over limits, sample by sample) and how results should be framed verbally, including the shark-zone disclaimer. Nothing an agent needs to call or narrate results 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 coverage is 100%, so the baseline is 3, but the description adds real value for `lieu` by enumerating the accepted place space (Hermitage, Boucan Canot, La Saline, Saint-Pierre, Étang-Salé, Grande Anse, bassin Bleu, bassin Dinan), which goes beyond the schema's short examples. It confirms that `eau` may be left empty and inferred from the question and place.

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 domain (drinking and bathing water quality in Réunion, from ARS analyses) with the exact granularity: per-network last analysis, compliance and 6-month exceedances, and bathing sites sample by sample. It also distinguishes itself from the sibling coupures_eau for active 'do not drink' notices, so an agent can route correctly without opening a 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?

Four concrete example questions ('l'eau du robinet est potable à Cilaos ?', 'on peut se baigner à l'Hermitage ?') make the intended trigger unmistakable, and the pointer to coupures_eau covers the main exclusion. However, it never explicitly states when *not* to use it for the neighbouring concerns (restrictions_eau, temperature_mer), so the alternative routing is only partially mapped.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful context (data comes from the current prefectoral decree via VigiEau, coverage spans tap water, rivers, springs and aquifers), but says nothing about update frequency or how stale the 'en vigueur' data can be.

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 what the tool returns, then use cases, then the no-location default — the ordering is agent-friendly. The mirrored French/English sentence is slightly redundant but each clause still carries information.

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, two-optional-parameter tool with no output schema, the description conveys enough about the returned content (level categories, forbidden practices by profile) to call it correctly. Only the shape/format of the response is left implicit.

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 richly documented there, including free-text formats, coordinates and enum meaning, so the schema does the heavy lifting. The description restates the profile list and the per-commune granularity but adds no format or edge-case detail 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?

States a concrete resource (drought water-use restriction levels per commune), the authoritative source (arrêté préfectoral en vigueur / VigiEau), and exactly what it returns (level per commune, per water source type, and prohibited uses per profile). This clearly separates it from siblings like coupures_eau (outages), qualite_eau (quality) and vigilance_meteo (weather alerts) without naming them.

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 three realistic user-question phrasings that select this tool and states the default behavior when no location is supplied ('Sans lieu : toute l'île'). It does not, however, name an alternative tool or an explicit exclusion case, which keeps it below a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered; the description adds real context beyond that: weather is 'MESURÉE' versus forecast, a place is normalized to its commune, and gaps are surfaced in a non_inclus field with the suggested tool. It also discloses a genuine coverage limitation — waste centres only in the Ouest — which is exactly the kind of caveat an agent cannot infer from structured data.

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 opening clause is well front-loaded and the enumeration does double duty as a coverage contract, but the list is extremely long and the entire content is duplicated in French and English, roughly doubling length without adding information. A trimmed version with the same coverage claim would serve an agent better.

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 complex multi-source aggregator with no output schema, the description tells the agent what domains come back, how a place is resolved, and how missing data is reported via non_inclus. That is enough to call it correctly and interpret the response; only the response shape of each section remains unspecified.

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% and the single parameter already documents that a commune or place ('Saint-Paul', 'Boucan Canot', 'Cilaos') is resolved to its commune. The description repeats that normalization rule and adds plage/quartier/sommet as accepted place types, but contributes little beyond the schema, so the baseline 3 applies.

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 concrete verb+resource (aggregate everything that matters today for a Réunion commune in a single call) and then enumerates the domains covered: weather, vigilance, sea, air, power, roads, news, water cuts, events, market, waste centres, fuel prices, duty pharmacy. This clearly sets it apart from the single-domain siblings (meteo_actuelle, qualite_air, transports, etc.) without needing to open any 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?

Gives explicit trigger phrasings (« quoi de neuf à Saint-Paul aujourd'hui ? », « ma journée au Tampon ») and a routing hint that anything not covered appears in non_inclus together with the tool to call instead. It stops short of naming which sibling to prefer for a single-domain question or of saying 'call this first, then drill down', so the alternative-selection rule stays implicit.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is met; the description goes further with domain rules an agent must not get wrong: a closed trail is forbidden even with a GPX trace, "hors gestion ONF" does not mean open, and a closure on any ONF segment of a route forces an avertissement field that must be surfaced first.

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 the resource and status semantics, then examples, then filtering, then the warning rule — a sensible order with little pure filler. It is a dense run-on paragraph, and the bilingual summary tail partly repeats the French opening, costing a point on structure.

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?

No output schema exists, yet the description covers the key returned elements (trace_gpx link, length, IGN elevations, avertissement field) and the ONF-vs-OSM data distinction. It stops short of describing result shape or how multiple itineraries vs. single trails are returned, which keeps it from a 5.

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% and the schema descriptions already carry the example mappings ("une rando de 10 km" → 8/12 km, "sans trop de dénivelé" → 400 m). The description restates the length/elevation filters and the lieu semantics but adds no format or precedence rules beyond the schema, so baseline 3 applies.

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?

Names a specific resource (Réunion hiking trails / forest roads from the ONF map) with concrete attributes: open/closed status, closure cause, expected reopening date, GPX trace, length and elevation gain. It is unmistakably distinct from every sibling (weather, tides, volcano, water restrictions) without needing 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?

Gives explicit query phrasings it answers ("sentiers fermés à Mafate ?", "le sentier de la Roche Pendue est ouvert ?", "dénivelé du GR R2 ?") plus the empty-lieu default (all closed trails island-wide) and how the length/elevation params filter results. It even routes the agent on how to present the result (avertissement first).

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

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

Annotations already establish read-only, idempotent, open-world, non-destructive behavior. The description adds useful dynamics beyond that: daily rechecking, entries disappear when the site responds again, and it explicitly never explains why a site is down. That is meaningful operational context.

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 with the core purpose and then adds examples and behavioral notes. It is somewhat long and bilingual, but the English translation is useful and no sentence is clearly wasted.

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?

Given no output schema and only one optional parameter, the description is complete enough: it explains what each entry contains (since when, last error, missing rundata.re content) and how list membership changes. It also warns that the tool does not explain root causes.

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%, so the single optional “quoi” parameter is already well documented as a site, commune, or theme filter. The description provides example query terms but does not add syntax or filtering semantics beyond the schema, so 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?

The description states a precise resource and scope: Réunion Island public websites that are currently not responding, with daily rechecks. It is clearly distinguishable from siblings like actualites, coupures_eau, or volcan_seismes because it reports site availability failures and the resulting missing rundata.re content.

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 concrete example queries (“le site de l'OVPF marche ?”, “pourquoi pas de bulletin du volcan ?”, “le site de Sudéau ne répond plus ?”) that implicitly tell the agent when to use it. It does not explicitly name alternative sibling tools or state when not to use it, but the usage context is strong.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description usefully signals that its content is time-sensitive ('liste à jour', 'dernières nouveautés'), implying the answer changes between calls. It does not describe the response shape (e.g. whether sources and tool list are separate sections), which matters since there is no output schema.

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 French text leads with the substance (sources, licences, coverage) and places the call-to-action late but clearly. The English sentence is a compressed paraphrase rather than a full duplicate, which is reasonable for a bilingual server. Nothing reads as padding, though the bilingual split costs some tightness.

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 parameters, no output schema, and annotations covering the safety profile, the description carries the remaining burden of telling the agent what it will learn. It covers sources, licences, attribution, coverage gaps, tool inventory and changelog. A hint about the response's structure would close the last gap.

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?

The tool takes zero parameters, so there is nothing to disambiguate and no risk of misuse. Baseline 4 applies; the description correctly implies a parameterless, always-available call.

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 (data sources, licences, attribution) and enumerates the extra payloads it returns: coverage status, a live tool inventory, and recent changes. It is unmistakably a metadata/discovery tool, distinct from every weather-and-place sibling in the list, though bundling four content types makes the core purpose slightly diffuse.

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 a concrete precondition: call this before concluding that a tool or dataset does not exist. That is an actionable trigger tied to a real agent failure mode. It does not name alternative tools, but no sibling overlaps with this function, so the gap is small.

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

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

Annotations already establish read-only, idempotent, non-destructive and open-world behavior, and the description adds real operational context on top: municipal sports programs return only the mairie document link without its contents, club-published sessions are shown only when the user declares membership, and football/basket yield news headlines and links rather than parsed results. These caveats materially affect how an agent should interpret and relay the output.

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, caveats and examples are all crammed into one enormous sentence followed by a query list and a single English line. Everything is roughly relevant, but there is no chunking or front-loading beyond the opening 'Sport à La Réunion (974)', so an agent must parse a dense wall of text to find the routing rules.

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 broad multi-source aggregator with four optional parameters and no output schema, the description does the heavy lifting: it names every source domain and states what each contributes (links vs. parsed results vs. headlines). It does not describe result ordering, volume or pagination, which is a minor residual gap.

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 schema already explains `lieu`, `quand`, `sport` and `adherent` in detail; baseline would be 3. The description adds marginal semantic value by expanding club acronyms (VBSP = Volley-Ball de Saint-Pierre) and, importantly, by clarifying that the `sport` value for football/basket changes the nature of the returned data — a nuance the enum alone does not convey.

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 enumerates exactly what the tool covers: regional handball (D1) and volley (R1/R2) fixtures and results, cancellations, standings, sailing regattas, golf, rallying, Grand Raid, municipal programs and club events. That is enough for an agent to tell this apart from generic news or event tools by subject matter. It stops short of a crisp verb+resource statement and never contrasts itself with the overlapping `evenements` or `actualites` siblings, which keeps it at 4.

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?

A long list of representative queries (« match de volley dimanche dans le sud ? », « foot ou basket ce week-end ? », « qui a gagné le Grand Raid ? ») shows the agent precisely which phrasings map here. It also notes that football and basket route to news only rather than official results. What is missing is any explicit exclusion or named alternative (e.g. use `evenements` for non-sport events), so 4 rather than 5.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the description's added value is the data provenance and shape: satellite-measured values with date and distance, model forecasts with height/period/direction, returned in two separate blocks. That output structure is useful context with no output schema present. It doesn't mention coverage limits or how stale measurements can be.

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 resource and the measured-vs-forecast distinction, and each clause contributes either trigger phrasing or output structure. The wholesale French/English duplication inflates length, though it may be justified for this French-language service.

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 single-optional-parameter read tool with no output schema, the description supplies the essential missing pieces: what each of the two result blocks contains and the 4-day forecast horizon. Remaining gaps (measurement staleness, unit of temperature) are minor.

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 the lieu parameter is documented in detail (commune, beach, quarter, cirque, summit, lat/lon, empty = whole island). The description only restates 'près d'une plage ou d'un lieu côtier' and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 two distinct resources with specific verbs: measured sea temperature (satellite) and forecast waves (model, 4 days), and gives concrete example phrasings. It separates 'measured' from 'forecast' clearly, which is genuinely differentiating, but it never names the close siblings (maree, prevision_meteo, meteo_actuelle) an agent might confuse it with.

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?

Example user utterances (« la mer est à combien à Saint-Leu ? », « ça surfe à Saint-Pierre demain ? ») make the intended trigger conditions clear, including the 4-day forecast horizon. There are no explicit exclusions or named alternatives for adjacent tools, so it stops short of a 5.

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

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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds meaningful context beyond that: the data is 'en direct' (live), covers a specific network in the south of Réunion, and reports bikes-to-take and free-dock counts per station.

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 scope and live-data nature are front-loaded, and the bilingual format is appropriate for a Réunion-focused tool. The three example questions add useful clarity but make the description slightly longer than strictly necessary.

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 one-optional-parameter tool with no output schema, the description covers what is needed: live availability, per-station bikes/free-dock data, nearest-station lookup, and geographic coverage. Annotations handle the safety profile, so nothing critical 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 the single 'lieu' parameter is already fully documented in the schema (station, place, town, empty = whole network). The description reinforces this with example place names, but adds no new syntax or behavioral detail 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 the exact resource (Altervélo e-bike share), the geographic scope (Saint-Pierre, Saint-Louis, L'Étang-Salé), and the specific data returned (bikes to take and free docks per station). No sibling tool covers live bike-share availability, and an agent can immediately tell this apart from broader tools like transports.

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?

Three concrete example questions make clear when the tool is appropriate: checking bikes at a station, finding nearby bikes, and confirming return-dock availability. It does not name an alternative tool or explicitly exclude overlapping use, but no close sibling exists, so the contextual guidance is strong.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile needs no restating. The description adds real value by disclosing the data source (OVPF-IPGP) and the 30-day temporal window for seismicity, but says nothing about update cadence or return shape.

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 key capabilities are front-loaded in a single dense sentence, followed by example questions that aid matching. The bilingual duplication (full French listing plus English summary) adds length, but for a no-param tool with no output schema the enumeration is largely earning its place.

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 telling the agent what comes back, and it does so exhaustively: eruption state, alert level, last eruption date, access status, OVPF publications, and earthquakes both under the volcano and island-wide with a per-day breakdown. Nothing essential is missing 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?

The tool takes zero parameters, so the baseline is 4. The description appropriately spends its words on output content instead of inventing parameter guidance.

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 domain (Piton de la Fournaise eruption status, ORSEC alert level, Enclos Fouqué access, OVPF publications, and last 30 days of earthquakes) with concrete sub-fields. This clearly separates it from weather, cyclone, and vigilance siblings, which cover different hazards.

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 enumerates realistic triggering queries in quotes ('le volcan est en éruption ?', 'on peut monter au volcan ?', 'il y a eu un séisme ?'), giving an agent practical routing signals. It does not name exclusions or explicitly point at alternative siblings (e.g. vigilance_meteo) for non-volcanic hazards, so it stops short of a 5.

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