einvoicewiz

generate_einvoice_xml

Invoice JSON → validated EN 16931 CII XML (1 credit; failures free).

profile: "en16931" (Factur-X/ZUGFeRD data, B2B) or "xrechnung" (German public sector; needs
invoice.buyer_reference = Leitweg-ID and seller contact_email/contact_phone).
Invoice schema: see https://einvoicewiz.com/openapi.json  (required: invoice_number, issue_date,
currency, seller{name,country}, buyer{name,country}, lines[{name,qty,unit_price,vat_rate}]).
Returns {xml, validation, verify:{id,url}, credits_left}. On 422 the body lists the violated rules.

Input Schema

TableJSON Schema

Name	Required	Default
`api_key`	No
`invoice`	Yes
`profile`	No	en16931

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so impressively: it discloses the credit cost, failure behavior ('failures free'), return shape ({xml, validation, verify:{id,url}, credits_left}), and HTTP 422 error body content. It also explains validation behavior and profile-specific prerequisites, leaving little hidden about the tool's behavior.

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 dense but every clause earns its place: transformation, cost, profile selection, required fields, return value, and error behavior are all present with no filler. The use of compact schema notation and a link to the full OpenAPI spec keeps it as tight as possible for the complexity involved.

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?

Despite having no output schema and no annotations, the description provides enough operational context for an agent to call the tool correctly: required invoice fields, profile-specific requirements, return structure, cost, and failure semantics. The link to the full invoice schema further closes any remaining gaps.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It thoroughly documents the invoice object's required fields and the profile values with their meanings. The only gap is api_key, which is not explained, but it is optional with a default and the schema title provides some minimal signal.

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 a precise transformation statement: 'Invoice JSON → validated EN 16931 CII XML', specifying verb, resource, and validation constraint. It also differentiates itself from siblings like validate_einvoice and create_facturx_pdf by naming the exact output format and the two profile modes.

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

Usage Guidelines4/5

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

The description provides clear context for when to choose each profile: en16931 for Factur-X/ZUGFeRD B2B data and xrechnung for German public sector, including required fields for xrechnung. It does not explicitly name alternatives like validate_einvoice or create_facturx_pdf for different workflows, so the when-not-to-use guidance is only implicit.

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

All einvoicewiz 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

A3.9/5.0

Disambiguation5/5

Each tool covers a distinct operation: credits, signup, format advice, XML generation, PDF/Factur-X generation, validation, and certificate lookup. Even generate_einvoice_xml and create_facturx_pdf are clearly differentiated by output format, so an agent should not misselect.

Naming Consistency4/5

Most tools follow a lowercase snake_case verb_noun pattern like check_credits, generate_einvoice_xml, and validate_einvoice. The exceptions are signup (no underscore) and which_format_do_i_need (question-style phrase), which present minor but noticeable deviations.

Tool Count5/5

Seven tools is well-scoped for an e-invoice API: each covers a meaningful step in the user journey from signup and credit checking to format selection, generation, validation, and verification. No tool feels redundant or unnecessary.

Completeness5/5

The tool set provides a coherent end-to-end workflow: onboard with signup, check credits, determine the required format, generate XML or create a Factur-X PDF, validate the result, and look up verification certificates. There are no obvious dead ends for an agent attempting to produce and verify an e-invoice.

Resources

Need Help?