get_document_pdf

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

The readOnlyHint annotation already marks this as a non-mutating read. The description adds real value by disclosing that without save_to it returns a link, while with save_to it writes the PDF to a file or folder. That local filesystem write is a side effect worth noting against a readOnly annotation, though it concerns the caller's disk rather than backend data, so it is a tension rather than a clear contradiction. It does not describe the link format or errors for unsupported document types.

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 compact sentences with no padding, and the core purpose (PDF link) is front-loaded. The parenthetical scope note is efficient rather than redundant. Slightly terse given what is left unsaid, but nothing wasteful.

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 3-parameter tool with no output schema, the description conveys the main behavior and the save_to effect adequately. However, it never clarifies what the id references, what the returned link looks like, or whether behavior differs across the covered document types. Adequate but with clear gaps for a tool whose output (a link) is central.

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 only 33% (id and save_to have no schema descriptions), so the description carries extra weight. It does explain save_to's effect (downloads to a file/folder), but leaves id and the link-versus-download default implicit. It partially compensates for the coverage gap but not fully.

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: it returns the PDF link of a document, and notes it also covers DDT and accompanying invoices (fattura accompagnatoria). This is clearer than a bare name restatement. It stops short of distinguishing itself from the many sibling document getters (get_issued_document, get_received_document), but the retrieval target (the PDF) is unambiguous.

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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives among the dozens of sibling document tools. The only contextual cue is that save_to triggers a download, which is parameter behavior rather than usage routing. An agent must infer on its own when to reach for this versus the other get_* document tools.

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