MCP server to validate EU e-invoices (Peppol, XRechnung, Factur-X, UBL/CII) and explain validation error codes — for AI coding agents (Claude, Cursor, Copilot).
The server demonstrates solid definition quality with explicit tool schemas, clear descriptions, and parameter documentation. All three tools are properly registered with JSON Schema input definitions. However, there are gaps in output schema documentation and some parameter descriptions could be more detailed. The tools follow a consistent naming pattern (verb_noun) and descriptions adequately explain use cases and prerequisites. Error handling is present but minimal. Overall, this meets the threshold for 'Good' (B grade) with some room for improvement toward 'Excellent' (A grade).
Explain a single e-invoice validation error code (e.g. a FatturaPA SdI control like 00400, or an XRechnung rule like BR-DE-21) in plain English, with the suggested fix and an example. Works offline; no API key required.
List the EU e-invoice formats eleata can validate today, plus what is on the roadmap (e.g. FatturaPA, KSeF). No API key required.
Validate an EU electronic invoice against the official Schematron rules (Peppol BIS 3.0, EN 16931 UBL/CII, XRechnung 3.0.x, Factur-X/ZUGFeRD, UBL, CII). Returns whether it is valid and, for each violation, the rule id, a plain-English explanation and a suggested fix. Use this before a developer ships or transmits an invoice so a rejection (an SdI scarto, a Chorus Pro refusal, a KSeF error) is caught early. Requires EINVOICE_API_KEY (a free key from https://eleata.io/signup/).
Output schemas not documented. The tools return structured responses but the inputSchema declarations do not include outputSchema or documented return types. LLMs cannot reliably parse or chain tool results without explicit output documentation.
validate_einvoice lacks actionable error messages for common failure modes. When API_KEY is missing or invalid, the error is informational but does not guide LLM recovery (e.g., 'Get a free key from https://eleata.io/signup/'). When content length exceeds MAX_INPUT_CHARS, the error should suggest chunking strategies or alternative tools.
Parameter descriptions for 'format' enum in validate_einvoice do not explain the semantic differences between formats (e.g., when to use 'peppol-bis-3' vs 'en16931-ubl'). LLMs cannot infer that 'auto' should be the default in most cases without explicit guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
list_formats description does not specify what fields are returned (e.g., does it return format names, metadata, roadmap status?). Without knowing the response structure, LLMs cannot plan downstream usage or decide if they should call explain_error_code next.
The tools do not declare or document which ones are read-only vs state-mutating. While all three appear read-only, explicit toolAnnotations (readOnlyHint) would clarify this for agents and enable safety optimizations.