generate_erechnung

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description is not obliged to restate safety. It does add genuine behavioral context beyond them: deterministic output, sub-300ms latency, exact BigDecimal arithmetic, and MOD-97 IBAN verification — telling the agent the output is reproducible and validates bank data. It does not describe the return payload, which is the main remaining gap.

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?

One front-loaded sentence with the verb and resource first, then qualifying detail — no structural waste. Some phrasing is promotional ("zero LLM hallucinations") rather than operationally useful, which costs a point but not readability.

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 tool with a deeply nested invoice schema and no output schema, the definition explains the generation target well but omits what is actually returned (base64 PDF, file path, XML string?) and how errors or validation failures surface. An agent could decide to call it but would not know how to consume the 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?

Reported schema description coverage is 0%, so the description carries the parameter burden; it partially does by mapping the format choice to distinct artifacts (ZUGFeRD PDF/A-3b with SEPA GiroCode QR vs XRechnung XML), which clarifies the format enum and implicitly the stampGiroCode flag. It says nothing about the nested invoice object's required fields, profile selection, or which fields become mandatory under XRECHNUNG.

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 ("generate") plus the exact resource (an official German E-Rechnung) and names the two concrete artifacts produced (ZUGFeRD 2.5 PDF/A-3b and KoSIT XRechnung 3.0.2 XML). This cleanly separates it from siblings like parse_erechnung and validate_erechnung, which consume rather than produce invoices.

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 input must be structured JSON, which frames when the tool applies, but it never states when to choose this over validate_erechnung or embed_zugferd_pdf, nor any prerequisites or exclusions. Usage is inferable rather than explicit.

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