Fetches details for a project grouping by its account ID; pass the ID from the project list and optionally filter by dossier.
Détail d'un chantier (ancien regroupement) par son numéro dans le
compte (le champ id renvoyé par la liste des chantiers).
| Name | Required | Description | Default |
|---|---|---|---|
| dossier | No | ||
| chantier_id | Yes |
Changes observed during successful MCP inspections.
v0.2.1Input schema / properties / dossierAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Dossier"
+}v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read ('Détail'), but never states permissions, whether `dossier` scopes/filters the lookup, what happens if the id is invalid, or what the returned detail contains. Only the legacy naming note ('ancien regroupement') is added.
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?
A single front-loaded sentence with the resource and lookup key stated first. Efficient, though the parenthetical legacy note is marginally useful rather than essential.
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 detail tool with no output schema, no annotations, and 0% schema coverage, the description should convey what the detail response includes and how `dossier` affects it. It references the id source but omits return content and one parameter entirely, leaving real gaps.
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?
Schema description coverage is 0%, so the description must compensate. It clarifies `chantier_id` (the `id` field returned by the chantier list), but says nothing about the `dossier` parameter — its meaning, default, or whether it filters the result — leaving one of two parameters undocumented everywhere.
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?
States a specific verb+resource: retrieves the detail of a single chantier identified by its account number. It implicitly contrasts with the list tool 'chantiers' by explaining that the id comes from that list, so an agent can distinguish single-fetch from list. It doesn't name siblings explicitly, so not a 5.
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 hints at a workflow — get the `id` from 'chantiers' first — which implies when this tool is used. However, it gives no explicit when-to-use vs when-not, no alternatives (e.g., marge_chantier), and no prerequisites beyond the id source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.