mcp-einvoicing-de

Overview Schema Source Related Servers Discussions Admin

Invoice Create

invoice_create

Generate ZUGFeRD 2.x or XRechnung 3.x invoices as structured XML (CII/UBL) to meet German B2B e-invoicing requirements and EN 16931 compliance.

Instructions

Generate a ZUGFeRD 2.x or XRechnung 3.x invoice in XML (CII or UBL) format.

Supports all ZUGFeRD profiles: MINIMUM, BASIC_WL, BASIC, EN_16931, EXTENDED. For XRechnung, set profile to XRECHNUNG and choose CII or UBL syntax. When the buyer is a German VAT-registered business (DE-prefixed VAT id), the Wachstumschancengesetz B2B mandate (effective 2025-01-01, §14 Abs. 2 UStG) requires a structured EN 16931 invoice. Non-XML output is rejected unless transitional_period_opt_in is set to True (allowed only 2025-2026 with the buyer's written consent).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`syntax`	No	XML syntax: 'CII' (default) or 'UBL' (XRechnung only).	CII
`invoice`	Yes	Invoice data matching the ZUGFeRDInvoice schema. Set invoice.profile to XRECHNUNG to produce an XRechnung invoice.
`pretty_print`	No	Pretty-print the XML output.
`output_format`	No	'xml' (default) or 'pdf' (ZUGFeRD hybrid PDF/A-3).	xml
`transitional_period_opt_in`	No	Acknowledge the Wachstumschancengesetz transitional period (2025-2026) and explicitly permit non-XML output for a German VAT-registered buyer. Set to True only when the buyer has agreed in writing to receive PDF or another non-structured format. From 2027 the transitional grace ends for large businesses; from 2028 all B2B invoices to German VAT-registered buyers must be in a structured EN 16931 format. Source: §14 Abs. 2 UStG, Wachstumschancengesetz of 27 March 2024 (BGBl. I Nr. 108).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.11.0Aug 28, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
addedInput schema / properties / invoice / additionalProperties
```
Added value: +true
```

changedInput schema / properties / invoice / description

Previous value: -"Invoice data (ZUGFeRDInvoice schema)"New value: +"Invoice data matching the ZUGFeRDInvoice schema. Set\ninvoice.profile to XRECHNUNG to produce an XRechnung invoice."

addedInput schema / properties / output_format / description

Added value: +"'xml' (default) or 'pdf' (ZUGFeRD hybrid PDF/A-3)."

removedInput schema / properties / output_format / enum
```
Removed value: -[
-  "xml",
-  "pdf"
-]
```
addedInput schema / properties / pretty_print / description
```
Added value: +"Pretty-print the XML output."
```

addedInput schema / properties / syntax / description

Added value: +"XML syntax: 'CII' (default) or 'UBL' (XRechnung only)."

removedInput schema / properties / syntax / enum
```
Removed value: -[
-  "CII",
-  "UBL"
-]
```

addedInput schema / properties / transitional_period_opt_in / description

Added value: +"Acknowledge the Wachstumschancengesetz\ntransitional period (2025-2026) and explicitly permit non-XML\noutput for a German VAT-registered buyer. Set to True only when\nthe buyer has agreed in writing to receive PDF or another\nnon-structured format. From 2027 the transitional grace ends for\nlarge businesses; from 2028 all B2B invoices to German\nVAT-registered buyers must be in a structured EN 16931 format.\nSource: §14 Abs. 2 UStG, Wachstumschancengesetz of 27 March 2024\n(BGBl. I Nr. 108)."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

Changed1 schema field changedv0.3.1Jun 21, 2026
- addedInput schema / properties / transitional_period_opt_in
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```
First observedv0.1.0May 5, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It does this well by explaining that non-XML output is rejected unless transitional_period_opt_in is set, and by specifying the legal mandate for German VAT-registered buyers. It could go further by noting expected error behavior or side effects, but for a generation tool the compliance constraints are the most important behavioral traits and they are explicit.

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

Conciseness4/5

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

The description is compact despite covering a legally complex topic. It front-loads the core purpose, then layers profile support, syntax guidance, and legal constraints in a logical order. The legal citations add necessary authority for a compliance-sensitive tool, and no sentence is wasted.

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

Completeness4/5

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

Given the complexity of invoice generation, the description covers the key decision points: format, profile, syntax, and legal opt-in conditions. The output schema and 100% parameter coverage fill in the technical return details. It is slightly less complete on alternative-tool routing, but overall it provides enough context for an agent to invoke invoice_create correctly.

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 coverage is 100%, so the baseline is 3, but the description adds meaningful context beyond the schema: it enumerates supported ZUGFeRD profiles, explains the XRechnung syntax choice, and clarifies when transitional_period_opt_in should be true. This helps an agent reason about the invoice.profile and output_format parameters rather than just reading their schema descriptions.

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 specific verb and resource: 'Generate a ZUGFeRD 2.x or XRechnung 3.x invoice in XML (CII or UBL) format.' It clearly names the formats and profiles, and the generation verb distinguishes it from siblings like invoice_validate, invoice_parse, and invoice_convert. No ambiguity remains about what this tool does.

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 gives clear usage context: how to select XRechnung, which profiles are supported, and when the transitional_period_opt_in flag is required for non-XML output. It does not explicitly list when not to use this tool or point to alternatives, but the sibling names and the creation-focused wording make those boundaries reasonably clear.

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

Deploy Server