Skip to main content
Glama

Validate an e-invoice

validate_einvoice
Read-only

Says which rules an e-invoice passed, by which validator and release: the file is held to the rule set its specification identifier (BT-24) names, Factur-X and ZUGFeRD by Mustang, XRechnung (CII and UBL) by the KoSIT validator, and each check (syntax, schema, every named rule set) comes back with its own result and findings. Pass exactly one source: render_id, an e-invoice this workspace rendered, which is answered from the report the render keeps and costs nothing; or xml_base64, the XML itself. An XML takes one of the organisation's validations of the day (from the Starter plan; Free validates no uploads). Up to 4 MB of CII or UBL; a PDF is not taken. result is passed, failed or not_checked: not_checked means no rule set here is for the file (reason and explanation say why, such as an identifier it does not know), not that the file is wrong. The report says which rules a file passed; it does not say whether the document is a proper invoice for VAT purposes. To check an _invoice block before rendering it, use check_invoice.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "validate_einvoice"
  }
}

Input Schema

NameRequiredDescriptionDefault
rulesNoauto (default) takes the rule set the file's identifier names; a rule set named here judges only a file whose identifier it is for. en16931 holds a render's EN 16931 invoice to CEN's own rules, which counts like an upload
render_idNornd_ id of a render of this workspace that made an e-invoice; free
xml_base64NoThe e-invoice XML (CII or UBL), base64 encoded, up to 4 MB; counts one of the day’s validations

Output Schema

NameRequiredDescriptionDefault
rulesYesThe rule set and its release, as the validator names it
checksYes
reasonYesWhy it was not checked, such as unknown_customization_id
resultYespassed, failed or not_checked; new values may be added
allowanceYesWhat the day's validations have used after this call; null where nothing was counted
validatorYesThe validator and its version, e.g. KoSIT validator 1.6.3
xml_sha256YesSHA-256 of the XML that was judged
explanationYes
customization_idYesThe specification identifier (BT-24) the file names

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and non-destructive, yet the description adds real behavioral context beyond them: quota consumption per upload, a 4 MB ceiling, CII/UBL only with PDFs rejected, and the meaning of not_checked as 'no rule set here is for the file' rather than a failure. It does not mention latency or what the findings payload looks like, but the output schema covers the latter.

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?

Dense but front-loaded: what it does, then which validators, then source selection, then limits, then result semantics, then the sibling pointer. It is one long run-on block rather than separated sentences, which slightly hurts scanability, but almost every clause carries distinct information.

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 three-parameter, quota-governed read tool this covers the gaps that matter: allowed formats, size cap, plan gating, one-source-at-a-time, and disambiguation of the not_checked result. Return-value structure is delegated to the existing output schema, which is appropriate.

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, and the description still contributes the mutual-exclusivity constraint ('exactly one source') and the cost asymmetry between render_id (free) and xml_base64 (counts a validation) that the schema does not state. The 'auto' enum behavior is restated from the schema rather than extended.

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?

Names a specific verb and resource (report which rules an e-invoice passed, by validator and release) and enumerates the validators per specification family (Factur-X/ZUGFeRD via Mustang, XRechnung CII/UBL via KoSIT). It also draws a hard boundary against the closest sibling: 'To check an _invoice block before rendering it, use check_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?

Explicit selection rules: 'Pass exactly one source' with the render_id path described as free and the xml_base64 path described as consuming a daily validation, plus the plan constraint (Starter and above; Free validates no uploads). It also states the negative case — the report does not determine VAT validity — so an agent knows when not to rely on it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources