mcp-einvoicing-ae
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging level: DEBUG, INFO, WARNING, or ERROR | INFO |
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
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_invoice_aeA | Generate a PINT AE UBL 2.1 e-invoice XML document from structured data. Applies the correct CustomizationID (BT-24) and ProfileID (BT-23) for
the selected variant. All unconditionally-mandatory PINT AE elements
are emitted: Returns a dict with:
|
| validate_invoice_aeA | Validate a PINT AE UBL 2.1 invoice against the CEN EN16931 base Schematron. Checks the CEN EN16931 base rules (structural + arithmetic/totals,
~50 BR-* rules) via core's bundled, licensing-clean Schematron. Does
NOT check the PINT-AE jurisdiction overlay (ibr-*-ae rules) — the
result's metadata.scope is "en16931-base-only", and
EN16931_BASE_ONLY_SCOPE_WARNING is always included. BR-CO-09 is
expected to fire on every genuine AE invoice (see
EN16931_BASE_KNOWN_LIMITATIONS_WARNING, always included) since UAE
TRNs carry no ISO country prefix. This is not a full PINT AE
conformance check; a document that passes may still be rejected by a
real Peppol Access Point (no confirmed OpenPeppol redistribution
rights for the overlay rules).
Returns a structured result with per-rule error and warning messages.
The |
| validate_tdd_aeA | Validate a Peppol AE Tax Data Document (TDD). Always returns an explicit "unavailable" result — see module docstring and _TDD_VALIDATION_UNAVAILABLE for why no TDD validation is currently available. |
| parse_invoice_aeA | Parse a PINT AE UBL 2.1 XML invoice into a structured dict. Accepts a PINT AE billing or self-billing UBL 2.1 document (Invoice or CreditNote root), extracts the EN 16931 core field set plus the AE extensions (document_uuid, profile_execution_id, trade_license_number), and re-validates the merged result as an AEInvoice — so TRN format and tax-rate/category consistency are re-checked on parsed content, not just on freshly constructed invoices. Returns |
| 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_codelistB | Check whether a (scheme, value) pair is a recognized Peppol document type identifier. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| check_process_id_in_codelistB | 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. |
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 17 tools
The three network lookup tools (resolve_peppol_dns, peppol_lookup_participant, peppol_get_service_endpoint) layer on the same DNS/SMP pipeline and could be confused, though descriptions clearly delineate DNS-only vs registration vs endpoint retrieval. The codelist list_*/check_* families and the generate/parse/validate/send invoice tools are otherwise cleanly separated.
All names use snake_case, but the convention varies: most tools follow verb_noun (list_document_type_ids, check_process_id_in_codelist), while several network tools use a peppol_ prefix (peppol_send, peppol_get_service_endpoint) or a noun_verb order (peppol_directory_search). Overall readable and mostly predictable with minor deviations.
17 tools sits just above the ideal range and includes redundant families: three list_* and three check_* codelist tools that could be parameterized, plus three overlapping DNS/SMP lookup tools. Each tool is individually defensible, but the set feels heavier than necessary for this domain.
Core generate/parse/validate/send lifecycle is covered, but AE-specific validation is explicitly incomplete (no PINT-AE jurisdiction overlay rules, TDD validation always returns unavailable), and there is no inbound AS4 receipt or message handling. These are notable gaps for a full AE e-invoicing surface.