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

Goes well beyond the annotations: discloses external ANAF lookups that fill company names, addresses, county codes and VAT status, that totals and VAT are computed, and that the XML is validated before return. Also surfaces the commercial behavior — $0.05 USDC via x402, charged only on a valid invoice — which no annotation conveys.

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?

Front-loaded with the when-to-use condition and the output, with the example last where it belongs. It is one dense block, however, mixing input shape, enrichment behavior, validation, and pricing; splitting the payment note out would improve scanability.

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?

Covers the noteworthy complexity — nested invoice object with only an example in the schema, plus external ANAF lookups and pre-return validation. With no output schema, it should still say what comes back (raw XML string, file, or base64) and whether the ANAF enrichment can fail or return partial data.

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 schema's coverage figure is nominal: the only description is 'see the tool description for the shape' with additionalProperties=true, so the description carries the real burden. It enumerates required fields (number, issue/due dates, seller/buyer CUI, line name, quantity, unit, price ex-VAT, VAT rate), flags IBAN as optional, gives concrete VAT rates, and supplies a full example payload.

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 and artifact: builds UBL 2.1 CIUS-RO e-Factura XML accepted by ANAF. The opening condition ('you have invoice data but no XML') implicitly separates it from validate_invoice/fix_invoice, which take existing XML. An agent can tell exactly what this produces.

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?

'Use when you have invoice data but no XML' gives a clear trigger condition, and the currency note tells you what to add for non-RON cases. No sibling is named explicitly (e.g. 'to check or repair an existing file, use validate_invoice / fix_invoice'), so the alternative routing 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.