invowerk

Create an e-invoice from JSON

generate_invoice

Read-only

Create a valid EN 16931 e-invoice (UBL or CII XML) from JSON.

Input: invoice is a JSON object keyed on EN 16931 Business Terms, the same schema as POST /v1/generate, at most 4 MB. Main fields: syntax ("ubl" default, or "cii"), flavor ("en16931" default, or "xrechnung", which requires buyer_reference, the Leitweg-ID BT-10, and payment_iban), invoice_number, issue_date (YYYY-MM-DD), currency, seller, buyer, lines, tax_breakdown, totals. invowerk writes your amounts as given. It does not compute or correct them. Input that breaks an EN 16931 or XRechnung rule returns an error naming each rule, e.g. BT-112 = BT-109 + BT-110 (BR-CO-15). Dates are YYYY-MM-DD, amounts go up to 999,999,999.99.

Returns xml, syntax, flavor and self_validation. invowerk checks the XML before answering and never returns an invalid document. Invalid input, or XML that fails the check, returns an error, as does a busy (engine_busy) or overrunning (engine_timeout) generate.

Credits: 5 per call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "invoice": "<invoice>"
    },
    "name": "generate_invoice"
  }
}

Input Schema

Name	Required	Description	Default
`invoice`	Yes	The invoice as a JSON object keyed on EN 16931 Business Terms, the schema of POST /v1/generate and of parse_invoice's `model`: syntax, flavor, invoice_number, issue_date, currency, seller, buyer, lines, tax_breakdown, totals.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 1, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well beyond the sparse annotations: it discloses the 4 MB input cap, the amount ceiling, that amounts are written as given and never computed or corrected, that failures return rule-named errors (e.g. BR-CO-15), that output is always self-validated, and that engine_busy/engine_timeout errors and a 5-credit cost per call apply. That is exactly the operational context annotations cannot supply.

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?

Front-loaded with the outcome sentence, then input, then behavior, then return and cost. Dense but every block carries information; the main fields list is the only slightly enumerative filler.

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?

Covers input shape, constraints, failure modes, return fields and cost — more than enough for a single-parameter tool with an output schema. The only missing piece is routing guidance versus the four sibling invoice tools.

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% and there is only one parameter, but the description still adds real meaning: defaults for syntax and flavor, the conditional XRechnung requirements (buyer_reference/Leitweg-ID BT-10 and payment_iban), date format and the field inventory. It supplies conditional logic the schema's free-form object cannot express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a concrete verb (create), resource (e-invoice) and concrete output format (UBL or CII XML from JSON), so the agent knows exactly what the tool produces. It does not, however, state how it differs from siblings like convert_invoice, parse_invoice or validate_invoice, which all operate on invoices.

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

Usage Guidelines3/5

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

Usage is only implied: you use this when you have a JSON model and need XML. There is no explicit guidance on when to prefer validate_invoice (check without generating) or convert_invoice (change syntax of existing XML), and no statement of prerequisites beyond the XRechnung field requirements.

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

All invowerk 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.