MCP server for reading and validating electronic invoices (Factur-X, ZUGFeRD, XRechnung, UBL, CII) using the Facturolia API
Three tools with functional but minimal schema and description quality. All tools have descriptions (passing basic bar), but they are generic and lack detail about error conditions, data structures, and recovery paths. Input schemas are present but extremely sparse, only one string parameter per tool with minimal type information. No output schemas are documented anywhere in the code. Naming is verb-based (parse, validate, compare) which is good, but parameter descriptions are one-liner and do not explain formats, constraints, or expected values. No examples of error handling, validation guidance, or actionable recovery instructions. This is typical of a STDIO-only server focused on minimal functionality rather than LLM ergonomics.
Compare PDF rendering with embedded XML data in a Factur-X/ZUGFeRD invoice to detect discrepancies
Parse an electronic invoice file (PDF with embedded XML or raw XML) and extract structured invoice data
Validate an electronic invoice against EN 16931 standard and return validation results with errors and warnings
No output schemas documented for any tool. LLMs cannot plan downstream actions or extract structured data without knowing what fields to expect.
Input schemas are minimalist: only a 'path' parameter with generic string type and one-line description. No format constraints, no mime-type validation, no size limits stated in schema. LLMs have no guidance on valid file paths or formats.
Tool descriptions are too generic and lack actionable context. 'Parse an electronic invoice file' does not explain when to use parse vs validate vs compare, what formats are supported, or what errors might occur. Average description is ~60 chars; should be 100-200 for clarity.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
No error handling documentation. Tools call an external API (facturolia.fr) but code contains no visible guidance on what errors agents should expect or how to recover. E.g., what if the API is down? What if the file is corrupted? What if the API key is invalid?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all three tools being read-only. Tool annotations help agents reason about safety and retry logic.
'path' parameter description is minimal ('Path to the invoice file (.pdf or .xml)') and does not state: absolute vs relative path, max file size, supported formats as enum, encoding, or error behavior if file does not exist.