accounting_export_zip

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

With no annotations, the description must fully explain behavior on its own; it discloses that a ZIP with XML files is produced and that SAGA account overrides fall back to stored settings. However, it does not mention currency-splitting behavior, the effect of exportBnr/exportAccounts/includeDiscount, or whether the export is synchronous or returns a download artifact.

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 description is front-loaded with the core purpose and content, followed by a concise sentence about date filtering and a focused note on SAGA account overrides. Each sentence earns its place, though the SAGA override sentence is slightly more detailed than necessary for a top-level description.

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?

Given the rich input schema and no output schema, the description is mostly complete: it states the output container format, the kinds of XML files included, target software, and date filtering. It omits a few behavioral nuances covered only in parameter descriptions, such as per-currency file splitting and the optional SAGA include files, but these are documented in the schema.

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?

Every parameter has a schema description, and many add meaningful constraints: target is an enum, dates specify YYYY-MM-DD, companyId has a default behavior, and the accounts/currencyAccounts objects document per-export overrides, fallback behavior, and SAGA-only applicability. The overall description reinforces the account-override 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 opens with a specific verb and resource: 'Export accounting data as a ZIP archive for import into accounting software (Saga, Winmentor, or Ciel).' It names the target formats and enumerates the ZIP contents (clients, suppliers, products, invoices, receipts, payments), making the tool's purpose unmistakable and distinguishing it from invoice-specific exports.

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?

The description states the general purpose and date-range filtering, and it gives conditional guidance for SAGA chart-of-accounts overrides, but it does not explicitly contrast the tool with sibling exports such as invoices_export_zip or invoices_export_saga_xml. Usage must be inferred from the accounting-software-import wording rather than stated directly.

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