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

With readOnlyHint=false already flagged, the description adds real behavioral context: enregistrer creates a new version only when the definition changed ('unchanged definition: no new version'), which explains the idempotentHint, and lister anonymizes other users' families behind an 'anonymous author code', a privacy behavior not visible in annotations. It still says nothing about permissions, quotas, or failure modes.

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 trigger condition is front-loaded and every clause carries information (per-action behavior, the prerequisite tool), with no filler. It is dense and slightly crammed into two long sentences, which costs a point against a tighter, better-segmented layout.

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 6-parameter, multi-action tool with one nested object and no output schema, the description covers all three actions, the nested `famille` payload's purpose, and the required prerequisite step. It does not describe what lister or lire actually return beyond the families themselves, leaving some return-shape ambiguity.

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 coverage is 100% and each parameter already documents the action it applies to (lire, enregistrer), so the schema carries the load. The description mostly restates those action-to-parameter mappings ('publique' to share, 'version' default latest) rather than adding syntax or format detail, so the baseline 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 names the specific resource (the account's persistent family library) and enumerates its three modes (lister/lire/enregistrer) with a helpful Revit-family-library analogy. It clearly differentiates itself from cao_famille_essayer, but it does not distinguish itself from the closely named siblings cao_familles and cao_familles_recharger, which an agent would need to tell apart.

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?

It opens with an explicit trigger ('WHEN a parametric family ... must be reused across projects or shared') and states the prerequisite workflow ('Build and test the family first with cao_famille_essayer'). There is no guidance on when NOT to use it versus the sibling library tools, so it falls short of a 5.

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