Generate an EN 16931-conformant UBL 2.1 invoice from structured fields. The result is self-validated before being returned. Provide seller, buyer, and at least one line; for standard-rated (category "S") lines include a vatRate and the seller vatId.
| Name | Required | Description | Default |
|---|---|---|---|
| buyer | Yes | ||
| lines | Yes | ||
| seller | Yes | ||
| dueDate | No | ||
| payment | No | ||
| currency | Yes | ISO 4217, e.g. EUR. | |
| issueDate | Yes | ISO date, e.g. 2026-06-19. | |
| invoiceNumber | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses self-validation before return, which adds value beyond annotations. Annotations already indicate non-destructive and idempotent behavior, but no mention of authentication, rate limits, or error handling.
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 redundancies. Front-loads key standard conformance and self-validation, then adds precise usage guidance.
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 essential aspects (standard, validation, critical parameters) but omits details on nested objects like seller, buyer, payment, dueDate. With no output schema, description could explain return value structure more.
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 coverage is low (25%), but description adds critical meaning: mandates seller, buyer, lines, and specific conditions for vatRate and seller vatId on S-category lines. Partially compensates for missing schema descriptions.
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?
Clearly states it generates an EN 16931-conformant UBL 2.1 invoice. Distinguishes from siblings (convert, validate, list formats) by focusing on creation.
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?
Provides explicit requirements: provide seller, buyer, at least one line, and for 'S' category lines include vatRate and seller vatId. Does not explicitly exclude alternatives but implies usage for generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool addresses a distinct operation—generate creates, validate checks, convert transforms, and list_supported_formats provides metadata—with no functional overlap. The descriptions make the boundaries between tools crystal clear.
All tool names follow a consistent verb_noun pattern (convert_invoice, generate_invoice, list_supported_formats, validate_invoice), with the object being the domain concept. This makes the set predictable and easy to navigate.
With only 4 tools, the server is tightly scoped to e-invoice processing—each tool earns its place, and the count is neither too thin nor bloated. It is an ideal size for the utility's purpose.
The set covers the core workflow: generating invoices, validating them, converting between formats, and discovering supported formats. There are no obvious gaps for the stated domain; users can perform all essential operations.