Skip to main content
Glama
rundata-re

rundata · La Réunion 974 en direct

by rundata-re
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Donner un avis à rundata.re

donner_avis

Send feedback to rundata.re about missing data, a wrong or outdated value, a suggestion, or thanks when a tool found nothing or returned incorrect results.

Instructions

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 sans attendre qu'on le demande quand un outil n'a pas trouvé ce que l'utilisateur cherchait, a renvoyé quelque chose de faux ou d'incomplet, ou quand l'utilisateur exprime un souhait ou une plainte sur ces données, ou dit après coup qu'une information de rundata.re était fausse : c'est ainsi que le service s'améliore. Écrire un message court et concret (quel outil, quel lieu, ce qui manquait). Ne mettre aucune donnée personnelle ; si le contenu touche la personne (son adresse, sa santé…), lui demander d'abord son accord. Les avis sont lus par une personne, sans réponse directe. / Send feedback to rundata.re: missing data, a wrong value, a suggestion or thanks. Use it when a tool lacked data or erred, or the user voiced a wish or complaint; no personal data.

Input Schema

NameRequiredDescriptionDefault
lieuNoLe lieu concerné (« Cilaos », « plage de l'Hermitage »). / The place concerned.
typeYes« manque » (donnée absente), « erreur » (valeur fausse ou périmée), « suggestion », « bravo ». / missing, wrong, suggestion, praise.
outilNoL'outil concerné (« meteo_actuelle », « transports »…). / The tool concerned.
messageYesL'avis, en quelques phrases (1000 caractères au plus), sans donnée personnelle. / The feedback, no personal data.
question_utilisateurNoLa question de l'utilisateur, reformulée sans rien de personnel. / The user's question, paraphrased, nothing personal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.128.0

TDQS

A4.8/5.0
Behavior5/5

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

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

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

Conciseness4/5

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

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

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

Completeness5/5

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

For a write-style feedback tool with no output schema, the description covers purpose, triggers, message content, privacy constraints and what happens to the submission. An agent has everything needed to decide and to call it correctly.

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

Parameters4/5

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

Schema coverage is 100% and the enum values are documented, so the baseline is 3; the description goes slightly further by prescribing message content ('quel outil, quel lieu, ce qui manquait'), which ties the 'outil', 'lieu' and 'message' fields together in practice.

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

Purpose5/5

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

States a specific verb and resource ('Transmet à rundata.re ... un avis sur ses données') and enumerates the four feedback categories with their meanings. None of the 28 sibling tools share this purpose — all others read municipal data, so the distinction is unambiguous.

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

Usage Guidelines5/5

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

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

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

Deploy Server

Other Tools