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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: scope is limited to officine prices, market/zone prices are unknown here, and proposed prices are not advised. It does not cover result size or latency for up to 20 products, hence not a 5.

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 content inventory is front-loaded and useful, but the text is a single very long sentence that bundles return fields, usage rules and caveats together. The trailing English sentence ('Full sales, stock and margin detail...') duplicates the French description and adds no new information, which is avoidable padding.

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?

There is no output schema, yet the description enumerates the return payload in detail (per-product figures, totals, averages, cover in days, rank only for a single product, aggregated family totals for multiple). Combined with annotations covering safety, an agent has everything needed to call it correctly and interpret the result.

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 only 50%: cips is documented in the schema, mois is not. The description compensates by explaining that the tool returns 'N mois de ventes' and that multi-product totals are computed 'mois par mois', giving the agent the meaning of the unlabeled parameter. It still does not state the 1-24 range or default 12 in prose, but those are in the schema.

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?

Names the resource (produit) and enumerates precisely what the tool returns: identity, catalogue price, PAMP, margin rate, stock state, N months of sales, totals, averages, cover in days and family rank. It also contrasts with siblings by pointing to chercher_produit for CIP codes and by excluding pricing/market questions, so an agent can tell it apart from ventes_mois, palmares or stock_dormant.

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?

Explicit when-to-use ('détail d'une référence précise, en comparer quelques-unes ou additionner une famille de produits') plus explicit when-not ('Pas pour une question médicale, une posologie, un dossier patient ni un prix du marché'). It even names the missing capability needed instead (a pricing tool tracking the pharmacy's zone), which is strong routing guidance.

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