Klarbon

Check an e-invoice

check_invoice

Read-onlyIdempotent

Validates an e-invoice against EN 16931 and its national rules (XRechnung, Peppol BIS and others), with each finding explained in plain words and how to fix it. With country, also applies that country's national rules on top of EN 16931 (France: the CTC rules), only when asked; Klarbon never infers the country. Free within the account's daily checks; needs an API key.

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": "check_invoice"
  }
}

Input Schema

Name	Required	Description
`country`	No	Also apply this country's national rules on top of EN 16931 (FR: the French CTC rules). Only when you give it; Klarbon never infers a country from the file.
`ruleset`	No	A rule set id, or auto (the default) to pick it from the file. Leave it out when you give country.
`file_url`	No	A public https address of the file. Private and local addresses are refused.
`filename`	No	The file's name, which helps recognise its format.
`file_base64`	No	The file's bytes as base64. Give this or file_url.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description does add useful context beyond them — API key requirement, daily free quota, and the shape of findings with remediation advice. It stops short of describing pagination, limits on finding counts, or failure modes for rejected files.

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?

Three tight sentences, front-loaded with what is validated and what the agent gets back. The country caveat mildly duplicates the schema wording but earns its place by emphasizing the no-inference rule.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining returns and does so (each finding explained in plain words plus a fix). For a five-parameter tool it remains silent on that at least one file source must be supplied and on file-size limits, which are only implied by the schema.

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 coverage is 100%, so all five parameters are already documented, including the country and ruleset enums and the file_url/file_base64 alternative. The description restates the country-on-top-of-EN-16931 behavior that the schema already contains, adding no new semantics or format hints.

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 — validating an e-invoice against EN 16931 plus named national rules — and adds the output's character (findings in plain words with fixes). The verb 'validates' clearly separates it from siblings like convert_invoice and check_vat_numbers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real usage conditions: the country rules are applied only when explicitly passed and 'Klarbon never infers the country', and it notes the tool is free within daily checks but requires an API key. It does not explicitly contrast with convert_invoice or open_invoice, so routing guidance is implied rather than stated.

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

All Klarbon tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?