Skip to main content
Glama

rundata.re · La Réunion en direct

Coupures d'eau et eau non potable à La Réunion

coupures_eau
Read-only

Avis des distributeurs d'eau de La Réunion (974) : coupures pour travaux ou lavage de réservoir (heures, rues concernées), pannes, et avis « ne pas boire l'eau » quand l'eau n'est plus potable. Saint-Denis (Dionéo), La Possession, Saint-Paul et Les Trois-Bassins (La Créole), Sainte-Marie (communiqués de CISE Réunion publiés par la ville), Saint-Leu (avis publiés par la commune, en court extrait), les communes de l'Est (Saint-André, Bras-Panon, Saint-Benoît, La Plaine-des-Palmistes, Sainte-Rose, Salazie) et runéo. Pour : « coupure d'eau à Saint-Denis ? », « l'eau est potable à la Plaine-des-Palmistes ? », « quand revient l'eau ? ». Sans lieu : tous les avis récents. Un avis « ne pas boire » se dit d'abord ; la conformité des analyses de l'ARS est dans qualite_eau. Quand secteurs_complets vaut false, la liste des rues de l'avis n'a pas été lue en entier : ne jamais en conclure qu'une rue ou un quartier n'est pas concerné, donner le lien de l'avis complet. Même quand la liste est complète, dire « cette rue n'est pas dans la liste de l'avis », jamais « pas de coupure chez vous ».

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "coupures_eau"
  }
}

Input Schema

NameRequiredDescriptionDefault
lieuNoLieu à La Réunion : commune, plage, quartier, cirque, sommet, ou coordonnées « -21.05, 55.22 ». Vide = toute l'île.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / lieu / description
      Previous value: -"Lieu à La Réunion, en texte libre : commune (« Saint-Paul »), plage (« plage de l'Hermitage », « Boucan Canot »), quartier, cirque (« Cilaos », « Mafate »), sommet (« Maïdo », « volcan »), ou coordonnées « -21.05, 55.22 ». Vide = tour de l'île. / Place in Réunion, free text or 'lat, lon'; empty = whole island."New value: +"Lieu à La Réunion : commune, plage, quartier, cirque, sommet, ou coordonnées « -21.05, 55.22 ». Vide = toute l'île."
  2. Changed1 schema field changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  3. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the read-only, open-world, non-destructive profile, so the bar is lower, yet the description adds real behavior: 'ne pas boire' advisories are reported first, and the secteurs_complets flag governs whether the street list was fully read. It also prescribes safe phrasing when data is incomplete, which is genuine operational context beyond the annotations.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is a single dense block, including an exhaustive enumeration of eastern communes and six operator names that could be compressed. The cautionary sentences about incomplete street lists earn their place; the roster of communes is heavier than needed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only tool with no output schema, this covers what an agent needs: where the data comes from, how to query without a location, how to interpret the secteurs_complets output flag, and how to phrase results safely. The cross-reference to qualite_eau closes the main scope boundary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema coverage, so the schema already documents it, including the empty-means-whole-island default. The description reinforces this with example locations and operators, but adds no format or interpretation detail the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and scope: advisories from Réunion water distributors about outages for works or tank washing, breakdowns, and 'do not drink' notices, with named operators and communes. An agent can distinguish this from generic news or weather siblings 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.

Usage Guidelines4/5

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

It gives concrete trigger phrasings ('coupure d'eau à Saint-Denis ?', 'quand revient l'eau ?'), explains the no-location behavior (all recent advisories), and explicitly routes ARS analysis conformity to the sibling qualite_eau. It stops short of distinguishing this from restrictions_eau or crues_rivieres, which are plausible confusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.