Skip to main content
Glama
Sign In
Conformo

Conformo

by arsalmurad
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Convert an e-invoice between syntaxes

convert_invoice
Read-onlyIdempotent

Convert an existing e-invoice between CII, UBL, XRechnung and Peppol BIS syntaxes, or from Factur-X/ZUGFeRD PDF, when you need the same invoice in another format.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
toYesOutput syntax. "cii" = UN/CEFACT CII, EN 16931 (Factur-X / ZUGFeRD EN 16931 profile, a.k.a. COMFORT); "cii-extended" = UN/CEFACT CII declared as Factur-X / ZUGFeRD EXTENDED (EN 16931 content only; no EXTENDED-only fields); "ubl" = UBL 2.1 Invoice or CreditNote, EN 16931; "xrechnung-cii" = XRechnung 3.x in CII syntax (German CIUS); "xrechnung-ubl" = XRechnung 3.x in UBL syntax (German CIUS); "peppol-ubl" = Peppol BIS Billing 3.0 (UBL); "ksef-fa3" = Polish KSeF FA(3), PLN domestic invoices only; written and schema-checked, never submitted.
xmlNoThe invoice as XML text (CII, UBL Invoice/CreditNote, XRechnung, Peppol BIS). Provide this OR pdfBase64.
pdfBase64NoA Factur-X / ZUGFeRD PDF/A-3 as base64; the embedded XML is used. Provide this OR xml.

Output Schema

NameRequiredDescriptionDefault
xmlYesThe invoice in the target syntax.
fromYesSyntax of the source: cii, ubl-invoice or ubl-credit-note.
formatYesThe syntax that was written.
warningsYesNon-fatal findings, e.g. data the target requires that the source does not have.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / format / description
      Added value: +"The syntax that was written."
    • addedOutput schema / properties / warnings / description
      Added value: +"Non-fatal findings, e.g. data the target requires that the source does not have."
    • addedOutput schema / properties / xml / description
      Added value: +"The invoice in the target syntax."
  2. First observedv0.2.1

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well past the readOnly/idempotent/non-destructive annotations: it warns that conversion invents nothing, that a target profile like XRechnung may lack required source data and surfaces `warnings`, and that unreadable documents return an error result with a reason. It also discloses local execution ("nothing is sent anywhere"), corroborating openWorldHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what the tool does, then alternatives, then input forms, then behavioral caveats and failure mode — a logical escalation with no filler. Each sentence supplies information the agent would otherwise have to infer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even though an output schema exists and return values needn't be spelled out, the description covers the parts that matter for a conversion tool: input acceptance, lossy-conversion risk, warning inspection, and error behavior. Nothing an agent needs in order to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the enum and per-parameter descriptions already carry the load, and the description correctly does not repeat them. It still adds useful framing that only one of xml or pdfBase64 is supplied and that Factur-X/ZUGFeRD PDFs are accepted as input, plus concrete example target syntaxes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Rewrites an existing e-invoice in another syntax") and grounds it with concrete conversions (CII to UBL, EN 16931 to XRechnung or Peppol BIS). An agent can immediately tell this apart from create_invoice or parse_invoice without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly scopes usage to when the caller "already hold[s] an invoice document" and routes the other cases: build from data → create_invoice, XML to PDF → parse_invoice then create_invoice_pdf. It also names the follow-up step (validate_invoice on the result) and the accepted input forms.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools