Let an AI assistant read and check European electronic invoices.
Point Claude (or any MCP-compatible client) at a .pdf or .xml invoice and it
answers with the contents in plain language, plus a consistency check against
the European standard EN 16931.
Supports Factur-X, ZUGFeRD, XRechnung, UBL and CII.
> Read ~/Downloads/invoice.pdf
Format: Factur-X / CII (EN 16931 (COMFORT) profile)
Invoice F-2026-0148 · issued 2026-07-15 · due 2026-08-14
Supplier: Studio Lumiere EURL
Customer: Cafe des Arts SARL
Total excl. VAT 1240.00 EUR · VAT 248.00 EUR · Total incl. VAT 1488.00 EUR
Lines (1):
- Consulting : 2 x 620.00 EUR = 1240.00 EUR (VAT 20 %)
EN 16931 check: no anomalies found.A Factur-X invoice is a PDF with structured data hidden inside it. The page a human reads and the data a machine imports are two different things, and they do not always agree. This server exposes both, so an assistant can answer "what is actually in this file?" rather than reading the visible page and hoping.
France made structured e-invoicing mandatory for receiving on 1 September 2026, so these files are now arriving in ordinary inboxes.
Related MCP server: Fintom8 E-Invoice MCP Server
No dependencies. Python 3.10 or newer is all you need.
Download facturolia_mcp.py.
Get a free API key at facturolia.fr/en/pricing.
Add it to your client configuration. For Claude Desktop, that is
claude_desktop_config.json:
{
"mcpServers": {
"facturolia": {
"command": "python",
"args": ["/absolute/path/to/facturolia_mcp.py"],
"env": { "FACTUROLIA_API_KEY": "your-key" }
}
}
}Restart the client. Two tools appear.
Tool | What it returns |
| Full contents: parties, dates, lines, VAT breakdown, totals, IBAN, plus the EN 16931 check |
| The compliance verdict and anomalies only, for "is this invoice correct?" |
Both take one argument, path, an absolute path to a .pdf or .xml file.
Variable | Default | Meaning |
| required | Your key |
|
| Response language, |
|
| Override for testing |
With FACTUROLIA_LANG=fr the answers come back in French, with French date and
label conventions. The tool descriptions stay in English so that every client
understands them.
The file is sent to the Facturolia API to be analysed. It is processed in memory and discarded immediately, no invoice is stored, and the contents do not appear in the technical logs. The servers are in the European Union.
That said, this is not local processing. If your policy forbids sending invoices to an external service, use the API yourself inside your own network instead, or do not use this server.
Limits: 10 MB per file, .pdf and .xml only.
It reads and checks invoices. It does not issue them, does not transmit them, and is not a compliance solution. In France, sending an invoice legally goes through an accredited platform (Plateforme Agréée). This tool sits before and after that step, never in place of it.
Web reader, free and without an account: facturolia.fr/en
REST API documentation: facturolia.fr/en/api
MIT. See LICENSE.
Validate one electronic invoice file (Factur-X, ZUGFeRD, XRechnung, UBL or CII) against the EN 16931 standard and return only the verdict and the list of anomalies: totals that do not add up, VAT miscalculated for a rate, missing required fields, each with the rule code and the figures involved. Use it to answer 'is this invoice correct?' or to screen several files quickly. It does not list the invoice contents; for parties, lines and totals use read_invoice. This is a consistency check, not a legal compliance certificate, and it does not transmit the invoice to any tax platform. Side effects: the file is uploaded over HTTPS to the Facturolia API, processed in memory and discarded. Requires FACTUROLIA_API_KEY; 10 MB limit; rate limited per key tier.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path on this machine to one invoice file, .pdf (Factur-X or ZUGFeRD) or .xml (UBL, CII or XRechnung). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent with these. It adds valuable context beyond the annotations: the file is uploaded over HTTPS, processed in memory and discarded, requires FACTUROLIA_API_KEY, has a 10 MB limit, and is rate limited per key tier. It also clarifies that the tool does not transmit invoices to any tax platform.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each sentence earns its place: what it returns, when to use it, what it excludes, and what side effects/limits apply. There is no redundancy, and the most decision-relevant content is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by specifying exactly what is returned: the verdict and a list of anomalies with rule codes and figures. It also covers formats, constraints, authentication, limits, and side effects. For a one-parameter validation tool, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents the single 'path' parameter clearly, including accepted file types. The description reinforces the file-format context but does not add meaningfully new parameter-level semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Validate') and a precise resource ('electronic invoice file against EN 16931'), and enumerates supported formats. It also distinguishes itself from the sibling read_invoice by explicitly saying it does not list invoice contents. An agent can clearly tell what this tool does and how it differs from the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: answer 'is this invoice correct?' or screen several files quickly. It also names the alternative read_invoice for content-related questions and clarifies what this tool is not (not a legal compliance certificate, not a tax submission). This leaves little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the full contents of one electronic invoice file (Factur-X, ZUGFeRD, XRechnung, UBL or CII) as plain text: invoice number and dates, supplier and customer, every line, the VAT breakdown per rate, totals, IBAN, the EN 16931 consistency check, and whether the amounts on a Factur-X PDF's visible page match its embedded XML. Use it when the user wants to know what an invoice contains. If they only ask whether the invoice is correct, use check_invoice instead, which returns the verdict without the contents. Side effects: the file is uploaded over HTTPS to the Facturolia API, processed in memory and discarded; nothing is written locally. Requires FACTUROLIA_API_KEY; files over 10 MB are refused; requests are rate limited per key tier and a 429 error means wait and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path on this machine to one invoice file. Must end in .pdf (a Factur-X or ZUGFeRD PDF with embedded XML) or .xml (UBL, CII or XRechnung). A plain PDF without embedded data returns an error explaining that it is not a structured invoice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description builds on this by disclosing the upload over HTTPS, in-memory processing and discard, the API key requirement, the 10 MB refusal, and rate-limit/429 behavior. These context-rich details meaningfully exceed what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries functional weight: output contents, usage advice, side effects, constraints, and error handling. The primary result is front-loaded before operational caveats, though it could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, the description is complete: it lists the return fields, the supported input file types, failure modes, security/processing behavior, authentication requirement, and rate-limit behavior. An agent has everything needed to decide whether to call it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already thoroughly documents the single 'path' parameter, including accepted extensions and the plain-PDF error case. The description adds no additional parameter meaning beyond that, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Extract') and resource ('one electronic invoice file') and enumerates exactly what will be returned, including the EN 16931 check and the visible-page-vs-XML comparison. It also differentiates itself from its only sibling, check_invoice, by explicitly contrasting content extraction with a verdict-only tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'Use it when the user wants to know what an invoice contains.' It also tells the agent when not to use it and names the alternative: 'If they only ask whether the invoice is correct, use check_invoice instead.' Additional constraints such as file size and 429 handling round out the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0check_invoiceread_invoiceScored across 2 tools
The two tools have clearly distinct purposes: read_invoice extracts full contents while check_invoice returns only the validation verdict. Their descriptions explicitly cross-reference each other to prevent confusion, so an agent can easily select the right one.
Both tool names follow a consistent verb_noun pattern (read_invoice, check_invoice), using snake_case and clear action words. The only minor deviation is that they are not from the same action family (read vs. check), but this is acceptable given the distinct operations.
With only 2 tools, the surface is quite thin, but for a focused invoice-processing server that offers exactly two complementary operations (read and check), it may be sufficient. However, typical MCP servers have more tools, so this feels slightly minimal.
The domain appears to be electronic invoice handling, and the two tools cover content extraction and validation. Missing operations include invoice creation, listing, or deletion, but for an analysis/validation service, these might be out of scope. Still, there is no way to manage invoices, so the surface is incomplete for a full lifecycle.
Validate, generate & convert EU e-invoices (UBL, CII, XRechnung, Factur-X) — EN 16931 pre-validated.
Validate, extract, repair and generate French Factur-X / EN16931 invoices via AgentForge API
Validiert E-Rechnungen (ZUGFeRD/Factur-X, XRechnung) gegen EN 16931 mit Korrekturvorschlägen.
Generate & validate EN 16931 e-invoices (Factur-X, ZUGFeRD, XRechnung); verification certificates
