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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds real value beyond them: it discloses the authoritative source, the fact that live open/closed status is returned, and the breadth of office types. It doesn't say whether results are paginated or how many offices come back, which keeps it off 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 the payload (addresses, hours, phones) and the source, then examples. It is somewhat long due to the four sample queries and the repeated English sentence, but nothing is redundant enough to distract an agent.

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 read-only lookup with full schema coverage and no output schema, the description supplies source, coverage, and example intents — everything needed to invoke it. Only the shape of the returned record (one office vs. a list) is left implicit, 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 description coverage is 100%, so both parameters are already fully documented in the schema, including the empty-lieu defaults to a whole-island tour. The description reinforces the semantics through the sample queries (place + service) but adds no syntax or formatting detail beyond the schema — the standard 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?

States a specific resource (public offices directory in Réunion) and enumerates the data returned: address, opening hours, live open/closed status, phone, website. It also names the source (annuaire officiel de service-public.fr) and the office categories covered, which clearly separates it from the weather/air-quality 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 :' block gives four concrete example queries that map directly onto realistic user intents, so an agent knows when to reach for it. It stops short of stating when NOT to use it or naming an alternative sibling, but the domain is distinct enough that little ambiguity remains.

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, openWorldHint and idempotentHint, so the safety profile is covered. The description adds domain-relevant behavior: the calendar is austral and diverges from the metropole, and an empty place yields an island-wide result. It says nothing about caching, data freshness, or how ambiguous place names are resolved — relevant given openWorldHint with free-text geocoding.

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 data inventory is front-loaded in the first sentence and the sample queries follow as retrieval aids. There is some redundancy — the trailing English sentence re-summarizes a subset of what the French already said — but the overall length is proportionate to four distinct data domains.

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, full schema coverage, and annotations, the main remaining burden is telling the agent what data comes back — which the description does by enumerating holidays, vacations, date, and sun times. It never indicates the response shape (e.g. list of upcoming holidays vs. a single date), a minor gap since 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 `lieu` parameter is already richly documented in the schema (commune, beach, cirque, summit, or 'lat, lon'; empty = whole island). The description only restates 'au lieu demandé', so it adds nothing beyond structured data — 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 concrete resources — school holidays for the Réunion academy (austral calendar, explicitly different from metropolitan France), public holidays including 20 December Fèt Kaf, today's date, and sunrise/sunset for a given place. It is clearly separable from every sibling tool, which are all weather/air/seismic/public-service 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?

The 'Pour : « c'est quand les vacances ? »…' list gives explicit natural-language triggers, including an edge case for sunrise at a specific summit (Maïdo), which directly maps to the `lieu` parameter. It stops short of naming when NOT to use it — e.g. that day-to-day weather belongs to meteo_actuelle/prevision_meteo rather than this tool.

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, openWorldHint), so the description's added context is what counts: it discloses the upstream data source (EDF), refresh cadence (every 5 min), geographic constraint (Réunion only), and that the payload spans both live production and a forward-looking grid signal. It does not describe the response shape, but no output schema exists so that gap is small.

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: what the data is, then the fields, then the forecast component, then use cases. The French/English duplication roughly doubles length, which is defensible for a bilingual catalog but is still repeated rather than additive; a shorter English gloss would have sufficed.

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 and no output schema, the description carries the burden of explaining what comes back, and it does: production total, per-source shares, renewable share, refresh interval, plus the coming-days grid outlook. An agent knows what it will get and whether it fits the user's question 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies a no-argument, snapshot-style call 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 precise resource and scope: real-time electricity production mix for Réunion Island (974), sourced from EDF, broken into per-filière shares plus renewable share and EDF's grid signal for the coming days. It is immediately distinguishable from every sibling (weather, air quality, volcano/seismic), none of which touch energy 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?

The 'Pour :' / example-question list ('d'où vient l'électricité ?', 'quelle part de renouvelable ?', 'quand recharger ma voiture ?', 'risque de délestage ?') gives concrete triggers for selecting this tool. It does not state exclusions or name alternatives, but no sibling overlaps, so the practical guidance is clear and complete 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 declare read-only, idempotent, open-world behavior, so the description need not restate safety. It adds substantive behavior: official registers as source, a 5-year DVF window, a 500 m hazard radius, and specific PPR/risk categories, though it does not discuss missing-data handling or response limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and information-dense, but the full bilingual duplication and long list of example questions make it longer than necessary. The content largely earns its place, so it is efficient but not maximally concise.

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 lookup with no output schema and only annotations for read-only/idempotent behavior, the description covers the domains, temporal and spatial scope, and input format well. It leaves out return shape, failure/missing-data behavior, and source-freshness caveats, so it is not fully complete.

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 address, lieu-dit, or 'lat, lon' input. The description adds no additional syntax, format, or validation 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—an address-level fact sheet combining cadastral parcel, PLU zoning, altitude, DVF prices, and hazards for Réunion—and enumerates the exact outputs. That is far more than the name/title and lets an agent distinguish this from the weather/service siblings, which cover none of these domains.

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 question examples ('cette parcelle est constructible ?', 'prix au m² des maisons à l'Hermitage ?') that show when to invoke it, which is strong context. It does not state when not to use it or name alternatives, so it stops 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 declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds real behavioral context beyond them: it returns dated measurements bundled with the station name, its distance and altitude, plus a microclimate warning when the requested place differs (altitude, windward/leeward slope), and it explains the radar fallback where no rain gauge exists. Minor gaps remain (no note on resolution limits or what happens for unknown place names), 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 measured-now purpose and the sibling routing are front-loaded, and every clause (station metadata, radar fallback, microclimate warning) earns its place. It is somewhat long and the French and English blocks partially restate each other, which is the only waste.

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 return values — and it does: dated measurements, station identity, distance, altitude, and conditional microclimate warnings, plus the radar-rain supplement. For a single-parameter read tool this is fully sufficient to call and interpret.

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 parameter at 100% schema description coverage, the schema already documents free-text place names, coordinate format, and that empty returns the whole island. The description only reinforces the notion of 'the most representative station for the requested place' without adding syntax or edge-case handling 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?

States a specific verb+resource: current MEASURED weather at Réunion, listing concretely what is reported (temperature, rain over 6 min/1 h, humidity, wind/gusts, pressure, present weather) and the station-selection logic plus radar rain at the exact spot. It explicitly contrasts itself with prevision_meteo, so an agent can separate it from the forecast sibling without opening either 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 natural-language triggers (« quel temps fait-il à Saint-Denis ? », « il pleut à Cilaos ? ») and an explicit exclusion plus alternative: for later today/this evening/this weekend use prevision_meteo. The when-to-use and when-not-to-use conditions are both 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?

Beyond the annotations (readOnly/openWorld/idempotent), it discloses that output is probabilistic model data, that every answer is labelled 'prévision', that microclimates are not resolved, and that cyclone queries should be deflected to official vigilance. Those are exactly the caveats an agent needs to phrase results safely.

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 distinction (forecast not measurement) and horizon, then examples, then limits and routing. The full bilingual duplication roughly doubles length and repeats example phrasings already present in the parameter schemas, which is mild waste but keeps both audiences served.

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 optional free-text parameters and no output schema, the description still specifies what variables come back, the granularity (per day and 3-hour blocks), the temporal horizon and the labelling/limitation caveats. Nothing an agent needs in order to call or present 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% and both parameters already document free-text place formats, coordinate syntax and empty-means-default behaviour. The description only implies the place must be in Réunion and the window is tonight-to-7-days, adding 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?

States the specific resource (weather forecast for a place in Réunion), the source (numerical model, not a measurement), the horizon (tonight to 7 days) and the returned variables (sky, min/max temperature adjusted to altitude, rain, wind, gusts, per day and 3-hour blocks). It explicitly contrasts itself with meteo_actuelle, so an agent can separate it from the sibling at a glance.

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 ('will it rain tomorrow in Saint-Denis?') and an explicit negative route: use meteo_actuelle for current conditions, and refer to Météo-France vigilance for cyclones. Both the when-to-use and the 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 readOnly/idempotent/openWorld, so the safety profile is covered; the description adds meaningful context beyond that — the index scale, the responsible pollutants, the data source, and that results cover today and tomorrow. It does not discuss caching or freshness latency, 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 core capability is front-loaded in the first clause, and the example phrasings are genuinely useful for matching user intent. The bilingual tail is economical, though the run-on enumeration of place types makes it slightly denser 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?

With a single fully-documented optional parameter and no output schema, the description does the needed work by explaining what the index values mean (1 bon à 6 extrêmement mauvais) and what pollutants are reported. Missing only an explicit note on output shape or update cadence.

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 already well documented with examples. The description reinforces this by stating that an empty value means the whole island, adding slight value over the schema rather than repeating it.

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 (indice ATMO par commune à La Réunion), the temporal scope (jour et lendemain), the data producer (Atmo Réunion), the scale (1–6) and the pollutant breakdown. An agent can immediately distinguish it from weather siblings like meteo_actuelle or prevision_meteo.

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

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

Concrete example queries (« l'air est pollué à Saint-Louis ? », « je peux faire du sport dehors ? ») make the intended use clear, and it states the default behavior when no location is given ('Sans lieu : toute l'île'). It does not explicitly say when to prefer this over vigilance_meteo or prevision_meteo, so it stops 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 declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so safety is covered. The description adds that the content is a static inventory of sources plus their coverage status, which is useful, but it says nothing about output shape or whether 'non couvert' is listed per dataset.

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?

Two short clauses, front-loaded with the resource and its contents. The French/English duplication doubles length but serves a genuine bilingual audience and adds no new claims.

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 read-only profile, the description states enough: what the listing contains (organism, licence, attribution, coverage gaps). Only the return structure is unstated, a minor omission for a static informational 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 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 (les sources de données du serveur) and specifies the exact content: organisme, licence, attribution à citer, and couverture actuelle. It is clearly a metadata/about tool, which separates it in spirit from the data-returning siblings, though it never explicitly states that 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?

The phrase 'et ce qui est couvert ou pas encore' implies the tool is the place to check licensing and coverage, which hints at when to use it. However, there is no explicit instruction such as 'call this before reusing data' and no reference to any sibling tool.

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 (readOnly, idempotent, openWorld), and the description adds real context beyond them: it reports the source (buoy vs satellite), the measurement date and the distance — details an agent needs to judge freshness and trustworthiness. It doesn't address what happens when no measurement exists.

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 claim and sample queries are front-loaded and the return content is stated compactly. The full English restatement doubles the length for little added information, though it does serve bilingual routing.

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 read tool with no output schema, the description supplies what the schema and annotations cannot: the nature of the returned measurement and its provenance fields. Only empty-result or no-coverage behavior is 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?

Schema coverage is 100% and the single 'lieu' parameter is fully documented in the schema, so the baseline of 3 applies. The description's sample place names ('Saint-Leu', 'l'Hermitage') echo the schema's own examples rather than adding new syntax 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 verb and resource ('Température de l'eau de mer MESURÉE à La Réunion') and scopes it to beaches or coastal places, which separates it from meteo_actuelle and prevision_meteo among the siblings. The capitalized MESURÉE plus the sample questions make the intent unmistakable.

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 natural-language example queries plus 'Renvoie la dernière mesure disponible' give a clear picture of when this tool applies. It never names an alternative sibling or states when not to use it, so it stops short of the 5 bar.

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 lower, and the description adds real context: the earthquake window is fixed at the last 30 days, and the payload reflects the latest OVPF publications and the most recent eruption date. It doesn't state refresh cadence or source authority beyond naming OVPF-IPGP, which would have pushed it higher.

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 enumerated scope is front-loaded and each listed field earns its place by telling the agent what comes back. The trailing bilingual restatement is partly redundant with the French text, and the run-on first sentence packs a lot into one clause chain.

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 and no parameters, the description carries the whole burden and does so by enumerating the returned fields plus their temporal scope (30 days of seismicity, last eruption date). An agent knows what it will get and when it applies without opening anything else.

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; there is nothing for the description to disambiguate. It correctly signals a single-shot, no-argument 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 concrete resource (Piton de la Fournaise volcano status + Réunion earthquakes) and enumerates exactly what it covers: eruption state, ORSEC alert level, last eruption date, Enclos Fouqué access, OVPF publications, and 30-day seismicity. This is clearly distinguishable from weather/air-quality siblings such as meteo_actuelle 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?

The example user questions ("le volcan est en éruption ?", "on peut monter au volcan ?", "il y a eu un séisme ?") give a concrete trigger set for when to call it. What's missing is an explicit boundary against the closest siblings — e.g. whether seismic/alert info should ever be sought from vigilance_meteo instead.

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