Créer une feuille de temps

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

Annotations already provide readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds the important behavioral detail that the write is non-idempotent and that two CRAs can coexist on the same month. It also states the return value (confirmation + created CRA details), adding useful context beyond the annotations.

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 well-structured: a concise one-line statement of purpose, followed by clearly labeled sections ('Quand', 'Plutôt que', bullet point on 'term', idempotency note, 'Returns'). Every sentence earns its place; no filler or redundancy.

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 9-parameter tool with no output schema, the description covers the essential operational guidance: when to use, what to avoid, the key parameter's format, idempotency, and return value. Some gap remains on how optional parameters (like state, startDate, endDate) relate to the monthly CRA creation, but the schema already documents these fields.

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%, so the schema already documents all 9 parameters. The description adds semantic clarity for 'term' (full month, daily granularity) and implicitly links 'resourceId' and 'term' as the key pair defining a CRA, but it doesn't significantly deepen the meaning of the other parameters. Baseline 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?

States a specific verb+resource (creates a monthly timesheet for a resource), defines the exact scope (one month per resource), and distinguishes it from the sibling tool by noting the API's non-deduplicating behavior. The description makes it clear this tool is for opening a new CRA for a (resource, month) pair that doesn't yet exist.

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?

Provides explicit 'Quand' (when to use) and 'Plutôt que' (rather than) guidance, warning against calling boond_timesheets_search first because the API does not deduplicate. It also clarifies that 'term' must be in YYYY-MM format and covers a full month, removing ambiguity.

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