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

Annotations already cover the safety profile (readOnly, non-destructive, non-idempotent), so the description's added value is the 200-item cap, the ZIP packaging, and the partial-failure contract: skipped sources are reported and a manifest must be read. That partial-result disclosure is genuinely beyond the annotations and important for a bulk export.

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 short sentences, front-loaded with the action and its cap; no filler. The second sentence is a slightly terse operational instruction rather than descriptive prose, but it earns its place by disclosing partial-failure handling.

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, the description carries the return-value burden and does mention the named ZIP, manifest, and skipped sources. It omits how the ZIP is delivered (URL, expiry, async job vs immediate), which is critical for a 200-item bulk export and matters given nearby tools like get_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 0%, so the description must carry parameter meaning. It correctly signals the two modes (explicit selection vs saved batch) and the 200 cap that mirrors maxItems, but it never explains that invoice_ids and batch_id are mutually exclusive, what happens if both or neither are supplied, or the required UUID format.

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: download original invoice PDFs, capped at 200, packaged as a named ZIP. The scope (original PDFs, not re-rendered exports) is stated, which helps against siblings like export_saved_invoice or export_client_invoices, but no sibling is named explicitly, so differentiation is left to inference.

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?

"For an explicit selection or one saved batch" implies the two calling modes, but there is no explicit when-to-use/when-not guidance and no routing to competing export tools (export_saved_invoice, export_client_invoices, export_saved_document). The agent must infer which export tool fits.

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