mcp-einvoicing-de
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EINVOICING_DE_LOG_LEVEL | No | Protokollierungsgrad (DEBUG, INFO, WARNING, ERROR) | INFO |
| EINVOICING_DE_PDF_ENGINE | No | PDF-Generierungsmodul (reportlab oder pymupdf) | reportlab |
| EINVOICING_DE_PEPPOL_SMP_URL | No | Peppol-SMP-Lookup-URL (optional) | |
| EINVOICING_DE_KOSIT_VALIDATOR_URL | No | URL des KoSIT-Validierungstools (optional, für Remote-Validierung) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| invoice_createA | 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). |
| invoice_validateA | Validate a ZUGFeRD 2.x or XRechnung 3.x invoice XML. Checks against EN 16931 rules and German KoSIT Schematron rules (BR-DE-* business rules). Returns a structured validation report with errors and warnings. Supports all ZUGFeRD profiles (MINIMUM through EXTENDED) and XRechnung (CII and UBL syntax). Profile and syntax are auto-detected if not specified. By default this validator runs entirely locally (Schematron only). Set cloud_validate=True (or EINVOICING_DE_KOSIT_ENABLE=1) to opt in to sending the invoice XML to a remote KoSIT endpoint. Doing so egresses the full invoice payload. |
| invoice_parseA | Extract structured data from a ZUGFeRD 2.x or XRechnung 3.x invoice. Accepts raw XML (CII or UBL), base64-encoded XML, or base64-encoded PDF (ZUGFeRD hybrid — the XML is extracted from the PDF/A-3 attachment). Returns a structured JSON object matching the invoice data model. |
| invoice_convertA | Convert a ZUGFeRD or XRechnung invoice to a different profile or syntax. Supports ZUGFeRD profile upgrades and downgrades, ZUGFeRD <-> XRechnung conversion, and cross-syntax CII <-> UBL transformation. Profile downgrades may result in data loss; set allow_data_loss=True to permit this. |
| datev_exportA | Export a ZUGFeRD invoice to DATEV CSV format (EXTF 700, Buchungsstapel). Produces a CSV file importable by DATEV Belegtransfer or DATEV Rechnungswesen. Maps invoice line items to DATEV booking records with configurable accounts. |
| tax_rulesA | Query German VAT rules for e-invoicing. Returns structured information about VAT rates (19%, 7%), VAT category codes, reverse charge rules under §13b UStG, zero-rate and exemption provisions (§4 UStG), intra-community supply rules, and VATEX exemption reason codes. For use when building invoice creation logic or validating VAT treatment. |
| peppol_lookup_participantA | Check whether a business is registered on the Peppol network. Performs a DNS-over-HTTPS U-NAPTR lookup followed by an SMP service-group request to determine registration status and the list of supported document type identifiers. |
| peppol_get_service_endpointA | Fetch the AS4 endpoint for a Peppol participant's document type. Resolves the SMP hostname via DNS, then fetches service metadata for
document_type_id. If the SMP returns a redirect, the result's
|
| resolve_peppol_dnsA | Resolve the SMP hostname for a Peppol participant via DNS only. Performs the raw U-NAPTR (SML) lookup without fetching the SMP service group, useful for diagnosing whether a participant is registered in the SML independently of SMP reachability. |
| peppol_sendA | Send a UBL/CII invoice to a Peppol participant via AS4. Looks up the recipient's AS4 endpoint (SMP), builds the ebMS3/AS4 envelope, and transmits it using the supplied signing credentials. |
| list_participant_id_schemesA | List Peppol participant identifier (ICD) schemes from the OpenPeppol eDEC code list. Requires EINVOICING_PEPPOL_CODELIST_DIR to point at a local copy of
the eDEC "Participant Identifier Schemes" GeneriCode export (not
bundled with this package, no confirmed redistribution rights, see
|
| list_document_type_idsA | List Peppol document type identifiers from the OpenPeppol eDEC code list. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| list_process_idsA | List Peppol process identifiers from the OpenPeppol eDEC code list. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| list_spis_use_case_idsA | List Peppol SPIS use case identifiers from the OpenPeppol eDEC code list. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| check_document_type_id_in_codelistA | Check whether a (scheme, value) pair is a recognized Peppol document type identifier. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| check_process_id_in_codelistA | Check whether a (scheme, value) pair is a recognized Peppol process identifier. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| check_participant_id_scheme_in_codelistA | Check whether a 4-digit ISO 6523 ICD code (e.g. "0208") is a recognized Peppol scheme. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| get_peppol_codelist_versionA | Report the OpenPeppol eDEC code list release version(s) currently configured locally. |
| peppol_directory_searchA | Search the Peppol Directory for registered participants. Public, unauthenticated search (no relation to SMP lookup). At least one of q/participant/name/country/doctype must be supplied. |
| validate_eusr_reportA | Validate a Peppol End User Statistics Report (EUSR) document. Runs XSD structural validation, then Schematron business rules
(requires the |
| validate_tsr_reportA | Validate a Peppol Transaction Statistics Report (TSR) document. Runs XSD structural validation, then Schematron business rules
(requires the |
| validate_mls_messageA | Validate a Peppol Message Level Status (MLS) document. Runs the bundled MLS Schematron rules (requires the |
| build_mls_messageA | Build a document-level MLS response and return it base64-encoded. For per-line responses, build the document directly with
|
| list_country_codesA | List ISO 3166-1 alpha-2 country codes from the CEF EN 16931 code list. |
| check_country_codeA | Check whether code is a recognized ISO 3166-1 alpha-2 country code. |
| list_currency_codesA | List ISO 4217 currency codes from the CEF EN 16931 code list. |
| check_currency_codeA | Check whether code is a recognized ISO 4217 currency code. |
| list_icd_codesA | List ISO 6523 ICD codes from the CEF EN 16931 code list. |
| check_icd_codeA | Check whether code is a recognized ISO 6523 ICD code. |
| list_document_name_codesA | List UNCL1001 document name codes from the CEF EN 16931 code list. |
| check_document_name_codeA | Check whether code is a recognized UNCL1001 document name code. |
| list_reference_qualifier_codesA | List UNCL1153 reference qualifier codes from the CEF EN 16931 code list. |
| check_reference_qualifier_codeA | Check whether code is a recognized UNCL1153 reference qualifier code. |
| list_payment_means_codesA | List UNCL4461 payment means codes from the CEF EN 16931 code list. |
| check_payment_means_codeA | Check whether code is a recognized UNCL4461 payment means code. |
| list_vat_category_codesA | List UNCL5305 VAT category codes from the CEF EN 16931 code list. |
| check_vat_category_codeA | Check whether code is a recognized UNCL5305 VAT category code. |
| list_allowance_reason_codesA | List allowance reason codes from the CEF EN 16931 code list. |
| check_allowance_reason_codeA | Check whether code is a recognized allowance reason code. |
| list_item_type_codesA | List item type identification codes from the CEF EN 16931 code list. |
| check_item_type_codeB | Check whether code is a recognized item type identification code. |
| list_charge_reason_codesA | List charge reason codes from the CEF EN 16931 code list. |
| check_charge_reason_codeA | Check whether code is a recognized charge reason code. |
| list_mime_codesB | List recognized MIME types for embedded attachments. |
| check_mime_codeA | Check whether code is a recognized MIME type for embedded attachments. |
| list_eas_codesA | List Electronic Address Scheme (EAS) codes from the CEF EN 16931 code list. |
| check_eas_codeA | Check whether code is a recognized Electronic Address Scheme code. |
| list_vatex_codesA | List VATEX (VAT exemption reason) codes from the CEF EN 16931 code list. |
| check_vatex_codeA | Check whether code is a recognized VATEX VAT exemption reason code. |
| get_en16931_codelist_versionA | Report the CEF EN 16931 code-list release version(s) currently configured locally. |
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 50 tools
The tool set has many code list checking tools that follow a clear pattern (list_X_codes/check_X_code), which are distinct from the invoice processing tools. However, there are repeated tools (e.g., list_eas_codes appears twice in the provided list) and some closely related validation tools (TSR vs MLS vs EUSR) that could cause confusion.
Most tools follow consistent verb_noun patterns: check_, list_, get_, create_, validate_. There are minor deviations like `peppol_lookup_participant` and `resolve_peppol_dns` using different prefixes, but overall the naming is predictable and clear.
50+ tools is excessive, largely driven by repetitive list_x_codes/check_x_code pairs for each codelist. The core invoice functionality is only ~5 tools, while code-list helpers dominate the surface.
The invoice lifecycle is well covered with create/validate/convert/export, and Peppol lookup/send tools cover the main delivery flow. Missing operations like cancel or fetch invoice history are minor for the domain scope.