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

With no output schema, the description carries the full burden and does so: it discloses refresh cadence (every 5 min), the media sources, the per-item return fields (heure, média, titre, première phrase, communes, lien), and two important caveats — route_du_littoral is a dated media announcement, not a measurement, and radars_fixes is the Interior Ministry's fixed list with speed limits, never mobile checks. This is beyond what readOnlyHint/idempotentHint alone convey.

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 and dense with useful specifics, but it is one sprawling run-on paragraph with stacked relative clauses, and the full enumeration of six media outlets plus the field-by-field listing costs more than it returns for an agent that mainly needs scope, cadence and the two caveats.

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 three-optional-parameter, no-output-schema aggregation tool, everything needed to call it correctly is present: filters, cadence, source provenance, returned fields, and the two special-case fields with their limitations. Nothing material is left to inference.

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 adds value by mapping colloquial topics to the sujet values ('manifestations et blocages' → mobilisation) and by clarifying that lieu accepts a commune or quartier, empty meaning the whole island. It does not explain the heures range beyond the schema, which already states 1–72 with a default of 24.

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?

Opens with a precise statement of what the tool returns: current local news for La Réunion (974) aggregated from named island media, refreshed every 5 minutes, plus préfecture communiqués. It also carves out the two special fields (route_du_littoral, radars_fixes) so an agent can tell this apart from siblings like resume_du_jour, transports or evenements without reading 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 three concrete trigger questions (blocages à Saint-Pierre, route fermée, quoi de neuf à Saint-Benoît) and an explicit routing rule for radars_fixes ('pour une question sur les routes ou les radars') plus an exclusion ('Jamais les contrôles mobiles'). It never names a sibling tool as the alternative, so the when-not-to-use-this-tool-instead guidance is implied rather than stated.

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 declare read-only, idempotent, open-world, non-destructive behavior, so the description appropriately focuses on domain caveats. It discloses major data sources (service-public.fr, FINESS, OpenStreetMap, TCO, Data ES, Basilic) and practical limitations such as on-duty pharmacy coverage and emergency routing. It does not contradict the annotations and adds meaningful context beyond them.

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 a single sprawling paragraph that mixes public services, fuel prices, pharmacies, hospitals, markets, waste collection, déchèteries and children's activities. It contains useful details, but it is poorly front-loaded and difficult to scan, so the conciseness and structure are weak.

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-parameter tool with no output schema, the description provides enough context about sources, coverage, caveats and example use cases to call it correctly. It could be more complete by clarifying output format or pagination, but given the annotation support and detailed domain notes, the essential context is present.

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 already 100%, so the baseline is 3, but the description adds substantial semantic guidance for 'quoi' by listing many accepted query categories and for 'lieu' by giving examples such as coordinates and street-plus-commune formats. The parameter guidance is valuable but buried inside a run-on text, making it harder to use than a structured list would be.

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 clearly establishes that this is a directory/lookup tool for public services and practical life information in Réunion, with concrete examples such as mairies, CAF, carburant, pharmacies, marchés, déchèteries and children's activities. The purpose is specific and scoped to Réunion, but the long enumeration blurs the core identity and only occasionally distinguishes it from siblings, for example by routing Christmas or night markets to 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?

Usage is supported by query examples ("horaires de la mairie de Saint-Paul ?", "prix de l'essence ce mois-ci ?", "quel jour passent les poubelles à Saint-Paul ?") and by explicit category keywords for the 'quoi' parameter. It also gives useful guidance for adjacent needs: pharmacy on duty is only known via 3237.fr/32 37, emergencies go through 15, and Christmas/night markets should use evenements. The only gap is that most other sibling alternatives are not explicitly excluded.

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, open-world behavior, so the description doesn't need to. It does add useful context beyond them: the data comes from each point's operator and is live (libre/occupé/hors service), plus provenance and coverage breadth. It omits freshness/latency or update cadence details, keeping 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 tool's subject, coverage and returned fields are front-loaded in the first clause, with example queries trailing as illustration. It is a single dense sentence plus a query list; slightly long but each element (operators, counts, field list, examples) 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 lookup with no output schema, the description enumerates the returned attributes (statut, puissance, prises, horaires, réseau), which is enough to predict the payload. It doesn't address result size/limits despite 400+ charge points, a minor remaining 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 description coverage is 100%, so both parameters (lieu, rapide) are already fully documented; baseline is 3. The description reinforces 'rapide' indirectly via 'où recharger rapidement' and 'libre' via 'borne de recharge libre', but adds no format or syntax 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 specific resource (bornes de recharge publiques pour voiture électrique), a geographic scope (La Réunion), and enumerates the data it returns: live status, puissance, prises, horaires, réseau. Counts (136 stations, 400+ points) and named operators (Freshmile, EZDrive, E.Leclerc) make it unmistakable against siblings like velos_libre_service or 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?

The 'Pour :' section supplies three representative natural-language queries ('borne libre près de Saint-Gilles', 'où recharger rapidement à Saint-Pierre', 'bornes au Tampon') that map directly to the two parameters, giving clear usage context. It stops short of naming when NOT to use it or pointing to an alternative sibling, so it doesn't reach 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, so the bar is lower; the description usefully adds that moon phases are computed ('calculés') and that results are scoped to Réunion. It does not describe output shape or whether sun/moon values are estimated for the given `lieu` versus a fixed station, but nothing is contradicted.

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?

One dense inventory sentence followed by a short query-example sentence, both front-loaded and free of filler. The enumerations are long but each item is a distinct capability, so it earns its length; a slight trim of the parentheticals would help.

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 one optional parameter, no output schema, and rich annotations, the description covers the full capability set and scope well enough to call correctly. The only gap is that, lacking an output schema, it does not hint at the shape of returned records (e.g. per-day vs per-query).

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 in-schema, including the empty-string default and coordinate format. The description only echoes it via 'au lieu demandé', adding 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?

Names a specific resource (Réunion calendar) and enumerates exactly what it returns: school holidays, public holidays including 20 décembre/Fèt Kaf, today's date, sunrise/sunset, and moon phase/times/next phases. It also flags the domain-specific quirk (calendrier austral, différent de la métropole), which distinguishes it from generic date or weather 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 :' clause supplies three concrete user phrasings that map cleanly onto invocations, which is strong routing guidance. It stops short of stating exclusions — e.g. that tide times belong to `maree` or that general weather belongs to `prevision_meteo` — leaving the agent to infer boundaries with overlapping siblings.

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 the safety profile (read-only, idempotent, non-destructive, open-world), but the description adds non-obvious data-quality behavior: secteurs_complets=false means the street list is incomplete, so absence must never be reported as 'no cut at your address', and the full-advisory link should be given. That is exactly the kind of caveat the annotations cannot convey. It stops short of describing the overall response shape, 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?

Purpose and the critical 'ne pas boire first' and incompleteness caveats are front-loaded, and most clauses carry real information. The long enumeration of communes and distributors is useful coverage detail but is dense and could be tightened.

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-param, no-output-schema read tool, the description supplies coverage area, query phrasings, default behavior, sibling routing, and the key interpretation caveat. Only return structure/freshness granularity is left implicit, 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 param already documents accepted location forms and 'empty = whole island'. The description only marginally extends it by clarifying that no location means all recent advisories, so the baseline 3 for schema-covered params 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 the specific resource (water-distributor advisories in Réunion: planned cuts, breakdowns, do-not-drink notices) with the concrete scope, and it explicitly distinguishes itself from qualite_eau, which holds the ARS compliance analyses. An agent can tell what this returns and what it does not without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives literal example queries («coupure d'eau à Saint-Denis ?», «quand revient l'eau ?»), states the no-location default (all recent advisories), and routes a related need (ARS potability analyses) to the sibling qualite_eau. That is explicit when-to-use plus an alternative, not implication.

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 confirm it is a read-only, non-destructive tool. The description adds valuable behavioral context by stating that measurements are taken 'toutes les 5 minutes' and include 'crues historiques'. While it adds data context, it doesn't add significant operational/safety info beyond what's already structurally available, hence a solid middle score.

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 text is dense but highly informative. It front-loads the core functionality and then provides examples, maintaining a good balance between detail and readability without unnecessary jargon.

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?

The combination of the description, title, and the single parameter's clear function makes the tool definition complete. Given the 'readOnlyHint' and the specific example queries, the AI has everything it needs to select and invoke the tool confidently.

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 schema coverage is 100%, meaning the description doesn't need to add basic parameter definitions. However, the description adds significant semantic meaning by defining exactly what constitutes a valid 'lieu' (e.g., 'une rivière... ou un lieu... pour les stations proches'), which goes beyond a simple string type.

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 title 'Crues et rivières à La Réunion' combined with the description clearly states the tool provides real-time flood monitoring ('Vigilance crues'). It specifies the resource (river/ravine data) and the scope (the island of Réunion), making its purpose highly specific and easy to distinguish from sibling tools like 'meteo_actuelle' or 'volcan_seismes'.

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 description explicitly provides three example query patterns ('la rivière des Galets est en crue?', etc.). This gives the AI clear guidance on the intent and phrasing required, effectively serving as 'when to use' examples compared to other situational tools.

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 behavior, and the description adds important constraints beyond them: never invent a track, give the official Météo-France link, refer to prefecture instructions, and attribute quoted Météo-France data rather than rundata.re. It also discloses off-season behavior and scopes school-related alert interpretation away from individual schools.

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 front-loads the active-system purpose, then moves through alerts, off-season handling, exclusions, and example queries. It is dense but each sentence contributes relevant scope or behavioral detail; slightly more structural separation would improve scanability.

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 tool with no output schema, it describes the returned content well: system name and stage, last advisory time, prefecture alert meaning, off-season fallback, and historical rain/gust measurements. It also covers source attribution and limitations, leaving no essential invocation detail unclear.

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 schema already covers the optional 'nom' parameter in detail, including available storm names and what measurements are returned. The description adds a useful default distinction between current active systems (no name) and historical named storms, plus a concrete query example, though the schema remains the richer parameter reference.

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 (active tropical systems around Réunion), its sources (CMRS de La Réunion / Météo-France via GDACS), and the two modes: current system status and historical lookup by name. It explicitly excludes track, position, distance, and forecast, which sharply separates it from general weather and forecast 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?

It provides concrete trigger phrases ('il y a un cyclone en ce moment ?', 'combien de pluie pendant Garance ?') and states off-season behavior and the no-track/no-forecast boundaries. However, it does not explicitly name sibling tools such as prevision_meteo or vigilance_meteo as alternatives, so routing is clear but not fully spelled out.

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 valuable context beyond annotations: the Géo'DAE data source, coverage of over 1,200 devices across 24 communes, return details including walking time and access hours, and an emergency safety caveat. It does not specify result cardinality or response format, 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 description is front-loaded with purpose and scope, then moves efficiently through returned fields, coverage, examples, and emergency guidance. It is dense but every sentence contributes; the final safety instruction is essential and not padding.

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-only lookup with no output schema, the description is complete: it states what the tool does, what data it returns, the geographic coverage, example invocations, and the required emergency advice. An agent has everything needed 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 description coverage is 100%, and the schema already explains that 'lieu' accepts commune, plage, quartier, cirque, sommet, coordinates, or empty for the whole island. The description only reinforces the location concept and gives examples, adding little semantic detail beyond the schema. 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 specific resource (défibrillateurs/DAE) and scope (les plus proches d'un lieu de La Réunion), and it lists the returned fields: adresse, distance, temps à pied, emplacement, horaires. An agent can immediately tell this is a nearest-defibrillator lookup, distinct from all listed 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?

It gives concrete example queries ('où est le défibrillateur le plus proche de la plage de l'Hermitage ?', 'défibrillateur à Cilaos ?') that clarify when to use the tool. It also adds a critical usage instruction to first tell the user to call 15/112 and start cardiac massage, though it does not explicitly state 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 only declare non-read-only, non-destructive, non-idempotent; the description adds that submissions are read by a human with no direct reply, that no personal data may be included, and that consent must be sought first when content is personal. It does not mention rate limits or whether repeated submissions are deduplicated, which is the remaining gap for a write tool.

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 and feedback types are front-loaded, followed by usage triggers, content guidance, and privacy rules in a logical order. The middle sentence is long and packs several triggers into one chain, which slightly hurts scanability 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?

For a 5-parameter write tool with no output schema, the description covers when to call, what to write, what not to include, how consent works, and what happens afterwards (human review, no reply). Missing only operational details such as frequency expectations or confirmation behavior, 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%, so the baseline is 3; the description still adds content guidance beyond the schema by telling the agent what a good 'message' contains (which tool, which place, what was missing) and by reinforcing the no-personal-data constraint on 'message' and 'question_utilisateur'. It does not add anything for 'lieu' or 'outil' beyond what the schema already documents.

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+recipient ('Transmet à rundata.re ... un avis sur ses données') and enumerates the four feedback types, immediately distinguishing it from every data-lookup sibling. An agent knows exactly what this tool does 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?

Explicitly says to call it proactively ('sans attendre qu'on le demande') and lists concrete trigger conditions: a tool found nothing, returned something false or incomplete, or the user voiced a wish/complaint or later said a fact was wrong. That is precise routing guidance rather than implied usage.

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 declare it is a safe read; the description goes well beyond that by naming the source (EDF), the refresh cadence (every 5 min), and — most valuably — the coverage limitation: outage notices are only republished for communes whose legal notice permits it (e.g. Sainte-Marie), and elsewhere the tool reports that no notice was read or that reuse is forbidden. That is exactly the kind of negative-result behavior an agent needs to interpret empty answers.

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?

Content is front-loaded and every clause carries information, but it is a single dense block with stacked parentheses and nested colons that is hard to scan. Two capabilities and their caveats are interleaved rather than separated into distinct sentences, costing readability for no gain in brevity.

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, one optional parameter, and a genuinely complex two-mode tool, the description supplies source, update frequency, coverage caveats, and intent examples — enough to call it correctly and to interpret empty results. It falls short only on not clarifying the shape of what comes back (e.g. whether mix and outages are returned together or which dominates).

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 description already explains accepted place forms (commune, beach, quarter, cirque, summit, or "-21.05, 55.22") and that empty means the whole island. The description only echoes this implicitly through its example queries, adding no format or behavioral detail 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 a concrete resource and scope: live electricity data for Réunion (total production, per-source share, renewable share) plus EDF outage notices by day/hour/sector. It explicitly separates itself from coupures_eau ("électricité, pas l'eau"). The only deduction is that it bundles two distinct capabilities (generation mix and outage notices) into one tool, which slightly muddies the headline purpose.

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 phrases for each capability ("d'où vient l'électricité ?", "quand recharger ma voiture électrique ?", "coupure EDF prévue dans ma commune ?") and names coupures_eau as the sibling to use for water outages. It does not mention bornes_recharge despite the EV-charging framing, leaving one obvious routing decision to inference.

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/open-world, and the description adds substantially beyond them: source provenance, coverage of municipal and OpenAgenda feeds, timezone (heure de La Réunion), inclusion of cancelled/reported/sold-out status, and the notable 'statut_d_apres' case where a local media outlet announces before the organiser. That last detail materially changes how an agent should interpret a status 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?

Front-loaded with the resource and scope, then sources, then record fields, then use cases — a logical order. It is dense with long enumerations of communes and source names that add modest value, keeping 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?

There is no output schema, but the description enumerates the returned fields (titre, date/heures, salle, commune, genre, prix, billetterie, statut) and the timezone, so an agent knows what to expect. Combined with all-default optional parameters and explicit empty-value behaviour, nothing needed to call it correctly 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 each parameter's meaning, examples and empty-value defaults are already documented in the schema. The description corroborates the genre/title-word duality of 'quoi' but adds no syntax or format detail the schema lacks, 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 specific resource (upcoming events in La Réunion) with the covered event types, the exact sources it aggregates, and the fields each record carries. No sibling tool overlaps with local event listings, and an agent can immediately tell what this returns.

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 closing 'Pour :' clause gives three concrete question shapes ('que faire ce week-end à Saint-Paul ?', 'concert ce soir ?', 'c'est quand la fête de l'ail ?') that map onto the parameters, which tells the agent exactly when this tool fits. It stops short of naming exclusions or alternatives (e.g. sport, calendrier, actualites), so it is clear context rather than a full routing rule.

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, and the description goes further by disclosing data provenance (DVF, ANIL, Arcep, PPR), temporal scope (5 years of sales), and spatial granularity differences (prices 'autour' and within 500 m, rents and fibre at commune level, PPR 'au point'). That granularity disclosure is genuinely useful for interpreting results. It stops short of covering failure modes (address not found, ambiguous lieu-dit) or response 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 main payload (what registers say about an address) is front-loaded, and the example queries at the end anchor usage. The middle is a dense single-sentence enumeration that borders on encyclopedic, but each item maps to a distinct returned data family, so little is 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?

With no output schema, the description carries the burden of describing return content and does so exhaustively — parcel, zoning, altitude, prices, rents, fibre, and four risk dimensions with their spatial scope. An agent knows what it will get back and at what granularity before calling.

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 address, lieu-dit and coordinate formats. The description adds a real constraint beyond the schema: the input must be a location in La Réunion (974), which tells the agent the tool is geographically scoped rather than globally open despite openWorldHint.

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 precisely what is returned for an address in La Réunion: cadastral parcel (section, number, area), PLU zone with constructibility classes (U, AU, A, N), ground altitude, DVF median prices, ANIL rents, Arcep fibre share, and PPR/natural-risk data. This enumerates the resource far more specifically than any sibling (meteo, transports, qualite_eau, etc.), making selection 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?

Three representative example questions ('cette parcelle est constructible ?', 'prix au m² des maisons à l'Hermitage ?', 'quels risques à cette adresse ?') make the intended use cases concrete and easy to match. There are no explicit exclusions or named alternatives, but no sibling tool covers cadastre/urbanisme/prix, so the risk of misrouting is low.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered by structured data. The description does add real behavioral context beyond that — data source (Météo-France stations), the 1900-onward coverage, the hourly-only-since-2000 limit, and the automatic aggregation (day-by-day up to two months, monthly/annual beyond) — but it does not describe the response shape or how comparisons to the 1991-2020 normal and records are presented. With annotations carrying safety, a 3 reflects solid but incomplete added 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?

It is a single dense paragraph that front-loads the core purpose and limits before the examples, and every sentence carries information. However, it runs long with no internal structure, mixing data coverage, granularity rules, examples, and sibling routing into one block, which makes scanning harder than 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?

There is no output schema, yet the description covers what data is returned, at what resolution, the historical coverage limits, how results are compared to station normals and records, and when to use the alternatives. Nothing needed to call it correctly 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 all five parameters (du, au, lieu, jours, detail) are already documented in the schema, giving a baseline of 3. The description's explanation of granularity degradation (day-by-day up to two months, then monthly or yearly) adds interpretive meaning for du/au ranges that the schema does not state, but it adds no syntax or format detail for lieu or jours beyond what the schema already provides.

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 verb+resource: measured past weather in Réunion, from Météo-France stations, from 1900 to yesterday. It lists the exact variables (rain, min/max temps, sunshine, gusts) and explicitly differentiates itself from siblings meteo_actuelle (now) and prevision_meteo (future), so no inference is needed.

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 the exact conditions for calling it (any past-weather question), three concrete example questions, and names the two alternatives with the conditions that select them: meteo_actuelle for now, prevision_meteo for upcoming days. Explicit when/when-not routing is fully present.

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/open-world safety, but the description adds substantive behavior: the times are computed by rundata rather than official SHOM predictions, accurate to ~15–20 min and 5 cm, and the tool degrades gracefully for far-away locations (returns nearest-gauge height with no times plus a link to official schedules). That degradation contract is exactly what an agent needs and is not in 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?

Dense but front-loaded: the payload comes first, then the accuracy caveat, then the geographic limit, then example queries. Some clauses (repeating the accuracy figures and the town list) could be trimmed, but nothing 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?

No output schema exists, and the description fully compensates by enumerating the returned fields (current height, trend, last high/low, next events over two days) and the fallback return shape for distant locations. Nothing an agent needs in order to call it or interpret the result 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 single `lieu` parameter is already documented, including the empty-means-both default. The description adds real value by explaining the nearest-gauge resolution behavior and listing the covered coastal towns (Le Port, La Possession, Saint-Paul, Saint-Gilles, Saint-Denis, Sainte-Marie, Sainte-Suzanne), which clarifies what a valid place string means.

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 (sea height measured every minute by SHOM tide gauges at Le Port and Sainte-Marie) and the exact payload (current level, rising/falling trend, last observed high/low, next highs/lows over two days). Distinguishes itself clearly from any sibling by naming the measurement source and the computed-vs-official-prediction distinction.

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 ("la marée monte ?", "c'est quand la marée basse demain ?", "niveau de la mer au Port ?") and explicit boundaries: computed hours are only valid within ~15 km of the two gauges, and beyond that horizon the agent should defer to SHOM. Both the when-to-use and when-not-to-use cases are spelled out.

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 meaningful behavior beyond that: measurements are dated, include the station name, distance and altitude, and produce a microclimate warning when the place has a different exposure. It does not discuss failure modes such as an unknown place name, which keeps it just short of 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 purpose is front-loaded, but the description is bloated with repeated example questions and a nearly complete English duplicate of the French text. The extra detail is useful but could be trimmed without losing selection value, so it sits at adequate rather than efficient.

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 tool with no output schema and rich annotations, the description covers what is measured, how the location is resolved, what extra recent-rain history is returned, caveats about microclimates, and when to use the forecast tool instead. An agent has everything needed to call it correctly and interpret the result.

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 single parameter is already well documented. The description still adds value by explaining the consequence of the parameter: the nearest representative station drives most measurements, radar rain is read at the exact place, and recent rain is read at the nearest rain gauge. That clarifies what 'lieu' actually controls beyond the schema's list of accepted place formats.

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: current measured weather in Réunion, listing the exact variables (temperature, rain, humidity, wind, pressure, present weather) and the station/radar sourcing logic. It explicitly distinguishes itself from the forecast sibling by saying to use prevision_meteo for later periods. An agent can tell exactly what this tool returns versus the alternatives.

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 when-to-use examples such as 'quel temps fait-il à Saint-Denis ?' and 'il pleut à Cilaos ?', plus an explicit exclusion: 'Pour plus tard (demain, ce soir, ce week-end), utiliser prevision_meteo.' The routing condition between this tool and the forecast sibling is unambiguous.

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, and the description adds real context beyond them: the output is a model forecast, not a measurement; every response is labelled 'prévision'; the model does not resolve the island's microclimates; and 'confidence' means agreement among the 51 ECMWF ensemble scenarios, not a probability. It omits explicit pagination or latency details, but for a read-only forecast tool that is a minor gap.

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?

Structure is strong: purpose and output contents come first, then trigger examples, conditional blocks, limitations, and the sibling handoff. However, it repeats itself in the French and English versions and spends roughly eight quoted example questions plus two block descriptions, which is heavy for a two-parameter 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?

No output schema exists, so the description carries the full burden of explaining the return values, and it does: per-day and per-3-hour granularity, the mer_de_nuages and ciel_de_nuit blocks with their time windows and altitude conditions, the confidence scale, and the forecast disclaimer. An agent knows what it will receive and how to interpret it.

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 meaning beyond it: it constrains the forecast horizon ('de ce soir à 7 jours') and thereby tells the agent that longer-range requests are out of scope, and it frames the altitude-dependent blocks that the 'lieu' parameter value implicitly selects. The free-text place and time examples largely duplicate 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 verb and resource (weather forecast from a numerical model, not a measurement) for Réunion Island, and enumerates exactly what is returned: sky conditions, min/max temperatures adjusted for the location's altitude, rain, wind and gusts, 3-hourly breakdowns, UV index, and per-day confidence. It explicitly distinguishes itself from the sibling meteo_actuelle ('pour le temps qu'il fait maintenant, utiliser meteo_actuelle') and implicitly from historique_meteo and 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 includes explicit when-to-use triggers with quoted user questions ('il va pleuvoir demain à Saint-Denis ?', 'quel temps ce week-end à Cilaos ?'), describes which conditional output blocks apply (mer_de_nuages only above 800 m, ciel_de_nuit everywhere) with their own trigger questions, and gives when-not-to-use routing: meteo_actuelle for current conditions, Météo-France's official vigilance for cyclones.

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 value beyond that: the data source, the numeric scale and its meaning, that both today and tomorrow are returned, and that omitting the location widens scope to the entire island.

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 scope, then the returned fields, then the example intents in a single dense paragraph with no filler. Slightly compressed by the run-on parentheticals, 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?

For a single optional parameter with no output schema, the description covers what is returned (ATMO index today and tomorrow plus the responsible pollutant) and the no-location default. Nothing essential for correct invocation is missing, though a note on data freshness or update cadence would have completed it.

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 description already explains accepted place forms (commune, plage, quartier, cirque, sommet, coordinates) and the empty-means-whole-island rule. The description's 'Sans lieu : toute l'île' merely restates that, 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 a specific resource (qualité de l'air à La Réunion) with scope (par commune), data source (Atmo Réunion), what is returned (indice ATMO du jour et du lendemain, polluant en cause) and the scale (1 bon à 6 extrêmement mauvais). This clearly separates it from weather siblings like meteo_actuelle or vigilance_meteo, which cover forecasts rather than air quality.

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 user questions («l'air est pollué à Saint-Louis ?», «je peux faire du sport dehors ?») that map intents to this tool, plus a fallback rule: with no location, coverage is the whole island. It does not explicitly exclude or name a sibling alternative, which keeps it at 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 declare readOnly/idempotent/non-destructive, so the description focuses on what the data means: latest analysis, compliance, and exceedances over a 6-month window, per sampling point. It adds a real behavioral constraint (shark-rule 300 m band, permitted zones, never declare safety) that no annotation carries. It stops short of describing result shape precisely, hence 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?

Front-loaded with scope and data source, then examples, then the safety caveat — a logical order in one paragraph. It is dense but the long list of beaches/basins is somewhat padded relative to the value it adds.

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 does the work of explaining what comes back (latest analysis, compliance status, germs/parameters over limits on 6 months, per sampling). Combined with zero required params and the safety caveat, an agent has enough to call correctly; only the exact field/response shape is 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 params (eau enum, lieu) are fully documented in the schema, so baseline is 3. The description reinforces 'réseau par réseau' and 'prélèvement par prélèvement' but adds no syntax or format guidance 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 specific verb+resource: ARS water-quality analyses for Réunion, split into drinking-water (network by network) and bathing water (beach/basin, sample by sample). It is immediately separable from siblings such as coupures_eau and temperature_mer, and even names coupures_eau as the place where 'do not drink' advisories live.

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 questions («l'eau du robinet est potable à Cilaos?», «on peut se baigner à l'Hermitage?») and an explicit hand-off rule to coupures_eau for in-force 'ne pas boire' advisories. It also states the negative usage rule: never assert a place is shark-free or risk-free, or that a zone is open today — defer to the on-site flag.

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 domain context: the source is the current prefectoral decree via VigiEau, the levels and affected water categories are enumerated, and the profile-dependent nature of the answer is explained. It stops short of describing data freshness or output structure.

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 a single dense sentence, followed by example queries that earn their place by clarifying trigger scenarios. It is efficient, though the long sentence packs several lists and could be slightly easier to scan.

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 lookup tool with a fully documented two-parameter schema and no output schema, the description covers domain, source, levels, profiles, and default behavior. It implies the returned content (level per commune plus prohibited uses) but could be slightly more explicit about the shape of the response.

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 schema already documents both parameters thoroughly, including location formats, the default whole-island behavior, and the profile enum. The description mostly restates those semantics (whole island when no location; default particulier) without adding new format or interpretation 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 states a specific resource (drought-related water restrictions in Réunion), the authoritative source, the levels tracked, the water sources covered, and the prohibited uses. An agent can distinguish it from sibling tools such as coupures_eau or qualite_eau by the drought-restriction framing.

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 clear example user queries that should trigger the tool, including location-specific and permission questions, and notes that omitting a location returns island-wide results. It does not explicitly say when to prefer a sibling tool like coupures_eau, but the context is clear enough.

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, open-world, non-destructive, so the safety profile is settled. The description adds genuinely non-schema behavior: this is a one-call fan-in across ~15 sources, place names are normalized to their commune, and gaps are surfaced in a non_inclus field naming the tool to call instead. It does not mention latency or partial-source failure, which matters for an aggregator, keeping 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 purpose is front-loaded in the opening clause and the trigger examples are last, which is the right order. The middle enumeration is long, but each listed domain is load-bearing since it tells the agent what it will and won't receive; only the fuel-price and pharmacy entries feel like padding.

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 must carry the return shape, and it does by listing the covered domains and the non_inclus convention. For an aggregation tool of this breadth it is adequately complete, though it says nothing about how partial failures or stale sub-sources are reported in the response.

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 is fully described there, including that a place is 'rapporté à sa commune' with examples. The description repeats that same mapping and adds category examples (plage, quartier, sommet), which is marginal value rather than new semantics. Baseline 3 is appropriate when the schema already does the work.

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 (a 'résumé du jour' for one Réunion commune) and enumerates exactly what it aggregates: measured weather, forecast, vigilance, sea, air quality, electricity, roads, news, water cuts, events, holidays, town hall status, market, déchèteries, fuel prices, on-call pharmacy. That enumeration uniquely distinguishes it from every sibling (meteo_actuelle, vigilance_meteo, actualites, coupures_eau, etc.), which each cover one slice.

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 :' clause gives concrete trigger phrasings ('quoi de neuf à Saint-Paul aujourd'hui ?', 'ma journée au Tampon') that map cleanly onto user intent, and the note that missing items appear in non_inclus with the tool to call routes the agent onward. However, it never states an explicit exclusion (e.g. 'not for historical data or a single-domain deep dive – prefer the dedicated tool'), so the when-not is left 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 a safe read-only, idempotent, open-world lookup, and the description adds substantive policy the schema cannot express: a closed trail is forbidden even with a trace, 'hors gestion ONF' does not mean open, always surface the avertissement field first, and always give the trace_gpx link. It also names a returned side field (aires_accueil).

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 facts (what it is, how to scope it, the closure warning) come first, but it is a dense run-on block built from semicolons and parentheticals that packs multiple ideas per sentence. Every clause is relevant, yet the lack of structure makes it slower to parse than needed.

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?

Four optional parameters, no output schema, and the description compensates by naming the fields an agent will receive (avertissement, trace_gpx, longueur, dénivelé, aires_accueil) and the interpretive rules for interpreting them. Nothing needed to call it correctly or report 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 goes further by explaining that longueur_min_km, longueur_max_km and denivele_max_m filter both itineraries and individual trails, and by clarifying that lieu accepts a trail, place, cirque or commune and that empty means the whole island.

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 and scope: ONF-maintained hiking trails and forest roads on Réunion, with open/closed status, closure cause, GPX traces, length and elevation. It also covers OSM itineraries and names the data sources (ONF, préfecture, IGN, OpenStreetMap), which no sibling tool touches.

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 routing cues: by trail name, around a place (Maïdo, Piton des Neiges), in a cirque (Mafate, Cilaos, Salazie), by commune, or with no location for all closed trails island-wide, plus three literal example questions. No sibling alternative is named, but none of the listed siblings overlaps this domain.

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 the read-only, idempotent, open-world profile, and the description adds genuinely useful behavior beyond them: daily re-verification, the fact that a site recovering drops out of the list, and the stated limitation that it never explains the cause. It does not describe pagination or list size.

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?

One dense paragraph that front-loads the definition before listing contents, caveats, and example phrasings. It is longer than typical but nearly every clause carries information; the enumerated examples could be trimmed without loss.

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, and the description compensates by spelling out the fields returned per site, the freshness guarantee, and the exclusion rule for recovered sites. For a one-optional-parameter read tool with existing annotations, nothing an agent needs 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 single parameter 'quoi' already documents that it accepts a site, commune, or theme and that empty means the whole list. The description adds no further detail about the filter's matching behavior, 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 (public sites in Réunion that are not responding right now), its refresh cadence, and exactly what each entry contains (since when, last observation in plain words, what is therefore missing on rundata.re). It is clearly distinguishable from every sibling, none of which report site availability.

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 (OVPF, volcano bulletin, Sudéau) make the intended trigger context unmistakable, and 'Ne dit jamais pourquoi un site se tait' sets an explicit boundary on what the tool will not answer. No sibling is named as an alternative, so it stops short of the top score.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is settled. The description adds that this is a self-describing catalogue including coverage gaps and recent changes, which tells the agent what kind of content to expect. It does not state response shape or size, but with no output schema this remains a minor gap for a zero-argument metadata read.

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?

Content is front-loaded with the resource definition, then examples, then the key routing rule. The first sentence is a long run-on enumeration of contents, dense but each item earns its place by telling the agent what it can look up.

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 zero-parameter, no-output-schema catalogue tool, the description is nearly sufficient: it covers contents, example intents, and the anti-hallucination use case. Only the freshness/authority of the "liste à jour" and the response format are left 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?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. It correctly implies a parameterless, whole-catalogue read.

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 returns: source organism, licence, attribution, coverage gaps, current tool list, recent additions, and aggregate counts (sources, producers, licences, stations, defibrillators, trails). This clearly separates it from the 28 domain-data siblings, which return measurements, not catalogue metadata.

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 three concrete trigger questions ("d'où viennent tes données ?", "combien de sources lit rundata.re ?", "c'est open data ?") and an explicit exclusion rule: call it before concluding that a tool or dataset does not exist. That is a real when-to-use / when-not-to-conclude directive, not just context.

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, and non-destructive behavior. The description adds useful behavioral context beyond annotations: municipal sports programs are returned as links without their content, and excluded topics produce an explanation rather than silence.

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 dense and somewhat long, but it is front-loaded with the core sport resource and stays focused on scope, exclusions, and examples. Most details earn their place for a broad multi-sport tool, though the single run-on sentence reduces scanability.

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 the tool’s breadth and lack of an output schema, the description is quite complete: it covers covered sports, excluded topics, link-only municipal documents, and representative query patterns. Minor gaps remain around return format and how multi-sport or multi-location results are combined.

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 parameter descriptions already explain lieu, quand, sport, enum values, and empty-value defaults. The main description reinforces some semantics with examples like VBSP = Volley-Ball de Saint-Pierre, but does not add much parameter guidance 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: upcoming matches, results, cancellations, standings, motorsport, Grand Raid, and municipal sports programs in La Réunion. It also explicitly says what is excluded (regattas and golf) and gives example user questions, so an agent can distinguish it from general news or events tools.

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 is clearly framed through example queries such as « match de hand ce week-end à Saint-Pierre ? » and « qui a gagné le Grand Raid ? ». Exclusions are explicit for regattas and golf, and football/basket are limited to news only, though no sibling tool alternatives are named.

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 and non-destructive, so safety is covered. The description adds genuine behavioral context beyond that: the measurement is satellite-derived and carries its own date and distance, the forecast is a 4-day model, and results arrive in two separate blocks.

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 the measured/forecast split are front-loaded before the quoted example queries. It is dense but every element (data source, horizon, output layout) earns its place; the three examples are slightly redundant but useful for intent matching.

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 fully by explaining that results come in two separate blocks and what each contains (measurement with date and distance; wave height, period, direction). An agent knows what to expect before calling.

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 (commune, beach, coordinates, empty = whole island) is fully documented there. The description only reinforces that the location should be coastal/beach-adjacent, adding marginal meaning 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 a specific resource (sea temperature and swell in La Réunion) and separates two distinct data products: satellite-MEASURED water temperature and model-FORECAST waves. That distinction alone differentiates it from siblings like maree, prevision_meteo and meteo_actuelle, which do not focus on sea state.

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 phrasings ('la mer est à combien à Saint-Leu ?', 'ça surfe à Saint-Pierre demain ?') make the triggering context very clear, and the measured-vs-forecast split tells the agent which question maps to which data. It stops short of explicitly naming when not to use it or which sibling to prefer for generic weather.

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 adds two genuinely useful facts not in the annotations: the data is live ("en direct") and the coverage is limited to Saint-Pierre, Saint-Louis and L'Étang-Salé. It says nothing about refresh cadence, outage behavior, or result ordering beyond "les plus proches".

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?

One dense sentence covers resource, coverage area, and payload, followed by three example phrasings introduced by "Pour :". Front-loading is good and there is little waste, though the sentence is long and the list of commune names inside parentheses adds bulk.

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 the return shape and does so — per-station bike count, free dock count, and nearest-station results. Combined with annotations and full schema coverage, an agent has enough to call it correctly. Only freshness/refresh and ordering details are 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 single optional `lieu` parameter is documented as accepting a station name, place, or commune with empty meaning the whole network. The description adds meaning beyond that by revealing the behavioral effect of the parameter — supplying a place yields the nearest stations, i.e. a proximity ranking rather than a strict filter.

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 (Altervélo self-service e-bikes) and states exactly what is returned per station: bikes available and free docks, plus the nearest stations to a place. It is far more specific than the title alone. It never distinguishes itself from the sibling `transports`, which an agent could plausibly confuse with bike-share availability, so it falls short of a 5.

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 questions ("il reste des vélos à la station IUT?", "où prendre un vélo près du front de mer", "je peux rendre mon vélo au pôle d'échanges") make the intended triggering contexts concrete, including both availability and return-capacity use cases. There is no explicit exclusion or named alternative, which keeps it out of 5 territory.

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 substantive behavioral context beyond that: the earthquake window is explicitly 30 days, results can be broken down by day and by area (under the volcano vs. elsewhere on the island), and the source is OVPF-IPGP. It stops short of describing freshness/update cadence or the response shape, hence 4.

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?

One dense front-loaded sentence delivers the resource and its full content inventory, followed by a short intent-mapping clause. The enumeration is long but each item is a distinct returned field an agent would otherwise have to guess at, so it earns its space; slight trimming of the ORSEC parenthetical would tighten it.

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 burden of explaining return content — and it does, listing eruption status, ORSEC level, access conditions, publications, and earthquake coverage. It leaves unanswered only secondary details like update frequency and exact formatting for the per-day earthquake breakdown.

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 and there is nothing for the description to compensate for. It correctly presents the tool as a parameter-free status query rather than suggesting any filtering options.

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 (Piton de la Fournaise volcano status and Réunion earthquakes) and enumerates the exact content returned: eruption status, ORSEC level, last eruption date, Enclos Fouqué access, OVPF publications, and the last 30 days of earthquakes. No sibling tool covers volcano or seismic data, so it is clearly distinguishable from the weather/water/traffic tools in the list.

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 closing clause maps concrete user intents to the tool ("le volcan est en éruption ?", "on peut monter au volcan ?", "il y a eu un séisme ?"), which is strong guidance for intent routing. It does not state exclusions or name alternatives, but no sibling overlaps this domain, 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.