Télécharger un acte ou des comptes (PDF)

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

Annotations declare readOnlyHint=false with destructiveHint=false and idempotentHint=true; the description usefully explains that gap by disclosing the real side effect — a PDF written into the configured download folder via INPI_DOSSIER_TELECHARGEMENTS — and that the file path is returned. It stops short of stating prerequisites (API credentials, directory existence), overwrite behaviour, or failure modes for unavailable documents.

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, both earning their place: the first states the action, source, and destination; the second states the return value. Front-loaded and free of preamble or repetition of structured fields.

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 three-parameter tool with no output schema, the description covers the action, the persistent side effect, the destination configuration, and the return shape (file path). What is missing is modest but real: access prerequisites and behaviour when the document is unavailable or the file already exists.

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%, so each parameter already carries its own description, including the enum values for 'type' and the pointer to lister_documents_entreprise for 'identifiant'. The description adds only that the content is 'un acte ou des comptes annuels déposés au RNE', which is minor reinforcement rather than new semantics.

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 a specific verb and resource set: downloading in PDF an 'acte' or annual accounts filed with the RNE, plus saving it locally. This is clearly distinguishable from the sibling 'lister_documents_entreprise' (which enumerates rather than fetches content). The parenthetical file-path outcome further pins down what the tool delivers.

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 rather than stated: an agent infers this is the retrieval step after obtaining a document identifier, and the schema's 'identifiant' description points to lister_documents_entreprise. However, the description itself offers no explicit when-to-use, when-not-to-use, or named alternative for choosing between downloading and merely listing documents.

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