facturx_generate

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

Annotations are absent, so the description carries the full burden. It clearly states and returns 'le XML et un résumé des montants', and mentions automatic calculation of HT/TVA/TTC totals. This goes beyond the elementary mention of what the tool does and gives useful behavior information — it does not hide the fact that it computes totals and returns a summary. Remaining unresolved traits such as error handling or read/write side effects are not disclosed, but for a generation tool this seems adequate.

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, properly structured sentence (in French) that states the action, the object, the norm, the automatic calculations, and the return value. It’s concise and front‑loaded with the core purpose and output. Not a single redundant word, though it could be split into two sentences for readability; the density is worthwhile.

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 tool’s complexity (15 parameters, 6 required, nested objects, no output schema) the description is lightweight: it mentions the return value (XML + summary) but lacks a clear statement about validation against EN 16931/UE, error cases, or how input fields map to output. However, the input schema already carries 73% of the description, and the tool’s responsibility is clear enough. This is a minimum viable description for a generator, but not a thorough guide for a complex, norm‑driven tool.

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 73%, and nested objects are well-documented there (e.g., countryCode, vatRate, vatCategory). The description adds no explicit parameter‑level guidance beyond implying the tool will compute totals. Given the high schema coverage, a score of 3 is fair — The description doesn’t contradict or enrich the schema, but it also doesn't need to carry much since the schema is rich.

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 ('génère'), a precise resource ('fichier XML Factur-X'), and a scope (EN 16931/UE standard). It clearly distinguishes this tool from siblings like facturx_validate, facturx_parse, and facturx_create_pdf by focusing on XML generation, so an agent can easily select it.

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 (to produce a legal/invoice XML) and mentions it comprises total computation, which hints at when to use it over facturx_compute_totals. However, it does not explicitly discuss when not to use this tool (e.g., if only totals are needed, facturx_compute_totals might be a better fit) nor mention other siblings that generate PDFs. The guidance is implied rather than explicit.

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