Skip to main content
Glama

Rechnung erzeugen

rvg_create_invoice

Stellt eine Vergütungsrechnung aus (PDF oder ZUGFeRD) mit Download-Link. Rufe es erst, wenn der Nutzer den Entwurf aus rvg_preview_invoice ausstellen will. Kanzleidaten kommen aus den Einstellungen. Ohne den Tarif ONYST RVG im Standardlayout ohne Logo, auch ohne Kanzlei; als Word-Datei nur mit ihm. Kanzleidaten (Absender, Bankverbindung, Anschreiben, Zahlungsziel) erfragst du nur, wenn eine Absage sie als fehlend nennt: Bei Anmeldung über das eigene ONYST-Konto kommen sie aus den Einstellungen der angemeldeten Person, über einen API-Schlüssel aus den Einstellungen der Kanzlei (der Kanzlei des Schlüssels bzw. dem Profil der Person, die ihn angelegt hat); ausdrücklich angegebene Felder gewinnen. Der Link ist mehrfach abrufbar und liefert jedes Mal dieselbe Rechnung — die Antwort nennt, bis wann und wie oft. Ausgestellt und gezählt wird sie einmal, beim ersten Abruf. Gibt dein Host Dateien an den Nutzer weiter (etwa Claude Code oder claude.ai), nimm delivery: file (neben request) — dann ist sie sofort ausgestellt und hängt als Datei an. Sie entsteht wie im RVG-Rechner: mit dem Nummernkreis der Kanzlei, mit dem Tarif ONYST RVG auch mit Briefvorlage, Logo und Schrift, und sie steht danach im Rechnungsverlauf; mit format docx als Word-Datei. Hat die Kanzlei einen Nummernkreis, lass meta.rechnungsnummer leer: Die Nummer wird beim ersten Abruf des Links vergeben. Fehlt eine Pflichtangabe, wird der Aufruf abgelehnt und nennt die fehlende. Die Antwort nennt unter applied, was aus den Einstellungen kam. Zeigt dein Host Ansichten, erscheint der Link dort als Karte mit „Öffnen“ — verweise dann auf die Karte, statt den Link in deine Antwort zu schreiben; ohne Ansicht gib ihn unverändert weiter. Dieselbe Rechnung mit denselben Angaben ergibt binnen einer Stunde denselben Link, auch wenn sie schon über die Vorschau ausgestellt wurde — die Antwort sagt es dann. Mit dem eigenen ONYST-Konto oder einem API-Schlüssel mit vollem Umfang: Suche den Empfänger zuerst mit rvg_recipients_search und übergib seine id als empfaengerId — dann fragst du nicht nach der Anschrift. Die Antwort nennt unter addressBook, ob der Empfänger neu ist oder vom Adressbuch abweicht; biete danach an, ihn zu speichern bzw. zu aktualisieren (rvg_recipient_save) — nie ungefragt. Ebenso nennt firmProfile, welche Angaben aus kanzlei in den Kanzleidaten fehlen oder abweichen; biete an, sie mit rvg_firm_profile_update zu speichern — nie ungefragt.

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": {
      "request": "<request>"
    },
    "name": "rvg_create_invoice"
  }
}

Input Schema

NameRequiredDescriptionDefault
requestYesDie Rechnung: Berechnung, Empfänger, Rechnungsangaben und Format.
deliveryNoWie das Dokument ankommt (eigenes Argument neben request, nicht darin): link (Vorgabe) gibt einen Download-Link für den Menschen im Chat; file stellt sofort aus und hängt die Datei zusätzlich als Ressource an — für Hosts, die Dateien an den Nutzer weitergeben (etwa Claude Code und claude.ai); sonst link, etwa in ChatGPT. Gezählt wird in beiden Fällen einmal. view setzt allein die Ansicht „Rechnungsvorschau“ beim Klick auf „Rechnung ausstellen“; du setzt es nie.

Output Schema

NameRequiredDescriptionDefault
netYes
vatYes
grossYes
appliedNo
hinweisYes
amountDueNo
positionsYes
deductionsNo
addressBookNo
downloadUrlYes
firmProfileNo
expiresAtUtcYes
maxDownloadsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes far beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) by disclosing idempotency (same link within an hour), that the invoice is issued and counted once on first retrieval, that the link is re-retrievable, number-circle assignment on first fetch, and how kanzlei/data precedence resolves. These are exactly the behavioral traits an agent could not infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the body is a dense block of long run-on sentences with many embedded parentheticals and clauses, making it hard to scan. Most sentences carry information, yet the same rules (kanzlei fallback, delivery) restate schema text and could be trimmed.

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 complex mutation with nested calculation, recipient resolution, firm-profile fallbacks, and three delivery modes, the description covers the failure path (rejection names missing field), the applied/addressBook/firmProfile response keys, host-dependent delivery, and follow-up offer etiquette. Nothing an agent needs to call it correctly is missing.

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 the baseline is 3, but the description adds real cross-parameter meaning: leave meta.rechnungsnummer empty when the firm has a number circle, prefer empfaengerId over empfaenger address fields, and never pass kanzlei unless correcting. Some of this duplicates schema prose, keeping it from a 5.

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: 'Stellt eine Vergütungsrechnung aus (PDF oder ZUGFeRD) mit Download-Link.' It also names the sibling it depends on (rvg_preview_invoice) and distinguishes its role (issuing, not previewing). An agent can identify the tool without opening the schema.

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?

Explicitly says when to invoke ('erst, wenn der Nutzer den Entwurf aus rvg_preview_invoice ausstellen will') and routes to alternatives (rvg_recipients_search first, rvg_recipient_save and rvg_firm_profile_update only when offered). It also states when NOT to ask for firm data: only when a rejection names the missing field.

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