mcp-server-erechnung
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| X-RapidAPI-Key | No | Your RapidAPI key used as a header when connecting to the remote Streamable HTTP MCP server. | |
| X-RapidAPI-Host | No | The RapidAPI host header for the remote Streamable HTTP MCP server. | german-e-rechnung-zugferd-and-xrechnung.p.rapidapi.com |
| ERECHNUNG_RAPIDAPI_KEY | No | Your RapidAPI key used when running the local npx stdio MCP server. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Deterministic German B2B E-Rechnung compliance tools (EN 16931, KoSIT XRechnung 3.0.2, DATEV ZUGFeRD 2.5 PDF/A-3b, GiroCode SEPA QR, and guarded hybrid parsing).
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_erechnungA | Deterministically generate an official German E-Rechnung (ZUGFeRD 2.5 PDF/A-3b with SEPA GiroCode QR or KoSIT XRechnung 3.0.2 XML) from structured JSON (<300ms, zero LLM hallucinations, exact BigDecimal math & MOD-97 IBAN verification). |
| validate_erechnungA | Validate a ZUGFeRD PDF/A-3b (Base64) or XRechnung 3.0 XML against official EN 16931 XSD, KoSIT German Business Rules (BR-DE-*), and veraPDF ISO 19005-3. Returns valid=true/false plus structured rule_id, field, and human_hint. |
| parse_erechnungA | Smart Hybrid German E-Rechnung parser (Empfangspflicht): extracts embedded ZUGFeRD/Factur-X/XRechnung XML deterministically in ~20ms (source='NATIVE_XML'), or falls back to guarded extraction on flat PDFs with math_verified and iban_valid checks. |
| embed_zugferd_pdfC | Deterministically upgrade an existing visual PDF (Base64) + structured invoice JSON into an ISO 19005-3 PDF/A-3b ZUGFeRD 2.5 hybrid invoice with embedded factur-x.xml and GiroCode QR. |
| magic_convert_pdfB | Convert a flat legacy PDF (Base64, max 5 pages) into a ZUGFeRD 2.5 PDF/A-3b under strict BigDecimal Math & ISO 13616 MOD-97 IBAN guardrails. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
generate_erechnung, embed_zugferd_pdf, and magic_convert_pdf all ultimately produce a ZUGFeRD PDF/A-3b hybrid invoice, and the boundaries between 'generate from JSON', 'upgrade PDF+JSON', and 'convert flat PDF' are not fully crisp—magic_convert appears to combine parse+embed. validate_erechnung and parse_erechnung are clearly distinct, and the descriptions do help an agent pick the right entry point, but there is real overlap in the generation/conversion cluster.
generate_/validate_/parse_erechnung follow a clean verb+domain pattern, but the set drifts to a different object name in embed_zugferd_pdf and a non-standard quirky verb in magic_convert_pdf. Readable but not one predictable convention across all five tools.
Five tools is well within a healthy scope and each maps to a recognizable invoice operation (generate, validate, parse, embed, convert). Slight over-partitioning in the generation/embedding area keeps it from being a perfect fit, but nothing feels padded or missing count-wise.
The core lifecycle is covered: create both ZUGFeRD and XRechnung from JSON, validate against EN 16931/KoSIT/veraPDF, parse inbound invoices, embed and convert legacy PDFs. Minor gaps remain—no direct ZUGFeRD↔XRechnung format conversion and no preview/readable rendering—but agents can work around these via generate with the appropriate format flag.