Skip to main content
Glama

firma.de Rechner für Gründer

firma.de E-Rechnungs-API

e_rechnung
Read-onlyIdempotent

Erstellt aus einem Rechnungsentwurf im JSON-Format eine E-Rechnung nach EN 16931 in der Syntax UN/CEFACT CII: als XRechnung 3.0 (für Behörden, mit Leitweg-ID) oder als ZUGFeRD 2.5.2 im Profil EN 16931 (für Unternehmen, als PDF/A-3 mit eingebettetem XML). Dieselbe Rechen- und XML-Logik wie der E-Rechnungs-Generator von firma.de: Positionsbeträge, Umsatzsteuer je Steuersatz, Summen und die Pflichtfelder von XRechnung. Die Antwort enthält die Hinweise des Generators, die Summen und das XML; mit ?format=xml kommt nur das XML, mit ?format=pdf die PDF-Datei. Die Beispiele des Generators sind mit dem KoSIT-Validator und mit Mustang (inklusive veraPDF) getestet. Kostenlos, ohne Schlüssel.

POST mit JSON in der Form des Entwurfs (wie draft in der Antwort): seller, buyer, lines (höchstens 50), number, issueDate, service, payment, taxCase, format, note, cashAccounting. Fehlende Felder und null lassen den Standard stehen, "" leert ein Feld. Ungültige Werte und unbekannte Felder geben 400 mit problems je Feld.

Antwortet auf Deutsch, als Text oder JSON. Der Rechner für Menschen: https://www.firma.de/e-rechnung/ – REST: https://www.firma.de/api/e-rechnung/

Input Schema

NameRequiredDescriptionDefault
noteNoFreier Hinweis auf der Rechnung (BT-22).
buyerNo
linesNoPositionen, höchstens 50.
formatNomd (Standard): die Antwort als lesbarer Text mit Link in den Rechner, kurz genug für den Chat. json: alle Werte als JSON. xml: nur die E-Rechnung als XML.md
numberNoRechnungsnummer (BT-1).
sellerNo
paymentNo
serviceNo
taxCaseNotaxCase: standard (19 %, 7 % oder 0 % je Position), smallBusiness (Kleinunternehmer nach § 19 UStG, ohne Umsatzsteuer), reverseCharge (Steuerschuldnerschaft des Leistungsempfängers, § 13b UStG oder Leistungen an Unternehmen im EU-Ausland, nicht außerhalb der EU und nicht an Privatkunden; USt-IdNr. des Kunden nötig, bei Kunden im EU-Ausland auch deine), intraEu (innergemeinschaftliche Lieferung an ein Unternehmen, beide USt-IdNrn. nötig). Eine Rechnung, ein Steuerfall. Bis 250 € brutto braucht es meist keine E-Rechnung (Kleinbetragsrechnung), die API erzeugt sie trotzdem.
issueDateNoRechnungsdatum (BT-2); Standard heute.
cashAccountingNoIst-Versteuerung: druckt „Versteuerung nach vereinnahmten Entgelten“ (ab 2028 Pflicht).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false and openWorldHint=false, so safety and idempotency are covered; the description adds that no API key or cost is involved and that invalid values or unknown fields produce a 400 with per-field problems. It does not disclose limits, rate limiting, or what the generator 'Hinweise' contain, and it introduces a '?format=pdf' query option that has no counterpart in the schema's md/json/xml enum, which muddies the contract.

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?

Purpose and the two variants are front-loaded in the first sentence, and the second paragraph carries the operational rules. Some space is spent on promotional/testimonial material (KoSIT-Validator, Mustang, veraPDF, link to the human calculator) that helps trust but is not needed to invoke the tool.

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?

There is no output schema, yet the description explains what comes back — generator hints, totals, and the XML, plus the md/json/xml renderings — and notes that responses are in German. For a nested 11-parameter generator this is nearly complete; only the pdf format mismatch and missing limits leave a small gap.

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?

With 64% schema coverage over 11 parameters, the schema does most of the work, but the description adds the crucial merge semantics — missing fields and null keep defaults, "" explicitly clears a field — which the per-field schema text does not state. It also enumerates the top-level draft fields (seller, buyer, lines ≤50, number, issueDate, service, payment, taxCase, format, note, cashAccounting) so the agent knows the shape before opening the schema, though the ?format=pdf mention conflicts with the enum.

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 opening sentence states a specific verb and resource — it turns a JSON draft into an E-Rechnung per EN 16931 — and immediately names the two concrete output flavors (XRechnung 3.0 for authorities with Leitweg-ID, ZUGFeRD 2.5.2 PDF/A-3 for companies). An agent can tell exactly what it gets and that none of the sibling calculators/contract tools does this.

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?

It gives a clear decision rule for the two output variants based on recipient type (Behörde vs. Unternehmen) and states the tool is free and needs no key, which is the main gating question for an agent. What is missing is any explicit statement of when not to use it (e.g., trivial amounts) or how it relates to the sibling tax/legal tools.

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