Conformo

Overview Schema Source Related Servers Discussions Admin

Create an e-invoice (XML)

create_invoice

Read-onlyIdempotent

Build e-invoice XML from structured invoice data for EN 16931 CII/UBL, XRechnung, Peppol BIS Billing 3.0, or KSeF FA(3) so software can process new invoices.

Instructions

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.

Input Schema

Name	Required	Description	Default
`format`	Yes	Output 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.
`invoice`	Yes	The invoice. Required: number, issueDate, currency, seller, buyer, lines.

Output Schema

Name	Required	Description
`xml`	Yes	The e-invoice XML, ready to send or to pass to validate_invoice.
`format`	Yes	The syntax that was written.
`warnings`	Yes	Non-fatal findings, e.g. a missing XRechnung precondition.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026
- addedOutput schema / properties / format / description
```
Added value: +"The syntax that was written."
```
- addedOutput schema / properties / xml / description
```
Added value: +"The e-invoice XML, ready to send or to pass to validate_invoice."
```
First observedv0.2.1Nov 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/local, and the description adds substantive behavior beyond them: the tool runs locally and sends nothing, a failure is atomic ("produces nothing") and returns an error enumerating every problem by path, BT id and message. It also discloses a real limitation not in any annotation — the official rule sets are not run, so validate_invoice must be called separately.

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

Conciseness4/5

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

Six tight sentences, front-loaded with purpose then routing then input conventions then failure behavior. No filler, though the minor-units and computed-totals guidance partially repeats per-field schema descriptions and could be trimmed to one clause.

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

Completeness4/5

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

For a two-parameter tool wrapping a very large nested schema with an output schema available, the description covers the essentials: format choice, input conventions, atomic failure, locality, and the validation handoff. It does not mention format-specific field requirements (XRechnung mandatory seller contact, Peppol/France electronic address), but those are documented in the schema itself.

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 baseline is 3; the description earns an extra point by stating conventions that matter at call time but are easy to miss across a 100-field schema: `invoice` is an object not a JSON string, every money field is an integer in minor units, and totals/VAT breakdown must not be sent because they are computed.

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?

Opens with a specific verb and resource ("Builds e-invoice XML from structured invoice data") and enumerates the supported syntaxes (EN 16931 CII/UBL, XRechnung, Peppol BIS 3.0) selected by `format`. It explicitly differentiates itself from create_invoice_pdf and convert_invoice, so the agent can choose 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?

States the use case ("for a new invoice that software will read") and names three alternatives with the exact condition that selects each: create_invoice_pdf for PDF, convert_invoice for changing syntax, validate_invoice before sending. When-to-use, when-not-to-use, and alternatives are all present.

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

Deploy Server