Attestwire

Validate an EN 16931 e-invoice

validate_invoice

Read-onlyIdempotent

Validate an invoice against EN 16931 and its national CIUS rule sets (XRechnung UBL/CII, Peppol BIS 3.0, Factur-X). Returns every failure as a "teaching error": the official rule id, the business term (BT-/BG-) it constrains, what the regulation actually requires, and a concrete fix. REQUIRES AN API KEY and costs 1 document against the monthly quota — call issue_api_key first if you do not have one. For explaining a rule id you already have, use explain_rule instead: it is free.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`invoice`	Yes	The invoice to validate, as an InvoiceInput object. Required: profile (one of en16931, xrechnung-ubl, xrechnung-cii, facturx-en16931, peppol-bis-3), invoiceNumber, issueDate ("YYYY-MM-DD"), currency (ISO 4217), seller {name, address{city, postalCode, countryCode}}, buyer {name, address{...}}, and lines[] of {id, description, quantity, unitCode, unitPrice, vatCategory, vatRate}. The XRechnung profiles additionally require buyerReference (BT-10), a seller contact {name, phone, email}, and payment instructions — see BR-DE-1/2/5/6/7/15 via the explain_rule tool. A CREDIT NOTE IS THE SAME OBJECT with invoiceTypeCode (BT-3) set to "381": there is no separate tool and no separate shape, the same rules run, and the amounts stay POSITIVE — the type code is what conveys the direction of the money, so negative amounts on a credit note reverse it back into an invoice. Full schema: https://api.attestwire.com/openapi.json

TDQS

A4.7/5.0

Behavior5/5

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

Annotations state readOnly and idempotent, but the description adds substantial behavioral context not visible in structured fields: the tool consumes one document against a monthly quota, requires an API key, and returns teaching errors with rule IDs, business terms, requirements, and fixes. It also details credit-note behavior (same object, invoiceTypeCode 381, positive amounts), which is a critical behavioral edge case.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet information-dense: first sentence states purpose and standards, second describes return format, third covers prerequisites and quota cost, fourth explicitly references an alternative tool, and fifth provides schema URL. Every sentence earns its place, with no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple CIUS profiles, quota cost, authentication) and the absence of an output schema, the description is complete. It explains what the return contains (teaching errors), the full depth of the invoice object via a linked OpenAPI spec, and the credit-note exception. It also notes the sibling explain_rule for free rule lookup, covering the broader context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes the single 'invoice' parameter in depth, including required fields, profile enum, and the credit note handling. The tool description reinforces those details but adds no new parameter-specific meaning beyond what the schema provides. With 100% schema coverage, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Validate an invoice against EN 16931 and its national CIUS rule sets,' naming the specific standards (XRechnung UBL/CII, Peppol BIS 3.0, Factur-X). It clearly distinguishes from siblings by pointing to explain_rule for rule ID explanations and implying validate_invoice_xml handles XML input vs. this object-based validation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use: validating an invoice object. It states prerequisites ('REQUIRES AN API KEY') and directs users to issue_api_key first. It also names the alternative for rule ID lookup ('use explain_rule instead: it is free'), making the choice between tools unambiguous.

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

All Attestwire tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: validation (two input formats), generation, rule explanation, company readiness, VIES status, platform listing, key issuance, and upgrade link. Even the two validation tools are clearly split by input type (JSON vs XML), and the descriptions explicitly prevent confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (check_, explain_, generate_, get_, issue_, list_, validate_). The verbs are precise and the nouns clearly indicate the target, with no mixing of conventions or vague terms.

Tool Count5/5

Nine tools is well within the ideal scope for a specialized e-invoicing compliance server. Each tool serves a distinct purpose in the workflow—validate, generate, explain, check company/VIES/platform status, and manage API keys—without redundancy or bloat.

Completeness5/5

The tool surface covers the full lifecycle of e-invoicing compliance: validation (JSON and XML), generation, rule explanation, and external status checks (company, VIES, approved platforms). API key management and upgrade paths are also included. No obvious missing operations for the stated purpose.

Resources

Need Help?