Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 format. Use it for a new invoice that software will read. For a printable PDF with the XML inside, use create_invoice_pdf; to change the syntax of an invoice you already have, use convert_invoice. Pass invoice as a JSON object, not a string. Every money field ends in "Minor" and is an integer in minor units (EUR 12.34 = 1234); totals and the VAT breakdown are computed, so do not send them. If fields are missing or wrong it returns an error listing every problem (path, BT id, message) and produces nothing; fix them all and call again. It runs locally and does not send the invoice anywhere. It does not run the official rule sets: call validate_invoice on the XML before it goes out.

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 invoice object as create_invoice, money in integer minor units. language changes only the printed labels; the embedded XML is identical in every language. By default the PDF comes back as base64, which can be large; pass outputPath to write the file instead. Writing stays inside the server's working directory and never replaces an existing file unless overwrite is true. The same input always gives the same bytes, and nothing is sent anywhere. Check the result with validate_invoice (pass pdfBase64).

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 valid result means the listed ruleSets passed, not that a tax authority or buyer will accept the invoice, so report which rule sets ran and never claim more. Each failure carries the publisher's message and, for common rules, a plain-language fix. Input that is not an invoice comes back as an error result, not as invalid. The check runs offline; nothing is uploaded.

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 warnings and run validate_invoice on the result. A document it cannot read comes back as an error result with the reason. Runs locally; nothing is sent anywhere.

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, visibleTotals shows whether the totals printed on the page match the embedded XML, which exposes a tampered or mismatched PDF. A document it cannot read comes back as an error result with the reason. Runs locally.

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. conformoSupport says per format whether this server can create, read and validate it. Entries marked unverified are not confirmed from an official source; say so. Information, not legal advice. Reads a bundled dataset; no network.

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 found false and an empty official list; say so and do not guess. Reads the bundled rule sets; no network.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.6/5.0

Scored across 7 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues