invoicein

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the useful behavioral detail that output is a flat CSV with either one row per line item or one row per document. However, it does not disclose input handling, failure modes, or anything beyond the output shape.

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 a single tight sentence that front-loads the output format ('Flat CSV') and then succinctly states the two possible row granularities. There is no verbosity or redundant detail.

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?

The schema and annotations cover a great deal: parameter types, formats, size limits, and safety. However, the description does not make explicit that one of file_base64 or path must be provided, even though the schema marks both as optional. This is an implicit precondition an agent could easily miss when calling the tool with no arguments.

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 100%, and the level parameter already explains the 'lines' and 'documents' modes. The description's phrase 'one row per line item, or one row per document' merely paraphrases the schema's own parameter documentation rather than adding new meaning. The file_base64 and path parameters are also already well described in the schema.

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 clearly identifies the resource (invoice) and output format (flat CSV), and distinguishes the two row granularities. It lacks an explicit action verb like 'export' or 'convert', and it does not explicitly differentiate from siblings such as invoice_to_html or invoice_to_datev, though the CSV format makes the distinction fairly obvious.

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 guidance on when to use this tool versus alternatives like read_invoice, validate_invoice, invoice_to_html, or invoice_to_datev. The use case is only implied by the tool name and the word 'CSV'; no explicit conditions, exclusions, or prerequisites are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context: output rows are grouped per VAT-rate group, expense accounts are selected automatically based on SKR, and the user should verify account mappings before import. There is no contradiction with the annotations.

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 dense sentences with no filler. The output format is front-loaded, the key transformation rule is stated, and the verification caveat is a practical addition that earns its place.

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 an output schema present, full parameter-schema coverage, and annotations covering safety, the description provides enough context to understand the tool's behavior and constraints. The only notable gap is explicit sibling differentiation, but it does not prevent correct invocation.

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?

The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds slight semantic value by explaining that SKR drives automatic expense-account mapping, but it does not meaningfully elaborate on path, file_base64, or creditor_account beyond the schema.

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 title and description state a specific action (exporting an invoice), a precise target format (DATEV Buchungsstapel EXTF 700), and the transformation behavior (one booking row per VAT-rate group, automatic expense accounts by SKR). This clearly distinguishes it from sibling tools like invoice_to_csv and invoice_to_html.

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 implies the use case — producing DATEV accounting text for an incoming invoice — and includes a tax-advisor verification caveat, but it never explicitly states when to prefer this tool over invoice_to_csv or invoice_to_html, nor when not to use it. The routing between siblings is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context beyond those annotations: output is self-contained, printable, consistent in layout across syntaxes, and localized via language labels. No contradictions with annotations are present.

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 a single, well-structured sentence that front-loads the core purpose and packs in the most relevant behavioral details without waste. Every clause earns its place.

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 presence of a complete input schema, an output schema, and safety annotations, the description covers the key behavioral aspects an agent needs: output type, self-contained nature, printability, layout consistency, and localization. It could slightly expand on when to prefer this over sibling tools, but nothing critical is missing for correct invocation.

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 100%, and the schema already explains lang, path, and file_base64 in detail. The description adds little parameter-specific meaning beyond reinforcing that language affects rendering labels, which the schema already states. Baseline 3 is appropriate.

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 ('renders') and resource ('invoice') with a clear output form: human-readable, self-contained, printable HTML. This clearly distinguishes it from siblings like invoice_to_csv, invoice_to_datev, read_invoice, and validate_invoice, which produce different output types or serve different objectives.

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 implies when to use this tool: when a human-readable, self-contained HTML representation of an invoice is needed, regardless of source syntax. It does not explicitly name alternatives or state when not to use it, but the render-to-HTML framing provides clear contextual guidance compared to the sibling tools.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds valuable behavioral detail beyond the annotations: it returns the detected format, normalizes output across syntaxes, and includes fix hints with failed validation rules. This is meaningful context for an agent invoking the tool.

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 with no filler. The first sentence states the core purpose and validation behavior; the second expands on the return shape and report quality. All information is front-loaded and earns its place.

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?

The description is complete for this tool's complexity: it covers scope, output normalization, validation, and report content. The output schema handles return-structure details, and the annotations cover safety semantics. No critical operational gap remains for an agent 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 100%, so the baseline is 3 even though the description adds no parameter-specific detail. The schema already documents lang, path, and file_base64, including allowed languages, local-path restrictions, and the 25 MB limit.

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 ('Parse') and resource ('any European e-invoice') and clearly defines the output: canonical EN 16931 JSON plus a validation report. This distinguishes read_invoice from its sibling validate_invoice, since it both parses and validates rather than only validating.

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 implies usage: use this tool when an invoice file needs to be parsed into canonical JSON and validated against official rule sets. However, it does not explicitly mention when to prefer validate_invoice or the conversion siblings, so the routing guidance is only implied rather than stated.

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

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

Annotations already cover read-only and idempotent behavior. The description adds context beyond those: it emphasizes that this is validation only, surfaces that it is cheaper than read_invoice, and tells the agent what classes of results to expect. No contradiction with annotations.

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 focused sentences with no filler. The first sentence front-loads the tool's purpose and output scope, and the second sentence provides a crisp decision rule against a sibling. Every clause earns its place.

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 a full output schema, complete parameter documentation, and safety annotations, the description covers the remaining selection context: what this tool returns, its validation-only scope, and when it is preferable to read_invoice. Nothing essential is missing for an agent to choose and 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 100%, so the schema fully documents lang, path, and file_base64. The description does not add parameter-level detail, but it also doesn't need to; the baseline 3 applies because the schema carries the burden.

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 action ('Validation only') and resource ('invoice'), then enumerates the concrete outputs: applied rule sets, errors/warnings with fix hints, and invoice header. It clearly distinguishes itself from read_invoice by framing itself as a cheaper validation-first alternative.

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 explicitly names the sibling tool read_invoice and gives the condition for choosing validate_invoice: when you 'only need a verdict.' This is direct when-to-use guidance and makes the trade-off clear.

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