Create ZUGFeRD invoice

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

No annotations are provided, so the description carries the full burden. It usefully discloses the output format (PDF/A-3 with embedded XRechnung XML), but says nothing about permissions, failure modes, or the email side effect that the transport parameter triggers. For a creation tool with zero annotation coverage this is adequate but incomplete.

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?

A single tight sentence, front-loaded with the verb and the produced artifact, with parenthetical clarification of the embedded XML. Nothing extraneous.

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 should say what is returned (e.g., generated PDF bytes/base64 or a download reference), and it does not. It also omits the email-delivery behavior when transport is set. Given nested-object inputs and a mutation-style tool, this leaves meaningful gaps.

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 all three parameters are already documented in the schema, including the EN 16931 field reference and the email-transport link. The description restates the inputs at a high level without adding syntax or format details beyond the schema, so baseline 3 applies.

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 (Create) and resource (ZUGFeRD PDF/A-3 e-invoice) and clarifies the artifact ('visual PDF with embedded XRechnung XML'), which separates it from create_xrechnung (XML only) and create_zugferd_pdf. It doesn't explicitly name a sibling to route against, so it stops short of a 5.

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?

Input prerequisites are implied ('from structured invoice JSON plus a visual PDF template'), telling the agent it needs both JSON data and a base PDF. However there is no explicit when-to-use guidance or naming of alternatives such as create_zugferd_from_pdf or create_zugferd_pdf, leaving selection to inference.

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