État d'avancement du dossier : informations manquantes, état des signatures, et si le constat a été envoyé. Lecture seule. À appeler avant de conclure quoi que ce soit sur l'avancement, notamment pour savoir si le conducteur B a renseigné sa partie.
| Name | Required | Description | Default |
|---|---|---|---|
| dossier | Yes | Identifiant du dossier renvoyé par constat_demarrer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Lecture seule' (read-only), but the annotations declare readOnlyHint: false, which implies the tool may modify state. This is a direct contradiction. No other behavioral context is provided to compensate.
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 concise, with two sentences that communicate the purpose, key return values, and usage context. It is front-loaded with the main purpose and avoids unnecessary detail.
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 simple status tool with one parameter and no output schema, the description covers the main return values and usage timing. It lacks details about potential errors or edge cases, but these are not critical given the tool's simplicity.
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 input schema has 100% coverage for the single parameter 'dossier', which is described as the identifier returned by constat_demarrer. The tool description adds no additional parameter meaning beyond this, so a baseline score of 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?
The description clearly states the tool's purpose: providing the progress status of the file, including missing information, signature status, and whether the constat was sent. It uses a clear resource (the dossier) and distinguishes it from sibling tools that focus on individual aspects.
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 description explicitly says 'À appeler avant de conclure quoi que ce soit sur l'avancement', giving clear context on when to use it. It also mentions a specific use case (checking if driver B filled their part), but does not discuss when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
