Skip to main content
Glama

InkVoice — XRechnung & E-Invoicing

by net.inkvoice
OverviewDiscussionsAdmin

Server Details

XRechnung and ZUGFeRD e-invoicing (EN 16931): create, validate, check Leitweg-IDs, German VAT.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.8% over 22 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.7/5.0

Scored across 5 tools

Disambiguation5/5

Each tool addresses a distinct step in the invoicing workflow: VAT arithmetic, Leitweg-ID validation, XRechnung generation, ZUGFeRD generation, and invoice validation. The two creation tools are the only close pair, but their descriptions clearly separate XML-for-public-sector from PDF-for-private-B2B.

Naming Consistency5/5

All names follow a consistent imperative verb_object pattern in snake_case: calculate_vat, check_leitweg_id, create_xrechnung, create_zugferd, validate_einvoice. There is no mixing of styles or vague generic verbs.

Tool Count5/5

Five tools is a well-scoped set for an e-invoicing helper: each tool covers a meaningful part of the create-and-validate workflow without redundancy. The count feels intentional rather than thin or bloated.

Completeness4/5

The core lifecycle is covered: calculate VAT, check the routing ID, create either XRechnung or ZUGFeRD, and validate an existing invoice. Minor gaps remain — single tax rate per invoice, no direct PDF/XML extraction for validation, and no submission/Peppol — but these are documented limitations and workable around.

Available Tools

5 tools
calculate_vatCalculate German VATA
Read-only
Inspect

Converts between net, tax and gross for a given VAT rate, in either direction.

Give an amount and say whether it is net or gross, and you get all three figures back rounded to the cent. Germany's rates are 19 % (standard) and 7 % (reduced), but any rate from 0 to 100 is accepted, so this also works for an Austrian or French invoice.

Rounding is half-away-from-zero, the convention invoices and tax authorities use, and the three returned figures always reconcile: net plus tax equals gross exactly, with no cent left over from rounding each separately.

What this does NOT do: it does not decide which rate applies to a supply, handle more than one rate at a time, or know anything about reverse charge, intra-community supply or the Kleinunternehmer rules. It is arithmetic, not tax advice.

ParametersJSON Schema
NameRequiredDescriptionDefault
rateYesVAT rate as a percentage, not a fraction: 19 means 19 %, not 1900 %.
basisYesWhether `amount` is the net figure (add tax to it) or the gross figure (take tax out of it).
amountYesThe amount to convert, in the invoice currency. Must not be negative.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark the tool read-only; the description adds meaningful behavioral detail beyond that: half-away-from-zero rounding, exact reconciliation of net + tax = gross, and acceptance of rates 0–100. It also honestly discloses that it is arithmetic, not tax advice.

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?

The purpose is front-loaded in the first sentence, followed by usage, behavioral guarantees, and limitations. The paragraphs are dense but every sentence contributes; there is no fluff or repetition of schema details.

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 without an output schema, the description tells the agent that all three figures are returned, rounded to the cent, and reconcile. It also covers edge acceptance and exclusions, making it complete for a simple arithmetic conversion tool.

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 adds extra meaning by explaining the valid rate range (0–100) and how `basis` controls whether tax is added or removed, going slightly beyond the schema descriptions.

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: 'Converts between net, tax and gross... in either direction.' It clearly scopes the tool to arithmetic VAT conversion and distinguishes itself from siblings by stating what it does NOT do (rate selection, tax advice).

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

Usage Guidelines4/5

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

Clear context is given for when to use the tool, and the 'What this does NOT do' section provides explicit exclusions such as reverse charge and rate determination. It stops short of naming sibling tools as recommended alternatives, so it misses the top score.

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

check_leitweg_idCheck a Leitweg-IDA
Read-only
Inspect

Checks a German Leitweg-ID — the routing identifier that goes in BT-10 of an XRechnung to a public authority. An invoice to a German public body with a wrong or missing Leitweg-ID is rejected, so this is worth checking before building a document.

It verifies the structure (Grobadressierung of 2 to 12 digits, an optional Feinadressierung of up to 30 alphanumerics, then two check digits) and recomputes the ISO/IEC 7064 MOD 97-10 check digit, the same procedure an IBAN uses. When the check digits are wrong it returns the ones the address parts actually imply, so the value can be corrected rather than merely rejected. It also names the Bundesland the leading two digits point at, or Bund for the federation.

One real limit: the check digit is computed over the address parts with the hyphens removed, which is what KoSIT specifies, so it CANNOT detect a hyphen in the wrong place. '04011000-1234512345-06' and '040110001-234512345-06' both pass. That is the specification's behaviour, not a defect here.

What this does NOT do: it does not confirm that the ID belongs to a real authority or that they are reachable. It checks the number, not the recipient — there is no directory lookup.

ParametersJSON Schema
NameRequiredDescriptionDefault
leitwegIdYesThe Leitweg-ID, e.g. '04011000-1234512345-06'. Surrounding whitespace is ignored.

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint annotation, explaining the exact verification algorithm, the ISO/IEC 7064 MOD 97-10 check-digit procedure, the hyphen-placement limitation with concrete examples, and the fact that it returns implied check digits for correction. It is exceptionally transparent about edge-case behavior.

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?

The description is longer than average, but every section earns its place: main purpose, verification behavior, a critical limitation with examples, and explicit non-goals. It is front-loaded with the essential purpose and remains highly readable despite the technical detail.

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 without an output schema, the description states the key outputs: pass/fail on structure and check digits, the implied check digits when wrong, and the Bundesland derived from leading digits. For a single-parameter, deterministic check tool, this fully equips an agent to invoke it correctly and interpret results.

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?

The schema already describes the single parameter with an example and whitespace handling, giving a baseline of 3. The description adds genuine value by detailing the accepted structure, the check-digit computation, and the hyphen-sensitivity limitation, which helps the agent understand what values are valid and what the check actually covers.

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?

The description uses a specific verb and resource: it 'checks' a German Leitweg-ID, verifies its structure, and recomputes the check digit. It clearly distinguishes itself from broader invoice tools by stating exactly what it does not do, such as confirming the ID belongs to a real authority.

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

Usage Guidelines4/5

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

The description gives clear when-to-use context: check before building an XRechnung because a wrong or missing Leitweg-ID causes rejection. It also gives explicit when-not-to-use guidance by stating it does not validate the recipient or perform directory lookups, though it does not name a specific sibling tool as the alternative.

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

create_xrechnungCreate an XRechnungA
Read-only
Inspect

Builds a German XRechnung 3.x electronic invoice (EN 16931, CII syntax) from invoice details and returns the XML as text. This is the format German public-sector buyers are legally required to receive, and that many private B2B buyers now ask for.

The EN 16931 business rules are checked before anything is built, and a rejected call comes back naming the rules that failed and the business term (BT-xx) each concerns. The ones worth getting right up front: tax category S requires a rate above 0 %, categories Z, E and AE require exactly 0 %, E and AE additionally require a stated exemption reason (BT-120), and both parties need an email address because XRechnung makes the electronic address (BT-34, BT-49) mandatory. For a public-sector buyer, put their Leitweg-ID in buyerReference (BT-10) — check_leitweg_id will verify it first.

What this does NOT do:

  • It does not validate against the KoSIT Prüftool. It applies our reading of EN 16931, which is not the same thing as the Schematron suite a receiving portal runs. Use validate_einvoice for a second look, and the official validator before a deadline.

  • It does not produce ZUGFeRD or Factur-X. There is no PDF and no embedded XML — this is a bare XML file. Use create_zugferd for the hybrid a private-sector B2B buyer usually wants.

  • It handles ONE tax rate and one tax category for the whole invoice. A document mixing 19 % and 7 % lines is not expressible here.

  • It does not send the invoice anywhere, and there is no Peppol.

Nothing is stored: no account, no invoice record, no retained personal data.

ParametersJSON Schema
NameRequiredDescriptionDefault
invoiceYesThe invoice to turn into an XRechnung document.

TDQS

A4.9/5.0
Behavior5/5

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

The description goes far beyond the spare annotations by disclosing non-obvious behavior: validation rules are enforced before building, rejected calls name failed BT-xx rules, only one tax rate is supported, no PDF is produced, nothing is transmitted, and nothing is stored. It also honestly notes that this is not equivalent to the official Schematron validation.

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?

Although long, the description is dense and well-structured: purpose first, then validation constraints, then a clear 'What this does NOT do' section, then a privacy/storage note. The bullet-like sections make the non-obvious limitations easy to scan, and no sentence feels wasted.

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?

For a complex tool with nested parameters and no output schema, the description covers the essential operational context: output format, error behavior, legal context, key input constraints, exclusions, and side-effect guarantees. An agent has enough information to decide when to call this tool and what to expect back.

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 high, so the baseline is 3, but the description adds meaningful guidance for key fields: taxCategoryCode/taxRate/taxExemptionReason relationships, mandatory email for both parties, and buyerReference as the Leitweg-ID for public-sector buyers. It does not individually explain every nested field, but the most legally sensitive parameters receive concrete semantic context.

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?

The description opens with a specific verb and resource: it builds a German XRechnung 3.x electronic invoice in EN 16931/CII syntax and returns XML as text. It also distinguishes this tool from siblings by explicitly stating what it does not do, such as creating ZUGFeRD/Factur-X or validating against the KoSIT Prüftool.

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?

Usage guidance is explicit and actionable: it names check_leitweg_id for verifying Leitweg-IDs, validate_einvoice for a second validation look, and create_zugferd for private-sector hybrid invoices. It also gives context about when XRechnung is legally required, making the selection criteria clear.

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

create_zugferdCreate a ZUGFeRD / Factur-X invoiceA
Read-only
Inspect

Builds a ZUGFeRD 2.x / Factur-X hybrid invoice from the same details create_xrechnung takes, and returns it as a PDF file.

A hybrid is one invoice stated twice in one file: a PDF/A-3 document a person reads, carrying the same invoice inside it as EN 16931 XML a machine books. This is the format private-sector German B2B buyers generally want, where XRechnung is what public bodies require. If the recipient is a public authority and gave you a Leitweg-ID, you want create_xrechnung instead.

The embedded XML declares plain EN 16931 — the profile ZUGFeRD calls COMFORT — not the XRechnung CIUS, because that CIUS is a statement about public-sector procurement.

Validation is identical to create_xrechnung: the same EN 16931 rules are applied before anything is built, and a rejected call names the rules and business terms that failed.

What this does NOT do:

  • The result is a binary PDF returned as an attachment. It is not text and there is nothing useful to read in it — do not try to quote or summarise its contents. Offer it to the user as a file.

  • It does not validate against veraPDF or the Mustangproject validator. The document is built to be valid PDF/A-3 with the required Factur-X metadata, but that is our reading rather than a validator's verdict.

  • It handles ONE tax rate and one tax category for the whole invoice, exactly as create_xrechnung does.

  • It does not send the invoice anywhere, and there is no Peppol.

  • There is no logo and no custom styling. The PDF uses the default invoice layout.

Nothing is stored: no account, no invoice record, no retained personal data.

ParametersJSON Schema
NameRequiredDescriptionDefault
invoiceYesThe invoice to turn into a ZUGFeRD / Factur-X document.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only provide readOnlyHint=true and openWorldHint=false, but the description adds substantial behavioral detail: the result is a binary attachment that must be offered as a file rather than quoted or summarized, validation is performed but not via veraPDF/Mustangproject, only one tax rate/category is supported, and nothing is stored. This corroborates the readOnly annotation by explaining what 'read-only' means here, rather than repeating it.

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?

The core purpose is front-loaded in the first sentence and the structure is logical: purpose, format explanation, compliance profile, exclusions, side-effect profile. It is verbose, but nearly every section carries distinct operational value; minor redundancy exists in repeating 'exactly as create_xrechnung does' and in over-explaining the hybrid concept.

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?

For a tool with a deeply nested schema and no output schema, the description covers return-value handling (binary PDF, offer as file), validation-failure behavior (names the rules and business terms), tax-rate limits, delivery/sending behavior, and storage side effects. An agent has everything needed to invoke it correctly and set user expectations about the output.

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

Parameters3/5

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

Schema description coverage is 100% for the single invoice parameter, so the baseline is 3. The description adds the cross-reference that it takes 'the same details create_xrechnung takes' and discloses the one-tax-rate/one-tax-category constraint, but it does not add per-field meaning beyond the schema.

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 a ZUGFeRD 2.x / Factur-X hybrid invoice from the same details create_xrechnung takes, and returns it as a PDF file.' It explicitly names the sibling create_xrechnung and explains the distinguishing factor (private-sector B2B vs public-sector XRechnung), so an agent can tell them apart from the description alone.

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 when explicitly — 'private-sector German B2B buyers generally want' this format — and the when-not with a concrete decision rule: 'If the recipient is a public authority and gave you a Leitweg-ID, you want create_xrechnung instead.' The exclusions list (no Peppol, no sending, no veraPDF validation) further prevents accidental misuse.

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

validate_einvoiceCheck an e-invoiceA
Read-only
Inspect

Reads an existing electronic invoice and reports what is wrong with it. Accepts XRechnung and ZUGFeRD XML in either EN 16931 syntax — CII (used by XRechnung and ZUGFeRD) and UBL — and reports the syntax and profile it found along with the invoice's key fields, so it also answers "what is this file?".

It checks the rules behind most real rejections: BT-10 buyer reference present, and its Leitweg-ID check digit when it looks like one; BT-34 and BT-49 electronic addresses present; tax category S not used at 0 %; BT-120 exemption reason present for categories E and AE; line amounts summing to BT-106; net plus tax equalling the BT-112 gross; BT-115 amount due matching gross less prepaid; and the due date not falling before the issue date.

What this does NOT do:

  • It is NOT the KoSIT Prüftool and is not a substitute for it. It covers the rules that account for most rejections, not the full EN 16931 Schematron suite. A file that passes here can still be rejected by a Rechnungseingangsportal.

  • It does not check the XSD schema, so a structurally invalid document may parse here.

  • It reads XML only. A ZUGFeRD PDF must have its embedded XML extracted first — pass the XML, not the PDF.

Nothing is stored: the document is parsed in memory and discarded.

ParametersJSON Schema
NameRequiredDescriptionDefault
xmlYesThe full XML text of the invoice. For ZUGFeRD, the XML extracted from the PDF, not the PDF itself.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark readOnlyHint=true, but the description adds meaningful behavioral detail: 'Nothing is stored: the document is parsed in memory and discarded.' It also discloses limitations (not XSD validation, not full EN 16931 Schematron suite) and an important nuance: a file that passes can still be rejected by a portal. This goes well beyond the annotation.

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?

The description is long but well-structured and front-loaded with the core purpose. It uses a clear 'What this does NOT do' section and bullet-like lists. Every sentence carries useful information, though the detailed enumeration of checked rules (BT-10, BT-34, etc.) could be considered verbose for an AI agent. Still, it is appropriately sized for a complex validation tool.

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?

For a tool that validates complex e-invoices, the description is remarkably complete. It covers accepted input formats, the specific rules checked, limitations and exclusions, behavioral side effects (memory-only, no storage), and what the output will contain ('reports the syntax and profile it found along with the invoice's key fields'). No gaps remain that would prevent correct selection and invocation.

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

Parameters5/5

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

Schema coverage is 100% and the single 'xml' parameter is well described. The description adds substantial meaning: it accepts XRechnung and ZUGFeRD XML in EN 16931 syntax (CII and UBL), clarifies the input must be the extracted XML not the PDF, and explains what the tool does with that XML. This goes far beyond the schema's basic description.

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?

The description opens with a specific verb and resource: 'Reads an existing electronic invoice and reports what is wrong with it.' It also clarifies it identifies syntax/profile and key fields, answering 'what is this file?'. This clearly differentiates it from siblings like create_xrechnung and check_leitweg_id, and the 'What this does NOT do' section further distinguishes it from the official KoSIT Prüftool.

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

Usage Guidelines4/5

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

Provides explicit when-not: it is not the KoSIT Prüftool, does not check XSD schema, and reads XML only (not ZUGFeRD PDFs). It also states a passing file may still be rejected by a Rechnungseingangsportal. However, it does not explicitly mention sibling tools like check_leitweg_id when the task is only a Leitweg-ID check, so it lacks direct alternative routing.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedcreate_xrechnung1 field changed
      • addedInput schema / properties / invoice / properties / deliveryDate
        Added value: +{
+  "default": null,
+  "format": "date",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • Changedcreate_zugferd1 field changed
      • addedInput schema / properties / invoice / properties / deliveryDate
        Added value: +{
+  "default": null,
+  "format": "date",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. 1 tool update
    • Addedcreate_zugferd
  3. 4 tool updates
    • First observedcalculate_vat
    • First observedcheck_leitweg_id
    • First observedcreate_xrechnung
    • First observedvalidate_einvoice

Related MCP Connectors

Related MCP Servers

  • beliq-mcp by beliq-eu

    beliq-mcpofficial

    beliq-eu
    A
    license
    A
    quality
    D
    maintenance
    Validates electronic invoices (XRechnung, ZUGFeRD, Factur-X, Peppol BIS, etc.) against authority-pinned rules and explains failures.
    2
    151 npm
    MIT

  • einvoice-mcp

    makririch
    A
    license
    A
    quality
    D
    maintenance
    MCP server for DACH e-invoicing. Create XRechnung (UBL) and ZUGFeRD 2.3 (Factur-X CII) invoices, validate against EN 16931 rules, extract data from XML, and convert between UBL, CII and JSON formats.
    6
    74 npm
    2
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources