Skip to main content
Glama

Constat Auto — Constat amiable

by io.github.Doran56

constat_renseigner

DestructiveIdempotent

Enregistre ou met à jour les informations du constat. Appelez-le autant de fois que nécessaire, par petits groupes de champs, au fil de la conversation. Seuls les champs fournis sont modifiés. N'inventez jamais une valeur : un champ inconnu doit rester absent. Attention : modifier un constat déjà signé invalide les signatures et oblige à solliciter de nouveau les conducteurs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dossierYesIdentifiant du dossier renvoyé par constat_demarrer.
accidentNoCirconstances de temps et de lieu de l'accident.
conducteur_aNoVéhicule A : celui de la personne à qui vous parlez. Ne remplir que les champs connus, et n'inventer aucune valeur — un champ inconnu doit rester absent.
conducteur_bNoVéhicule B : l'autre véhicule impliqué. Mêmes champs que conducteur_a.
destinataireNoAssureur ou courtier à qui le constat signé sera transmis.
observations_aNoObservations du conducteur A, dans ses propres mots.
observations_bNoObservations du conducteur B, si elles ont été recueillies.
circonstances_aNoNuméros des cases de circonstances cochées pour A, de 1 à 17. Appeler constat_circonstances pour la liste officielle et relire les cases au conducteur. Si aucune ne correspond, ne pas en forcer une : utiliser aucune_circonstance_a.
circonstances_bNoNuméros des cases de circonstances cochées pour B, de 1 à 17. Si aucune ne correspond, utiliser aucune_circonstance_b.
conducteur_b_absentNotrue si le second conducteur n'a pas pu être identifié (délit de fuite, véhicule stationné sans propriétaire présent). Le constat est alors une déclaration unilatérale.
aucune_circonstance_aNotrue si le conducteur A déclare qu'aucune des 17 circonstances ne s'applique (ex. véhicule régulièrement stationné, heurté par l'arrière). Exclusif de circonstances_a : cocher une case inexacte pour pouvoir avancer fausserait l'analyse de responsabilité. Exige alors une explication factuelle dans observations_a.
aucune_circonstance_bNoÉquivalent pour le conducteur B, avec observations_b.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed15 schema fields changed
    • addedInput schema / properties / accident / properties / degats_materiels_autres_description
      Added value: +{
+  "description": "Nature et propriétaire des biens endommagés autres que les deux véhicules (case 4 du modèle européen). « Oui » sans cette précision n'est exploitable par personne.",
+  "type": "string"
+}
    • addedInput schema / properties / aucune_circonstance_a
      Added value: +{
+  "description": "true si le conducteur A déclare qu'aucune des 17 circonstances ne s'applique (ex. véhicule régulièrement stationné, heurté par l'arrière). Exclusif de circonstances_a : cocher une case inexacte pour pouvoir avancer fausserait l'analyse de responsabilité. Exige alors une explication factuelle dans observations_a.",
+  "type": "boolean"
+}
    • addedInput schema / properties / aucune_circonstance_b
      Added value: +{
+  "description": "Équivalent pour le conducteur B, avec observations_b.",
+  "type": "boolean"
+}
    • changedInput schema / properties / circonstances_a / description
      Previous value: -"Numéros des cases de circonstances cochées pour A, de 1 à 17. Appeler constat_circonstances pour la liste officielle et relire les cases au conducteur."New value: +"Numéros des cases de circonstances cochées pour A, de 1 à 17. Appeler constat_circonstances pour la liste officielle et relire les cases au conducteur. Si aucune ne correspond, ne pas en forcer une : utiliser aucune_circonstance_a."
    • changedInput schema / properties / circonstances_b / description
      Previous value: -"Numéros des cases de circonstances cochées pour B, de 1 à 17."New value: +"Numéros des cases de circonstances cochées pour B, de 1 à 17. Si aucune ne correspond, utiliser aucune_circonstance_b."
    • addedInput schema / properties / conducteur_a / properties / conducteur_adresse
      Added value: +{
+  "description": "Adresse du conducteur s'il diffère de l'assuré (prêt de volant, véhicule de société, location).",
+  "type": "string"
+}
    • addedInput schema / properties / conducteur_a / properties / permis_valable_jusquau
      Added value: +{
+  "description": "Fin de validité du permis de conduire, au format AAAA-MM-JJ.",
+  "type": "string"
+}
    • addedInput schema / properties / conducteur_a / properties / point_de_choc_initial
      Added value: +{
+  "description": "Point de choc INITIAL, là où le contact a commencé (case 10 du modèle européen, la flèche). À ne pas confondre avec zones_endommagees, qui décrit les dégâts apparents (case 11).",
+  "enum": [
+    "av",
+    "avg",
+    "avd",
+    "cg",
+    "cd",
+    "ar",
+    "arg",
+    "ard"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / conducteur_a / properties / remorque_immatriculation
      Added value: +{
+  "description": "Immatriculation de la remorque ou caravane attelée, le cas échéant (case 8 du modèle européen).",
+  "type": "string"
+}
    • addedInput schema / properties / conducteur_a / properties / remorque_pays
      Added value: +{
+  "description": "Pays d'immatriculation de la remorque. Par défaut celui du véhicule.",
+  "type": "string"
+}
    • addedInput schema / properties / conducteur_b / properties / conducteur_adresse
      Added value: +{
+  "description": "Adresse du conducteur s'il diffère de l'assuré (prêt de volant, véhicule de société, location).",
+  "type": "string"
+}
    • addedInput schema / properties / conducteur_b / properties / permis_valable_jusquau
      Added value: +{
+  "description": "Fin de validité du permis de conduire, au format AAAA-MM-JJ.",
+  "type": "string"
+}
    • addedInput schema / properties / conducteur_b / properties / point_de_choc_initial
      Added value: +{
+  "description": "Point de choc INITIAL, là où le contact a commencé (case 10 du modèle européen, la flèche). À ne pas confondre avec zones_endommagees, qui décrit les dégâts apparents (case 11).",
+  "enum": [
+    "av",
+    "avg",
+    "avd",
+    "cg",
+    "cd",
+    "ar",
+    "arg",
+    "ard"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / conducteur_b / properties / remorque_immatriculation
      Added value: +{
+  "description": "Immatriculation de la remorque ou caravane attelée, le cas échéant (case 8 du modèle européen).",
+  "type": "string"
+}
    • addedInput schema / properties / conducteur_b / properties / remorque_pays
      Added value: +{
+  "description": "Pays d'immatriculation de la remorque. Par défaut celui du véhicule.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses a critical consequence beyond annotations: modifying a signed constat invalidates signatures and requires re-collecting driver consent. It also explains partial-update behavior and the no-invention rule. Annotations already mark destructiveHint/readOnly false, and the description adds what is actually affected.

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

Conciseness5/5

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

Four short sentences lead with the purpose, then give usage, partial-update semantics, and the signature warning. No filler; each sentence adds operational information.

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 complex tool with 12 top-level parameters, nested objects, and no output schema, the description covers the operational essentials: incremental updates, preservation of omitted fields, anti-hallucination rule, and the signature-invalidation side effect. The remaining details live in the unusually rich schema.

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%, so the per-field descriptions carry most of the burden. The description adds valuable global parameter semantics—only supplied fields are modified and unknown values must be omitted—which are not visible in the schema itself.

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 action on a clear resource: 'Enregistre ou met à jour les informations du constat.' It also signals its role as the incremental data-entry tool ('Appelez-le autant de fois que nécessaire'), which distinguishes it from siblings like constat_demarrer, constat_finaliser, and constat_signatures.

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?

Gives explicit usage guidance: call repeatedly, in small field groups, during the conversation, and only provided fields are changed. It does not explicitly name when-not-to-use alternatives, 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.

All Constat Auto — Constat amiable toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each constat_* tool corresponds to a distinct phase of the accident statement workflow—starting, filling, sketching, signing, status checking, finalizing, canceling—with no two tools overlapping in purpose. The two guide-related tools (search, fetch) are clearly separate from the workflow tools.

Naming Consistency3/5

The constat_ prefix provides a recognizable pattern, but the suffix alternates between verbs (demarrer, renseigner, finaliser, annuler) and nouns (circonstances, croquis, signatures, statut, assureurs). Additionally, the two guide tools (fetch, search) break the pattern entirely, mixing languages and conventions.

Tool Count5/5

With 11 tools, the server is well-scoped for its purpose: each tool serves a clear step in the constat process and the two guide tools complement the primary workflow without redundancy. The count is within the ideal 3–15 range and does not feel heavy or thin.

Completeness4/5

The workflow is well covered: start, fill, sketch, sign, monitor status, finalize, and cancel. A minor gap is the lack of a dedicated 'get full constat contents' tool (statut only shows missing fields and signature state), but the core lifecycle is otherwise complete.

Resources