invoicehub

convert_invoice

Idempotent

Convert an e-invoice between formats via the shared EN 16931 canonical model: parse the source document, re-serialize as the target, and validate the result before returning it — never a document that has not been checked. Format ids: "UBL_2.1" (OASIS UBL, the universal Peppol/EN16931 baseline), "UN_CEFACT_CII" (UN/CEFACT Cross Industry Invoice, required syntax for Chorus Pro/France and many ERP back-ends), "XRechnung_UBL" / "XRechnung_CII" (Germany's mandatory B2G format, XRechnung 3.0 — required for invoicing German public-sector buyers), "Factur-X" (France/Germany hybrid PDF+XML — a human-readable PDF/A-3 with the structured invoice embedded, common for French B2B). Binary formats (Factur-X) are base64 in both directions. Requires an API key on the Pro plan or above for any target beyond plain UBL_2.1 — call list_supported_formats to see current availability.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	Target format id, e.g. "UN_CEFACT_CII", "XRechnung_UBL", "XRechnung_CII", or "Factur-X".
`from`	Yes	Source format id, e.g. "UBL_2.1".
`document`	Yes	The source document: raw text for XML formats, base64 for binary formats (Factur-X).

TDQS

A4.8/5.0

Behavior5/5

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

Description adds behavioral context beyond annotations: validates before returning, handles binary formats with base64. No contradiction with annotations (readOnlyHint=false, idempotentHint=true).

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?

Description is fairly long but front-loaded with core action. Each sentence earns its place, though some detail could be condensed. Well-structured with clear sections.

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?

Given complexity (multiple formats, binary, plan restrictions) and no output schema, the description is comprehensive—covers validation, base64, plan requirements, and sibling tool reference.

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% with descriptions. The description adds significant meaning to the parameters by detailing format IDs, binary handling, and source document format for 'from' parameter.

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?

The description clearly states the tool converts invoices between formats via a canonical model. It distinguishes from siblings like generate_invoice, validate_invoice, and list_supported_formats by focusing on conversion.

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?

Provides explicit guidance on when to use (conversion between specific format IDs), including plan requirements and suggestion to call list_supported_formats for availability. Implicitly tells when not to use (e.g., if target requires higher plan).

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

All invoicehub tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool addresses a distinct operation—generate creates, validate checks, convert transforms, and list_supported_formats provides metadata—with no functional overlap. The descriptions make the boundaries between tools crystal clear.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (convert_invoice, generate_invoice, list_supported_formats, validate_invoice), with the object being the domain concept. This makes the set predictable and easy to navigate.

Tool Count5/5

With only 4 tools, the server is tightly scoped to e-invoice processing—each tool earns its place, and the count is neither too thin nor bloated. It is an ideal size for the utility's purpose.

Completeness5/5

The set covers the core workflow: generating invoices, validating them, converting between formats, and discovering supported formats. There are no obvious gaps for the stated domain; users can perform all essential operations.

Resources

Need Help?