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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond that: nothing is sent or stored, and the person transmits the request themselves. This clarifies the tool's side-effect-free nature in a way annotations alone do not.

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?

Two sentences, front-loaded with the action and followed by the critical no-send/no-store assurance. Every sentence earns its place with no repetition 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?

With no output schema and only annotations carrying safety metadata, the description still covers what the tool produces (a specification and contact details), what it does not do (send or store), and where identifiers come from. The main missing piece is explicit usage guidance, but otherwise an agent has enough to call it correctly.

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 carries the burden. It lists six of the seven parameters by name (produit, quantité, format, papier, finition, délai) and explains that identifiants are printer identifiers obtained from other tools. It still does not specify optionality or formats, but it compensates well for the schema's lack of descriptions.

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 and resource: drafting a quote-request specification and providing public contact details of selected printers. It enumerates the specification fields (produit, quantité, format, papier, finition, délai) and clarifies that identifiers come from other tools, making it easy to distinguish from siblings like rechercher_imprimeurs or fiche_imprimeur.

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?

Usage is implied: gather identifiers from other tools and then prepare a quote request. However, the description never explicitly says when to use this tool versus alternatives, nor does it name any sibling or state exclusions. A user must infer the workflow.

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