Feuilles de temps d'une ressource

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), lowering the bar for the description. The description adds useful behavioral context beyond those annotations: the default month/year behavior ('défaut : mois courant') and the return content ('Liste des feuilles de temps ... avec jours/heures et statut'). This exceeds what the annotations provide, although it does not mention pagination or error handling, which are minor for a read-only list operation.

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 compact and front-loaded: the first sentence states the core action and the optional filter; the second sentence provides when-to-use guidance with explicit alternatives; the third sentence describes the return value. Every sentence contributes distinct information, with no redundancy or filler.

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 tool with 3 parameters, one required, no output schema, and read-only semantics, the description is complete. It covers the purpose, the exact use case, how it differs from analogous tools, the default behavior, and the shape of the returned data. Nothing an agent needs to invoke this tool correctly is missing.

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 100%: all three parameters (resourceId, year, month) have descriptive entries in the schema, including the default behavior for omitted month/year. The description repeats the defaults but does not add any additional semantics beyond the schema. Per the calibration baseline, when schema coverage is high and the description adds no new parameter meaning, a 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 states a specific verb ('Récupère'), a resource ('feuilles de temps d'une ressource'), and the input ('par son ID'), with optional month/year filter. It also explicitly names the sibling alternatives it is not (boond_timesheets_get, boond_timesheets_search), allowing an agent to select this tool without opening schemas. This is a clear, differentiated purpose.

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 states when to use this tool ('pour lister les CRA d'une ressource sur un mois donné, sans connaître leurs ID') and when to prefer alternatives ('Plutôt que : ... boond_timesheets_get ... boond_timesheets_search ...'). It leaves no ambiguity about the conditions that select this tool versus its siblings.

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