Factur-X: Generate & Validate E-Invoices

by io.github.LeBorgneAntoine

Overview Discussions Admin

Server Details

Validate Factur-X, CII & UBL e-invoices free, no key. Generate compliant invoices from JSON.

Ownership verified

Status: Healthy
Uptime: 95.6% over 45 days
Last Tested: 2026-10-15 09:56
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.7/5.0

Scored 2026-10-03 11:25 across 10 tools

Disambiguation5/5

Each tool targets a distinct operation, and the descriptions actively cross-reference each other to steer selection (e.g. check_party for one party vs check_invoice_parties for both; validate_invoice for a user document vs view_invoice_demo for synthetic samples). Boundaries are unusually well drawn, leaving little room for misselection.

Naming Consistency5/5

All ten tools use a clean snake_case verb_noun convention (check_party, generate_invoice, validate_invoice, extract_invoice, embed_xml, draft_credit_note). The pattern is predictable and readable throughout.

Tool Count5/5

Ten tools fit the generate-and-validate scope precisely: generation, validation, extraction, embedding, credit notes, party checks, guidance, examples, and a demo. No tool appears redundant or bolted on.

Completeness4/5

The surface covers the full lifecycle: examples, party verification, generation (PDF/CII/UBL), validation, extraction, credit notes, embedding, and finding explanations. Minor gaps (no explicit revision/re-issue workflow beyond regeneration, no delivery step) are intentional and documented.

Available Tools

10 tools

check_invoice_partiesCheck seller and buyer togetherA

Read-onlyIdempotent

Inspect

Check a supplied seller AND buyer together, returning combined readiness and separate evidence.

Use before generate_invoice; use check_party for one party and validate_invoice for document rules.
Each party needs siren, siret or vat; siret wins over siren. French identifiers or country_code=FR
require SIREN/SIRET; a French lookup can derive omitted vat. Address fields activate address checks.
requester_vat applies to both lookups but cannot replace either party's vat. Roles follow seller/buyer
argument names; no invoice lines or full invoice body is needed.

Makes at most two EU Verify requests with the caller's plan key; Pro/Scale enable register access.
Returns status and parties.seller/buyer, each with status, reasons and available evidence. Only two
positive results yield invoice_ready; any not_ready yields not_ready, otherwise inconclusive.
Inspect both results: denied plans, invalid input, quotas and outages never establish readiness.
No document quota is consumed; upstream limits still apply per lookup. Results may change on retry.
No invoice is generated, stored or sent.

ParametersJSON Schema

Name	Required	Description
`buyer`	Yes	Buyer's registry identifiers and optional checks.
`seller`	Yes	Seller's registry identifiers and optional checks.
`requester_vat`	No	Your VAT number for VIES request evidence.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, openWorld), and the description adds substantial operational detail beyond them: at most two EU Verify requests, plan-key usage, Pro/Scale register access, no document quota consumed, upstream per-lookup limits, results may change on retry, and that no invoice is generated/stored/sent.

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?

Front-loaded with purpose, then usage, then behavior; every sentence carries information. It is dense and long, but the density is justified by the tool's complexity rather than padding.

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 two-party verification tool with a nested schema and an output schema, the description covers inputs, precedence, request semantics, and the readiness decision logic (two positives yield invoice_ready; any not_ready yields not_ready; otherwise inconclusive) including how denied plans/quotas/outages factor in. Nothing essential is missing.

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% (baseline 3), but the description adds real precedence and derivation logic absent from the schema: siret wins over siren, French identifiers/country_code=FR require SIREN/SIRET, a French lookup can derive omitted vat, address fields activate address checks, and requester_vat cannot replace either party's vat.

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+resource scope ('Check a supplied seller AND buyer together, returning combined readiness and separate evidence') and implicitly contrasts with its sibling check_party by emphasizing the paired scope. An agent can distinguish it from single-party and document-rule tools without opening the 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 routes the caller: 'Use before generate_invoice; use check_party for one party and validate_invoice for document rules.' It names both alternatives and the conditions that select them, leaving nothing to inference.

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

check_partyCheck one invoice partyA

Read-onlyIdempotent

Inspect

Check exactly one seller or buyer's registry identifiers and readiness through EU Verify.

Use to correct one party's identifiers; use check_invoice_parties to check seller and buyer together,
or validate_invoice for document rules.
Supply siren, siret or vat; siret wins over siren. A SIREN/SIRET, country_code=FR or FR VAT triggers
French checks requiring a SIREN/SIRET. Omitted vat can be derived from a successful French lookup;
foreign parties normally need explicit VAT. Send address fields with a coherent country_code;
requester_vat cannot substitute for the checked party's vat.

Sends supplied fields to EU Verify and applicable registers. A Pro/Scale key enables checks;
other plans return plan_excluded. No Factur-X document quota is consumed.
Returns status, reasons with field pointers and available evidence: invoice_ready is positive,
not_ready needs correction, upstream_unavailable is inconclusive and retryable, invalid_input
indicates rejected input. Register results and evidence ids may change between calls.
No invoice is created or stored.

ParametersJSON Schema

Name	Required	Description	Default
`vat`	No	Party's EU VAT number, for example FR40732829320.
`city`	No	City, checked with the address.
`eori`	No	EORI. Checked only when you send it.
`iban`	No	Party IBAN. Checked only when you send it.
`role`	No	Party role recorded in the evidence; defaults to buyer.	buyer
`siren`	No	9-digit French SIREN, including leading zeros.
`siret`	No	14-digit French SIRET, including leading zeros.
`address`	No	Street line; any address, postal_code or city activates address checking.
`postal_code`	No	Postal code, checked with the address.
`country_code`	No	ISO 3166-1 alpha-2 country code, for example FR or DE.
`requester_vat`	No	Your VAT number, so the evidence pack can include a VIES request identifier.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

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

With annotations only covering read-only/open-world/idempotent, the description adds substantial context they don't: fields are sent to EU Verify and applicable registers, a Pro/Scale key is required (other plans return plan_excluded), no Factur-X quota is consumed, no invoice is stored, and results may drift across calls. It even decodes the status vocabulary (invoice_ready, not_ready, upstream_unavailable, invalid_input).

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?

Front-loaded with purpose then alternatives, then rules, then behavior. The dependency/precedence block is dense, but every sentence carries information an agent needs; only minor tightening is possible.

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 an 11-param external-check tool with an output schema, the description covers plan gating, quota, side-effect absence, status semantics, and identifier resolution rules. Nothing required to call it 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 baseline is 3, but the description adds real precedence/derivation semantics not in the schema: siret wins over siren, omitted vat can be derived from a successful French lookup, foreign parties need explicit VAT, country_code=FR triggers French checks, and requester_vat cannot substitute for the checked party's vat.

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 (check) and resource (exactly one seller or buyer's registry identifiers) plus the backing service (EU Verify). It explicitly contrasts with check_invoice_parties, so the agent can distinguish the two single-vs-batch tools without opening a 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?

Names the exact alternatives and the condition selecting each: check_invoice_parties for seller+buyer together, validate_invoice for document rules. It also states the trigger conditions ('use to correct one party's identifiers') rather than leaving usage to inference.

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

draft_credit_noteDraft a full or partial credit noteA

Read-onlyIdempotent

Inspect

Draft a type-381 credit note from an existing invoice, for all lines or selected quantities.

Use to reverse an existing invoice's charges; use get_invoice_example for a synthetic credit-note example.
invoice must be the original generate_invoice input object, not extract_invoice output.
number and issue_date belong to the new credit note; the original number/date are copied into
preceding_invoices. Give number a distinct value and use YYYY-MM-DD dates. due_date replaces the
original deadline; omitting it removes that deadline rather than inheriting it.

Omit credit_lines to retain all original lines and amounts. Otherwise select distinct 1-based array
positions, not line ids: [{"line_index":1,"quantity":"2"}] credits two units of the first line.
Omitted lines are excluded; quantities cannot exceed the original. Prices and VAT rates are retained.
Selected-line mode clears original totals, prepayments, rounding and paid status for recalculation.
Document allowances/charges, or reduced quantities on adjusted lines or overridden net amounts,
need explicit allocation: these cases return an error; prepare a credit body for generate_invoice.
No prior-credit history is stored: the caller must prevent cumulative credits beyond the original.
Keep amounts positive: type 381 expresses the credit. Existing credit notes, a reused invoice number
or negative line amounts produce a tool error. Default payment remittance references follow the
new number; a custom reference is preserved. Returns invoice, type_code, preceding_invoice and next.
Pass the returned invoice to generate_invoice with the original profile to create the document.
No key or document quota is needed for drafting; nothing is stored, sent or refunded.

ParametersJSON Schema

Name	Required	Description
`number`	Yes	Credit note number, different from the invoice number. Max 35 characters: letters, digits, and . _ / -.
`invoice`	Yes	The original invoice object you passed to generate_invoice. Not an extract_invoice result.
`due_date`	No	Optional due date. Omit it to drop the original invoice due date.
`issue_date`	Yes	Credit note issue date, ISO 8601 (YYYY-MM-DD).
`credit_lines`	No	Selected original line positions and quantities. Omit for a full credit; an empty list is invalid.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnlyHint/idempotentHint/openWorldHint); the description adds substantial behavior: nothing is stored, sent or refunded, no key or document quota needed, omitted due_date removes the deadline rather than inheriting it, selected-line mode clears totals/prepayments/rounding/paid status, and specific error conditions (existing credit notes, reused number, negative amounts, allocation cases). These disclosures go well beyond the annotations.

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?

Purpose is front-loaded in the first sentence and every subsequent sentence adds a distinct rule (mode selection, identifier handling, allocation errors, idempotency caveat). It is long at roughly ten sentences, but dense rather than padded; a tighter grouping of the error conditions would improve it.

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, nested-object tool with an output schema, the description covers mode selection, identifier/date handling, recalculation side effects, error cases and the hand-off to generate_invoice. An agent has everything needed to invoke it correctly without inferring.

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, but the description adds non-obvious semantics: number/issue_date belong to the new note while the original values are copied into preceding_invoices, credit_lines use distinct 1-based array positions (not ids, with a worked example), omitted lines are excluded, quantities cannot exceed the original, and prices/VAT are retained. Some of this now duplicates schema text, which slightly caps the score.

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, resource and regulatory type ('Draft a type-381 credit note from an existing invoice') plus the two operating modes (all lines or selected quantities). It also names the sibling tools it relates to (get_invoice_example, generate_invoice, extract_invoice), so an agent can place it precisely among the siblings.

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 routes: 'Use to reverse an existing invoice's charges; use get_invoice_example for a synthetic credit-note example', and directs the caller to 'prepare a credit body for generate_invoice' when allocation cases arise. It also states when not to rely on it ('No prior-credit history is stored: the caller must prevent cumulative credits').

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

embed_xmlEmbed CII XML into a PDF

Read-onlyIdempotent

Inspect

Combine a visual PDF you already have with CII XML into one Factur-X PDF/A-3.

Use for an existing visual invoice; use generate_invoice to render invoice data or produce UBL.
Match the PDF's parties, lines and totals to xml yourself: check examines only XML and cannot detect
disagreement with the visible PDF. The embedded profile comes from xml; neither check nor language
changes it. language does not translate the PDF.

Invalid input or failed rules return a tool error with no file; rule errors include ids. For a
findings report use validate_invoice. Success returns a JSON summary (profile, size_bytes, warning
count) and a base64 PDF/A-3 resource. Requires a trial, prepaid or subscription allowance via OAuth or key; success consumes one document, errors
consume none. Nothing is stored or sent.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	Yes	Unencoded CII XML text (Factur-X / EN 16931); UBL is not supported.
`check`	No	XML validation rules: fr-ctc adds French BR-FR-* to EN 16931; base uses EN 16931 only.	fr-ctc
`language`	No	Language written in the PDF metadata: fr (default) or en.	fr
`pdf_base64`	Yes	Standard base64 of PDF bytes starting with %PDF-. Not a URL or data-URI.

explain_findingExplain a validation findingA

Read-onlyIdempotent

Inspect

Turn a validation rule id into the invoice field to change and an example value.

Use after validate_invoice or a generate_invoice rule error, not to validate an invoice itself.
rule is trimmed and uppercased to select a guide entry. message/json_pointer must come from that
same finding: nonempty values override its generic context, but never change the selected fix or
example. Omit them to use guide defaults for known rules.

Returns rule, known, message, json_pointer, fix and example; known rules also include problem.
Selected BR-FR rules and BR-CO-17/BR-CO-26 have guidance.
Unknown ids return known=false and example=null with the supplied context, not an error; consult
the original finding. No key or document quota is needed; nothing is stored.

ParametersJSON Schema

Name	Required	Description
`rule`	Yes	Validation rule identifier, for example BR-FR-01 or BR-CO-26.
`message`	No	Original finding's message text.
`json_pointer`	No	Original finding's json_pointer field path.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/no-key requirements, yet the description adds substantial behavior: rule ids are trimmed and uppercased before lookup, supplied message/json_pointer override generic context but never change the selected fix or example, unknown ids return known=false rather than an error, and nothing is stored. That is real disclosure beyond the structured hints.

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?

Front-loaded with the core transformation and the usage exclusion, and each sentence carries distinct information. It is dense — three tightly packed paragraphs — but no sentence is filler, so it stays just short of maximal.

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?

Given a 3-parameter tool with an output schema, the description covers trigger, exclusions, parameter normalization, override rules, unknown-id behavior, and the storage/quota profile. Nothing an agent needs to call it correctly is absent.

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, but the description adds genuine semantics: normalization of 'rule', the requirement that message/json_pointer come from the same finding, the override-vs-default behavior, and what happens when they are omitted. It stops short of full coverage only because the returned fields are enumerated rather than the inputs elaborated further.

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 precise verb and resource — 'Turn a validation rule id into the invoice field to change and an example value' — which is unmistakable against siblings like validate_invoice or generate_invoice. It also explicitly says it does not validate an invoice itself, separating it from validate_invoice.

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?

Gives an explicit trigger ('Use after validate_invoice or a generate_invoice rule error') and an explicit exclusion ('not to validate an invoice itself'). The alternative is named and the selecting condition is stated, leaving nothing to inference.

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

extract_invoiceExtract e-invoice data

Read-onlyIdempotent

Inspect

Extract invoice parties, dates, lines, totals and VAT as JSON for bookkeeping or matching.

Use validate_invoice for compliance; this performs no OCR or recalculation. Supply one source:
nonblank xml overrides document_base64 without inspecting it, so omit xml to extract a PDF's
attachment. include_xml returns that selected source for archiving or validation, not XML
reconstructed from fields. Extracted fields need mapping before use as generate_invoice input.

Returns fields and format/profile metadata, plus PDF metadata for PDF input. Missing business values
remain null; numeric values are strings. Missing input, invalid base64, malformed/unrecognized XML
or a PDF without embedded XML returns a tool error, not an empty extraction.
Requires a trial, prepaid or subscription allowance via OAuth or API key; success consumes one
operation, errors consume none. Nothing is stored or sent.

ParametersJSON Schema

Name	Required	Description
`xml`	No	CII or UBL XML as unencoded text.
`include_xml`	No	Include source XML text in the result; this can substantially increase response size.
`document_base64`	No	Standard base64 of a Factur-X PDF, CII XML or UBL XML file; no data-URI prefix.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

generate_invoiceGenerate an EN 16931 invoice

Read-onlyIdempotent

Inspect

Create an EN 16931 e-invoice from structured data: Factur-X PDF/A-3, CII XML, or UBL 2.1 XML.

Use when you have the parties, lines and dates and need the document. To revise one, correct the input
and regenerate; save and deliver the returned file through your own system. Do not use when you already have a
visual PDF and CII XML: call embed_xml. To check a document you did not create here, call validate_invoice;
to read one, call extract_invoice.

Start invoice from get_invoice_example, replacing sample parties and dates. Leave totals and line
net_amount omitted to compute them from quantities, prices, allowances and charges. For ubl-xml,
profile must be en16931 or extended-ctc-fr; extended and basicwl are CII/PDF-only. profile selects
the XML model while check selects validation rules: use check=base for non-French invoices;
changing check does not disable party_check. language and footer_text affect only the visual PDF.

Omitted party_check enables registry checks only for extended-ctc-fr; true/false explicitly
overrides that default. Enabled checks send party identifiers/address and seller IBAN to EU Verify.
A not_ready verdict blocks output with field pointers. Successful checks add evidence ids;
registry outages do not block generation and are reported as warnings, not proof of readiness.
XSD/business-rule failures return a tool error with rule ids; fix the input and retry.

Requires an authenticated trial, prepaid or subscription allowance (OAuth or API key).
Each successful result uses one document operation, including repeated calls.
Returns a JSON text summary (totals, warnings, evidence) and an embedded resource: base64 PDF
or XML text. No invoice is stored or sent to a recipient.

ParametersJSON Schema

Name	Required	Description	Default
`check`	No	Rule set the output must pass before it is returned: fr-ctc (default) = EN 16931 + French CTC rules (BR-FR-*), base = EN 16931 only (non-French sellers).	fr-ctc
`output`	No	facturx-pdf (default): PDF/A-3 with the visual invoice and CII XML inside, the hybrid file French platforms accept. cii-xml: UN/CEFACT CII XML alone. ubl-xml: UBL 2.1 XML alone.	facturx-pdf
`invoice`	Yes	Invoice data: seller, buyer, lines, dates, payment terms. Amounts are decimal strings ("1200.00"), dates ISO 8601. Totals and the VAT breakdown are computed. Full JSON Schema in the resource facturx://schema/invoice.
`profile`	No	EN 16931 conformance level written in the XML: en16931 (default, full semantic model), extended (optional business terms), extended-ctc-fr (French B2B mandate; parties are checked before the file is emitted), basicwl (no lines)	en16931
`language`	No	Language of the visual PDF: fr (default) or en. Ignored when output is cii-xml or ubl-xml.	fr
`footer_text`	No	Optional text printed in the PDF footer. Omit it for no footer. Ignored for XML-only output.
`party_check`	No	Ask EU Verify whether the seller and buyer are invoice-ready before emitting. true checks. false skips. Omit it and extended-ctc-fr checks, other profiles do not. not_ready is a tool error and no file is returned.

get_invoice_exampleGet an invoice or credit-note exampleA

Read-onlyIdempotent

Inspect

Return a complete invoice or credit-note example to edit and pass to generate_invoice.

Use this first, instead of inventing fields. No API key is required, and the call does not count
as a document. The seller and buyer are sample data: replace them, the number, the dates and the
lines before you generate. For credit_note, also replace preceding_invoices with the original invoice reference.
To credit a real invoice already in hand, use draft_credit_note instead of this synthetic example.
Amounts are positive decimal strings. Nothing is stored, and no file
is created. Returns the invoice plus the profile and check to pass to generate_invoice.

ParametersJSON Schema

Name	Required	Description	Default
`profile`	No	en16931 (default) or extended-ctc-fr. The body is the same. extended-ctc-fr sets party_check so generate_invoice asks EU Verify before emitting a file.	en16931
`document_type`	No	invoice (default): type 380; credit_note: type 381 with a sample original-invoice reference.	invoice

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), yet the description adds substantive context: no API key required, the call does not count as a document, nothing is stored, no file is created, and the returned data is synthetic sample data that must be replaced before generating. It even flags the credit_note-specific preceding_invoices substitution.

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?

Front-loaded with the core action in the first sentence, followed by usage, caveats, and substitution guidance. Every sentence carries a distinct instruction, though the block runs slightly long and could be tightened without losing meaning.

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?

Output schema exists so return values needn't be spelled out, and the description nonetheless notes it returns the invoice plus profile and check. Combined with full parameter coverage and clear routing, an agent has everything needed to call it correctly.

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%, so the enum meanings for profile and document_type are already fully documented. The description adds only the credit_note/preceding_invoices substitution hint and the positive-decimal-amount convention, which is marginal value over the schema baseline.

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: 'Return a complete invoice or credit-note example.' It names its downstream consumer (generate_invoice) and its alternative (draft_credit_note), so an agent can distinguish it from siblings like generate_invoice and view_invoice_demo without opening a 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?

Explicit routing guidance: 'Use this first, instead of inventing fields' and 'To credit a real invoice already in hand, use draft_credit_note instead of this synthetic example.' It states both when to use it and the condition that selects the alternative, leaving nothing to inference.

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

validate_invoiceValidate your invoice document

Read-onlyIdempotent

Inspect

Check a Factur-X PDF, CII XML or UBL XML against EN 16931, and report the fields to fix.

Use when the caller supplies a document, including after corrections; use extract_invoice for business data.
With no document and only a request to try the product, choose view_invoice_demo instead.
Supply one source: nonblank xml overrides document_base64 without inspecting it. To check a PDF's
attachment, omit xml. check adds rules to the detected profile; it cannot change that profile.
Use base for non-French invoices to avoid French-field findings.

Returns validity and findings with rule ids and field pointers for explain_finding. XSD failures
skip schematron; inspect checks_skipped before treating validation as complete. Warnings alone do
not invalidate an invoice. Rule failures or a PDF without XML return valid=false; missing input,
invalid base64, malformed or unrecognized XML return a tool error.
Free without a key (shared daily limit, files up to 5 MB). With an OAuth connection or API key,
completed reports consume one operation even when invalid; tool errors do not.
No invoice is changed, stored or sent.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	No	CII or UBL XML as unencoded text.
`check`	No	fr-ctc: EN 16931 plus French CTC rules (BR-FR-*). base: EN 16931 only.	fr-ctc
`document_base64`	No	Standard base64 of a Factur-X PDF, CII XML or UBL XML file; no data-URI prefix.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

view_invoice_demoTry fixed invoice samples (no document input)

Read-onlyIdempotent

Inspect

Demonstrate the engine on bundled synthetic samples only; never checks a user's invoice.

Use for product evaluation without a key. To check a supplied document, choose validate_invoice.
Choose sample=valid to inspect a passing CII invoice or sample=invalid to see the missing-buyer-name
finding. Both use the production XSD and EN 16931 engine; results may be cached for 24 hours for
the same engine version and input. Inspect validated_at and cached; a cache hit is not a fresh run.
Call with {} to validate the passing sample, or sample=downloads for PDF/CII/UBL files and the published report.
Accepts no document data, URLs or extra arguments. No PDF or business-register checks in live mode.
Shared rate limits return a retryable tool error; unavailable checks never become a passing result.
Use explain_finding for a returned rule id. Your own invoices require validate_invoice with
a verified-account trial, prepaid or monthly-plan key. Nothing is stored except reports for these public fixtures.

ParametersJSON Schema

Name	Required	Description	Default
`sample`	No	valid (default): passing CII invoice; invalid: missing buyer name; downloads: published files.	valid

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

Tool Schema Changelog

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

4 tool updatesOct 3, 2026
- Changedcheck_invoice_parties2 fields changed
  - addedInput schema / properties / buyer / type
```
Added value: +"object"
```
  - addedInput schema / properties / seller / type
```
Added value: +"object"
```
- Changeddraft_credit_note1 field changed
  - addedInput schema / properties / invoice / type
```
Added value: +"object"
```
- Changedembed_xml1 field changed
  - addedInput schema / properties / language / type
```
Added value: +"string"
```
- Changedgenerate_invoice4 fields changed
  - addedInput schema / properties / invoice / type
```
Added value: +"object"
```
  - addedInput schema / properties / language / type
```
Added value: +"string"
```
  - addedInput schema / properties / output / type
```
Added value: +"string"
```
  - addedInput schema / properties / profile / type
```
Added value: +"string"
```

2 tool updatesOct 2, 2026

Changeddraft_credit_note2 fields changed

addedInput schema / $defs / CreditLine

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "line_index": {
+      "description": "1-based position in the original invoice.lines array, not its id.",
+      "minimum": 1,
+      "title": "Line Index",
+      "type": "integer"
+    },
+    "quantity": {
+      "anyOf": [
+        {
+          "exclusiveMinimum": 0,
+          "type": "number"
+        },
+        {
+          "pattern": "^(?!^[-+.]*$)[+-]?0*(?:\\d{0,13}|(?=[\\d.]{1,20}0*$)\\d{0,13}\\.\\d{0,6}0*$)",
+          "type": "string"
+        }
+      ],
+      "description": "Positive quantity to credit, at most the original line quantity; decimal string.",
+      "title": "Quantity"
+    }
+  },
+  "required": [
+    "line_index",
+    "quantity"
+  ],
+  "title": "CreditLine",
+  "type": "object"
+}

addedInput schema / properties / credit_lines

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "$ref": "#/$defs/CreditLine"
+      },
+      "minItems": 1,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Selected original line positions and quantities. Omit for a full credit; an empty list is invalid.",
+  "title": "Credit Lines"
+}

Changedget_invoice_example1 field changed

addedInput schema / properties / document_type

Added value: +{
+  "default": "invoice",
+  "description": "invoice (default): type 380; credit_note: type 381 with a sample original-invoice reference.",
+  "enum": [
+    "invoice",
+    "credit_note"
+  ],
+  "title": "Document Type",
+  "type": "string"
+}

1 tool updateOct 2, 2026

Changedview_invoice_demo5 fields changed

removedInput schema / properties / sample / anyOf

Removed value: -[
-  {
-    "enum": [
-      "valid",
-      "invalid"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

changedInput schema / properties / sample / default
```
Previous value: -nullNew value: +"valid"
```

changedInput schema / properties / sample / description

Previous value: -"valid: fixed CII invoice; invalid: same invoice without the buyer name. Omit for downloads."New value: +"valid (default): passing CII invoice; invalid: missing buyer name; downloads: published files."

addedInput schema / properties / sample / enum

Added value: +[
+  "valid",
+  "invalid",
+  "downloads"
+]

addedInput schema / properties / sample / type
```
Added value: +"string"
```

1 tool updateSep 30, 2026

Changedview_invoice_demo1 field changed

addedInput schema / properties / sample

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "valid",
+        "invalid"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "valid: fixed CII invoice; invalid: same invoice without the buyer name. Omit for downloads.",
+  "title": "Sample"
+}

1 tool updateSep 27, 2026
- Addedcheck_invoice_parties

5 tool updatesSep 27, 2026

Changedcheck_party4 fields changed

changedInput schema / properties / country_code / description

Previous value: -"ISO 3166-1 alpha-2. FR, a SIREN, or a VAT starting with FR makes the party French."New value: +"ISO 3166-1 alpha-2 country code, for example FR or DE."

changedInput schema / properties / siren / description

Previous value: -"9-digit French SIREN. Give siren, siret, or vat."New value: +"9-digit French SIREN, including leading zeros."

changedInput schema / properties / siret / description

Previous value: -"14-digit SIRET. French parties need a SIREN or SIRET."New value: +"14-digit French SIRET, including leading zeros."

changedInput schema / properties / vat / description

Previous value: -"EU VAT number, for example FR40732829320. Checked, or derived from the SIREN."New value: +"Party's EU VAT number, for example FR40732829320."

Changedembed_xml3 fields changed

changedInput schema / properties / check / description

Previous value: -"Rule set the XML must pass before embedding: fr-ctc (default, EN 16931 plus French BR-FR-*) or base (EN 16931 only). A failed check is a tool error listing the rule ids, not a validation report, and no PDF is returned."New value: +"XML validation rules: fr-ctc adds French BR-FR-* to EN 16931; base uses EN 16931 only."

changedInput schema / properties / pdf_base64 / description

Previous value: -"Required. Standard base64 of the visual invoice PDF. After decoding it must be a PDF (bytes start with %PDF-). Invalid base64 or a non-PDF is a tool error and no file is returned. The PDF is converted to PDF/A-3."New value: +"Standard base64 of PDF bytes starting with %PDF-. Not a URL or data-URI."

changedInput schema / properties / xml / description

Previous value: -"Required. CII XML for the same invoice (Factur-X / EN 16931). UBL and any other flavor cannot be embedded: that is a tool error and no PDF is returned. The XML must pass `check` or the tool errors with the rule ids and returns no PDF."New value: +"Unencoded CII XML text (Factur-X / EN 16931); UBL is not supported."

Changedexplain_finding3 fields changed

changedInput schema / properties / json_pointer / description

Previous value: -"json_pointer from the finding. Used as-is when you send it."New value: +"Original finding's json_pointer field path."

changedInput schema / properties / message / description

Previous value: -"The finding message, echoed back when the rule is not in the short guide."New value: +"Original finding's message text."

changedInput schema / properties / rule / description

Previous value: -"Rule id from a finding, for example BR-FR-01 or BR-CO-26. Required."New value: +"Validation rule identifier, for example BR-FR-01 or BR-CO-26."

Changedextract_invoice3 fields changed

changedInput schema / properties / document_base64 / description

Previous value: -"Base64 of a Factur-X PDF, or of a CII or UBL XML file. Give this or xml. If both are set, nonblank xml is used. Invalid base64 is a tool error. A PDF with no embedded e-invoice XML is a tool error, not an empty result. Omit both and the tool errors."New value: +"Standard base64 of a Factur-X PDF, CII XML or UBL XML file; no data-URI prefix."

changedInput schema / properties / include_xml / description

Previous value: -"When true, the result also includes the raw XML text, which can be large. Default false returns only the parsed fields (number, dates, parties, totals, VAT, lines)."New value: +"Include source XML text in the result; this can substantially increase response size."

changedInput schema / properties / xml / description

Previous value: -"CII or UBL XML as plain text. Alternative to document_base64: give exactly one. If both are set, this value is used when nonblank. XML that is not well-formed or not an e-invoice is a tool error, not an empty fields object."New value: +"CII or UBL XML as unencoded text."

Changedvalidate_invoice3 fields changed

changedInput schema / properties / check / description

Previous value: -"fr-ctc (default): EN 16931 plus French CTC rules (BR-FR-*). base: EN 16931 only. A failed rule is a normal result with valid false and findings, not a tool error."New value: +"fr-ctc: EN 16931 plus French CTC rules (BR-FR-*). base: EN 16931 only."

changedInput schema / properties / document_base64 / description

Previous value: -"Base64 of a Factur-X PDF, or of a CII or UBL XML file. Give this or xml. If both are set, nonblank xml is used. Invalid base64 is a tool error. Omit both and the tool errors."New value: +"Standard base64 of a Factur-X PDF, CII XML or UBL XML file; no data-URI prefix."

changedInput schema / properties / xml / description

Previous value: -"CII or UBL XML as plain text. Alternative to document_base64: give exactly one. If both are set, this value is used when nonblank. Well-formed XML that is not an e-invoice is a tool error."New value: +"CII or UBL XML as unencoded text."

3 tool updatesSep 27, 2026

Changedcheck_party3 fields changed

changedInput schema / properties / address / description

Previous value: -"Street line. Checked only when you send an address."New value: +"Street line; any address, postal_code or city activates address checking."

changedInput schema / properties / iban / description

Previous value: -"Seller IBAN. Checked only when you send it."New value: +"Party IBAN. Checked only when you send it."

changedInput schema / properties / role / description

Previous value: -"seller or buyer. Required."New value: +"Party role recorded in the evidence; defaults to buyer."

Changedextract_invoice2 fields changed

changedInput schema / properties / document_base64 / description

Previous value: -"Base64 of a Factur-X PDF, or of a CII or UBL XML file. Give this or xml. If both are set, xml is used. Invalid base64 is a tool error. A PDF with no embedded e-invoice XML is a tool error, not an empty result. Omit both and the tool errors."New value: +"Base64 of a Factur-X PDF, or of a CII or UBL XML file. Give this or xml. If both are set, nonblank xml is used. Invalid base64 is a tool error. A PDF with no embedded e-invoice XML is a tool error, not an empty result. Omit both and the tool errors."

changedInput schema / properties / xml / description

Previous value: -"CII or UBL XML as plain text. Alternative to document_base64: give exactly one. If both are set, this value is used. XML that is not well-formed or not an e-invoice is a tool error, not an empty fields object."New value: +"CII or UBL XML as plain text. Alternative to document_base64: give exactly one. If both are set, this value is used when nonblank. XML that is not well-formed or not an e-invoice is a tool error, not an empty fields object."

Changedvalidate_invoice2 fields changed

changedInput schema / properties / document_base64 / description

Previous value: -"Base64 of a Factur-X PDF, or of a CII or UBL XML file. Give this or xml. If both are set, xml is used. Invalid base64 is a tool error. Omit both and the tool errors."New value: +"Base64 of a Factur-X PDF, or of a CII or UBL XML file. Give this or xml. If both are set, nonblank xml is used. Invalid base64 is a tool error. Omit both and the tool errors."

changedInput schema / properties / xml / description

Previous value: -"CII or UBL XML as plain text. Alternative to document_base64: give exactly one. If both are set, this value is used. Well-formed XML that is not an e-invoice is a tool error."New value: +"CII or UBL XML as plain text. Alternative to document_base64: give exactly one. If both are set, this value is used when nonblank. Well-formed XML that is not an e-invoice is a tool error."

1 tool updateSep 27, 2026
- Addedview_invoice_demo
4 tool updatesSep 26, 2026
- Removedcredit_note
- Addeddraft_credit_note
- Addedget_invoice_example
- Removedinvoice_example
2 tool updatesSep 26, 2026
- Addedcredit_note
- Addedinvoice_example
2 tool updatesSep 26, 2026
- Addedcheck_party
- Addedexplain_finding

4 tool updatesSep 26, 2026

Changedembed_xml4 fields changed

changedInput schema / properties / check / description

Previous value: -"Rule set the XML must pass before embedding: fr-ctc (default, France) or base (EN 16931 only)"New value: +"Rule set the XML must pass before embedding: fr-ctc (default, EN 16931 plus French BR-FR-*) or base (EN 16931 only). A failed check is a tool error listing the rule ids, not a validation report, and no PDF is returned."

changedInput schema / properties / language / description

Previous value: -"Document language written in the PDF metadata: fr or en"New value: +"Language written in the PDF metadata: fr (default) or en."

changedInput schema / properties / pdf_base64 / description

Previous value: -"Your existing visual invoice PDF (any PDF, will be converted to PDF/A-3), base64 encoded"New value: +"Required. Standard base64 of the visual invoice PDF. After decoding it must be a PDF (bytes start with %PDF-). Invalid base64 or a non-PDF is a tool error and no file is returned. The PDF is converted to PDF/A-3."

changedInput schema / properties / xml / description

Previous value: -"CII XML for the same invoice (Factur-X or EN 16931). It must pass the `check` rules or the tool fails"New value: +"Required. CII XML for the same invoice (Factur-X / EN 16931). UBL and any other flavor cannot be embedded: that is a tool error and no PDF is returned. The XML must pass `check` or the tool errors with the rule ids and returns no PDF."

Changedextract_invoice3 fields changed

changedInput schema / properties / document_base64 / description

Previous value: -"Factur-X PDF (the embedded XML is read), or a CII or UBL XML file, base64 encoded"New value: +"Base64 of a Factur-X PDF, or of a CII or UBL XML file. Give this or xml. If both are set, xml is used. Invalid base64 is a tool error. A PDF with no embedded e-invoice XML is a tool error, not an empty result. Omit both and the tool errors."

changedInput schema / properties / include_xml / description

Previous value: -"Also return the raw XML text (large); default false returns only the parsed fields"New value: +"When true, the result also includes the raw XML text, which can be large. Default false returns only the parsed fields (number, dates, parties, totals, VAT, lines)."

changedInput schema / properties / xml / description

Previous value: -"CII or UBL XML as plain text; alternative to document_base64, give exactly one"New value: +"CII or UBL XML as plain text. Alternative to document_base64: give exactly one. If both are set, this value is used. XML that is not well-formed or not an e-invoice is a tool error, not an empty fields object."

Changedgenerate_invoice3 fields changed

changedInput schema / properties / footer_text / description

Previous value: -"Optional footer text on the PDF"New value: +"Optional text printed in the PDF footer. Omit it for no footer. Ignored for XML-only output."

changedInput schema / properties / language / description

Previous value: -"Language of the visual PDF: fr or en"New value: +"Language of the visual PDF: fr (default) or en. Ignored when output is cii-xml or ubl-xml."

changedInput schema / properties / party_check / description

Previous value: -"Ask EU Verify whether the seller and buyer are invoice-ready before emitting. Defaults to true for extended-ctc-fr. not_ready returns an error and no file."New value: +"Ask EU Verify whether the seller and buyer are invoice-ready before emitting. true checks. false skips. Omit it and extended-ctc-fr checks, other profiles do not. not_ready is a tool error and no file is returned."

Changedvalidate_invoice3 fields changed

changedInput schema / properties / check / description

Previous value: -"fr-ctc (default): EN 16931 + French CTC rules (BR-FR-*). base: EN 16931 only."New value: +"fr-ctc (default): EN 16931 plus French CTC rules (BR-FR-*). base: EN 16931 only. A failed rule is a normal result with valid false and findings, not a tool error."

changedInput schema / properties / document_base64 / description

Previous value: -"Factur-X PDF (the embedded XML is read), or a CII or UBL XML file, base64 encoded"New value: +"Base64 of a Factur-X PDF, or of a CII or UBL XML file. Give this or xml. If both are set, xml is used. Invalid base64 is a tool error. Omit both and the tool errors."

changedInput schema / properties / xml / description

Previous value: -"CII or UBL XML as plain text; alternative to document_base64, give exactly one"New value: +"CII or UBL XML as plain text. Alternative to document_base64: give exactly one. If both are set, this value is used. Well-formed XML that is not an e-invoice is a tool error."

Publisher details

Operator: Orvel · Publisher source
Operator website: https://orvel.dev · Publisher source
Vendor relationship: First-party · Publisher source
Documentation: https://facturx.orvel.dev/docs/mcp/ · Publisher source
Trust center: Not applicable
Restrictions: validate_invoice checks your own Factur-X, CII or UBL invoice with no key, as do the sample demo and helpers (free checks share a daily limit, files up to 5 MB). To generate, embed or extract your own documents: 10 operations over 14 days with a verified Orvel account, no card, then EUR 10 for 100 operations (no subscription) or monthly plans from EUR 29. OAuth clients can connect https://facturx.orvel.dev/mcp/account; this listing uses /mcp, which also accepts Authorization: Bearer keys. Pricing: https://facturx.orvel.dev/docs/pricing/. Setup: https://facturx.orvel.dev/docs/mcp/ · Publisher source

Related MCP Connectors

invoicehub A
dev.invoicehub
Validate, generate & convert EU e-invoices (UBL, CII, XRechnung, Factur-X) — EN 16931 pre-validated.
Finance Legal & Compliance
2
InvoiceXMLOAuth
com.invoicexml
Create, validate, convert & extract compliant e-invoices (UBL, Factur-X, ZUGFeRD, XRechnung)
Finance Legal & Compliance Payments & Billing
25
einvoicewiz A
com.einvoicewiz
Generate & validate EN 16931 e-invoices (Factur-X, ZUGFeRD, XRechnung); verification certificates
Payments & Billing Legal & Compliance
71
invowerk A
dev.invowerk
E-invoice checker for ZUGFeRD, Factur-X, XRechnung and Peppol BIS. Free web tool, API and MCP.
Finance Legal & Compliance
61

Related MCP Servers

invoicehub-mcp
Legal & Compliance Developer Tools
einvoice-dev1
A
license
Not graded
quality
D
maintenance
EU e-invoice validation, as a developer API. Check whether an electronic invoice conforms to EN 16931 — the European standard behind France, Germany, Belgium, Poland and the 2030 ViDA mandate — with a single REST call. Structured JSON errors mapped to the official BR-* business rules. No enterprise sales call required.
Updated 3 months ago (2026-07-26 01:57 UTC)
MIT
InvoiceInofficial
Finance Legal & Compliance Payments & Billing
peculiar-systems
A
license
A
quality
A
maintenance
Reads and validates any European e-invoice a business receives — XRechnung, UBL, CII, ZUGFeRD/Factur-X PDF, Peppol BIS 3, FatturaPA, KSeF FA(3) — into canonical EN 16931 JSON with plain-language fix hints in EN/DE/PL/IT/FR, plus PDF, CSV and DATEV export. Nothing is stored; works without a key on a small daily quota.
Updated 20 days ago (2026-09-25 08:43 UTC)
5
MIT
beliq-mcpofficial
Finance Legal & Compliance
beliq-eu
A
license
A
quality
C
maintenance
Validates electronic invoices (XRechnung, ZUGFeRD, Factur-X, Peppol BIS, etc.) against authority-pinned rules and explains failures.
Updated a day ago (2026-10-14 10:07 UTC)
2
46 npm
MIT
eleata e-invoice MCP server
Legal & Compliance Finance
eleata
A
license
A
quality
D
maintenance
Validates EU electronic invoices (Peppol, XRechnung, FatturaPA, etc.) and explains validation error codes, enabling AI coding agents to check invoice validity and get fixes before rejection.
Updated 3 months ago (2026-06-30 15:36 UTC)
3
33 npm
MIT