Conformo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Conformo creates, validates, converts and parses EN 16931 e-invoices (CII, UBL, XRechnung, Peppol BIS, Factur-X/ZUGFeRD PDF). Money is always integer minor units (EUR 12.34 = 1234). Typical flow: create_invoice (or create_invoice_pdf), then validate_invoice and report which rule sets ran. It does not transmit invoices over Peppol, a French PA, KSeF or SdI. It does not support FatturaPA or Facturae, and handles KSeF FA(3) only as domestic PLN invoices it writes and schema-checks (it cannot read them).
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_invoiceA | Builds e-invoice XML from structured invoice data: EN 16931 CII or UBL, XRechnung (CII or UBL) or Peppol BIS Billing 3.0, chosen by |
| create_invoice_pdfA | Builds a Factur-X / ZUGFeRD invoice: a PDF/A-3b page a person can read, with the EN 16931 XML embedded for software. Use it when the invoice goes to a person or by e-mail. For XML only, such as an XRechnung uploaded to a German public-sector portal, use create_invoice. Takes the same |
| validate_invoiceA | Checks an e-invoice against the official rule sets on this machine: the XSD, the EN 16931 Schematron from CEN, and the KoSIT XRechnung or Peppol BIS rules when the document declares them. Use it before sending an invoice you created and when you receive one. To read the invoice's data use parse_invoice; to explain one failed rule in depth use explain_validation_rule. Accepts XML or a Factur-X / ZUGFeRD PDF, whose embedded XML is checked; syntax and profile are detected from the document. A |
| convert_invoiceA | Rewrites an existing e-invoice in another syntax, for example CII to UBL, or plain EN 16931 to XRechnung or Peppol BIS. Use it when you already hold an invoice document. To build one from data use create_invoice; to get a PDF from XML use parse_invoice, then create_invoice_pdf. Accepts XML or a Factur-X / ZUGFeRD PDF. Nothing is invented: a target such as XRechnung may need data the source lacks, so read |
| parse_invoiceA | Reads an e-invoice (CII, UBL, XRechnung or Peppol XML, or a Factur-X / ZUGFeRD PDF) into the structured invoice object that create_invoice accepts, with money in integer minor units. Use it to answer questions about a received invoice, to edit one, or to re-issue it with create_invoice. It does not check any rules, so use validate_invoice for that, and convert_invoice to change syntax directly. For a PDF, |
| get_country_requirementsA | Looks up the e-invoicing rules for one country in a sourced dataset: B2G and B2B mandates for issuing and receiving, start dates, turnover thresholds, required formats and official sources. Use it before create_invoice to decide which format a buyer in that country needs, or to answer when a mandate applies. It says nothing about a specific invoice; use validate_invoice to check one. Covers BE, DE, ES, FR, IT, NL, PL. |
| explain_validation_ruleA | Explains one validation rule id, such as BR-CO-15, BR-DE-15, PEPPOL-EN16931-R003 or BR-FR-05: the publisher's official wording from the compiled rule sets and, where available, a plain-language summary, the reason for the rule and how to fix it. Use it after validate_invoice reports a rule you need to explain or fix, or when a user asks what a rule means. It does not check an invoice; call validate_invoice for that. An unknown id is not an error: the result has |
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 7 tools
Each tool has a narrowly distinct purpose, and the descriptions explicitly cross-reference siblings to steer selection (create_invoice vs create_invoice_pdf vs convert_invoice; validate_invoice vs explain_validation_rule vs parse_invoice; get_country_requirements is clearly advisory only). There is no pair an agent could plausibly confuse.
All seven names follow a consistent snake_case verb_noun pattern (create_, validate_, convert_, parse_, explain_, get_). The single compound suffix create_invoice_pdf follows the same convention and reads naturally alongside create_invoice.
Seven tools is tightly scoped to the e-invoicing lifecycle, with each tool earning its place: two creation targets (XML, PDF), parsing, conversion, validation, rule explanation, and country requirements. Nothing looks redundant or padded.
The surface covers the full document lifecycle: build (XML/PDF), read (parse), transform (convert), check (validate), explain failures, and decide format per country. Minor gaps remain, such as no tool to enumerate supported rule sets/profiles or to bulk-validate, but parse → edit → create covers the update case.