rundata.re · La Réunion en direct

Donner un avis à rundata.re

donner_avis

Transmet à rundata.re, qui tient ce serveur, un avis sur ses données : une donnée qui manque (« manque »), une valeur qui semble fausse ou périmée (« erreur »), une idée (« suggestion »), ou un remerciement (« bravo »). L'appeler quand l'utilisateur signale une donnée qui manque ou une information fausse, ou exprime un souhait ou une plainte sur ces données. Quand un outil n'a pas trouvé ce qu'il cherchait ou s'est trompé, lui proposer de le signaler, et ne l'appeler qu'avec son accord. Écrire un message court et concret (quel outil, quel lieu, ce qui manquait), sans recopier la conversation et sans aucune donnée personnelle. Les avis sont lus par une personne, sans réponse directe.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "type": "<type>",
      "message": "<message>"
    },
    "name": "donner_avis"
  }
}

Input Schema

Name	Required	Description
`lieu`	No	Le lieu concerné (« Cilaos », « plage de l'Hermitage »).
`type`	Yes
`outil`	No	L'outil concerné (« meteo_actuelle », « transports »…).
`besoin`	No	Le besoin résumé en quelques mots (« la pluie à Marla ce matin »), 160 caractères au plus : jamais le texte de la conversation, rien de personnel.
`message`	Yes	L'avis, en quelques phrases (1000 caractères au plus), sans donnée personnelle.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

removedInput schema / properties / type / description

Removed value: -"« manque » (donnée absente), « erreur » (valeur fausse ou périmée), « suggestion », « bravo »."

Changed2 schema fields changedOct 29, 2026

addedInput schema / properties / besoin

Added value: +{
+  "description": "Le besoin résumé en quelques mots (« la pluie à Marla ce matin »), 160 caractères au plus : jamais le texte de la conversation, rien de personnel.",
+  "maxLength": 160,
+  "type": "string"
+}

removedInput schema / properties / question_utilisateur

Removed value: -{
-  "description": "La question de l'utilisateur, reformulée sans rien de personnel.",
-  "maxLength": 300,
-  "type": "string"
-}

Changed5 schema fields changedOct 26, 2026

changedInput schema / properties / lieu / description

Previous value: -"Le lieu concerné (« Cilaos », « plage de l'Hermitage »). / The place concerned."New value: +"Le lieu concerné (« Cilaos », « plage de l'Hermitage »)."

changedInput schema / properties / message / description

Previous value: -"L'avis, en quelques phrases (1000 caractères au plus), sans donnée personnelle. / The feedback, no personal data."New value: +"L'avis, en quelques phrases (1000 caractères au plus), sans donnée personnelle."

changedInput schema / properties / outil / description

Previous value: -"L'outil concerné (« meteo_actuelle », « transports »…). / The tool concerned."New value: +"L'outil concerné (« meteo_actuelle », « transports »…)."

changedInput schema / properties / question_utilisateur / description

Previous value: -"La question de l'utilisateur, reformulée sans rien de personnel. / The user's question, paraphrased, nothing personal."New value: +"La question de l'utilisateur, reformulée sans rien de personnel."

changedInput schema / properties / type / description

Previous value: -"« manque » (donnée absente), « erreur » (valeur fausse ou périmée), « suggestion », « bravo ». / missing, wrong, suggestion, praise."New value: +"« manque » (donnée absente), « erreur » (valeur fausse ou périmée), « suggestion », « bravo »."

Changed1 schema field changedOct 26, 2026
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
AddedOct 24, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so safety is largely covered; the description still adds real context by stating the feedback goes to an outside party that runs the server and is read by a human with no direct reply. It also constrains content (short, concrete, no conversation transcript, no personal data), though it says nothing about volume limits or what the caller receives.

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

Conciseness4/5

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

Five sentences, all functional, with the purpose and the four categories front-loaded before the usage and content rules. There is slight repetition of the 'no personal data' constraint across the description and the schema, but nothing wasteful enough to trim.

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 five-parameter write tool with no output schema, the description covers what it does, when to invoke it, the consent requirement, how to phrase the payload, and what happens downstream. An agent has everything needed to call it correctly and to decide whether to offer it at all.

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?

Schema description coverage is 80%, so the schema already explains lieu, outil, besoin and message. The description adds guidance that maps onto those fields — name the tool and place, keep it short, never paste the conversation — but it gives no field-by-field detail such as how 'type' should be chosen, leaving the schema to do the heavy lifting.

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 opens with a specific verb and resource — "Transmet à rundata.re ... un avis sur ses données" — and enumerates the four accepted categories (manque, erreur, suggestion, bravo) with a parenthetical gloss for each. That is enough to separate it from every sibling, all of which are data-retrieval tools.

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

Usage Guidelines5/5

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

It names the triggering conditions explicitly (user reports missing data or wrong info, expresses a wish or complaint) and a second case (a tool failed to find something or erred), and it imposes a consent gate: propose it to the user and call only with their agreement. When-to-use and a when-not condition are both present.

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

All rundata.re · La Réunion en direct tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.