Skip to main content
Glama

Rechnungsvorschau

rvg_preview_invoice
Read-onlyIdempotent

Zeigt eine Rechnung als Entwurf, bevor sie ausgestellt wird. Rufe es für jede Rechnung zuerst, vor rvg_create_invoice. Kanzleidaten kommen aus den Einstellungen; fehlen sie, nennt es die Antwort. Dasselbe Layout wie rvg_create_invoice mit dem Wasserzeichen „ENTWURF“ und der voraussichtlichen Rechnungsnummer. Mit dem Tarif ONYST RVG mit Briefvorlage, Logo und Texten der Kanzlei, ohne ihn im Standardlayout ohne Logo, auch ohne Kanzlei; bei mehreren Kanzleien ohne Vorzugs-Kanzlei lehnt es ab. Ausgestellt, vergeben oder gespeichert wird nichts; der Entwurf zählt als eine Rechen-Anfrage. Eingabe wie bei rvg_create_invoice. Bei Änderungswünschen (etwa „ergänze die Postpauschale“) rufe es mit den geänderten Angaben erneut auf. Ausgestellt wird erst, wenn der Nutzer es will — in Hosts mit Ansichten über den Knopf „Rechnung ausstellen“ der Vorschau, sonst mit rvg_create_invoice. preview (eigenes Argument neben request, nicht darin): widget (Vorgabe) zeigt die Seiten in der Ansicht und gibt dir eine Zusammenfassung; pdf hängt das Entwurfs-PDF als Ressource an, image die erste Seite als Bild — beides kostet Kontext, nimm es nur, wenn der Host keine Ansichten zeigt; arbeitest du ohne Ansichten (etwa in Claude Code oder als Agent), nimm gleich beim ersten Aufruf pdf. 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. 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. Als PDF sagt hint, wenn die Rechnung auch als E-Rechnung ginge, und firmProfile mit status e-rechnung, was ihr dafür fehlt; biete sie dann einmal an. Ob der Nutzer diese Rechnung schon ausgestellt hat (etwa über den Knopf der Ansicht), sagt dir dieses Werkzeug: Mit denselben Angaben nennt hint dann die vergebene Nummer — stell sie nicht noch einmal aus. Unter rueckfragen stehen Positionen, die typischerweise fehlen — frag den Nutzer (zeigt die Ansicht sie mit Antwortknöpfen, nenn nur ihre Zahl), statt sie selbst zu ergänzen, außer er hat sie ausgeschlossen („ohne Auslagen“ schließt Nr. 7002 ein, „nur …“). Keine Fragen ohne Anlass. Frag nicht im selben Zug, ob du ausstellen sollst, solange eine Rückfrage offen ist; stelle erst aus, wenn sie beantwortet sind. Meldet das Ergebnis, dass die Ansicht die Rückfragen mit Antwortknöpfen zeigt, frag nicht im Text danach: Nenn nur, wie viele offen sind — der Nutzer beantwortet sie dort. Hat der Nutzer eine Rückfrage verneint, trag ihren code, in der Gesamtrechnung mit pfad, in rueckfragenVerneint ein; sie kommt dann nicht wieder. Den Entwurf zeigst du trotzdem gleich, wenn der Nutzer die Rechnung will — er stellt nichts aus —, und fragst dazu, außer nach den Rückfragen mit Antwortknöpfen in der Ansicht. Mehrere Angelegenheiten: je Angelegenheit ein Entwurf, request nimmt eine Berechnung. Rechnungsdatum (heute), Leistungszeitraum und Zahlungsziel erfragst du dafür nicht. Nenn nur Beträge aus dem Ergebnis: keine Umsatzsteuer aufschlagen, keine Brutto-, Teil- oder Differenzsummen und keinen Betrag „effektiv nach Anrechnung“; fehlt einer, ruf erneut auf (etwa mit ustPflichtig oder für eine andere Variante) oder nenn ihn nicht. Antworte knapp: Summe zuerst, Positionen nur mit Nummer und Betrag, ohne Rechenweg. Was das Gespräch beantwortet, frag nicht; sonst je Rückfrage ein Satz.

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_preview_invoice"
  }
}

Input Schema

NameRequiredDescriptionDefault
previewNoWie die Vorschau ankommt (neben request, nicht darin): widget (Seiten in der Ansicht des Hosts, Vorgabe), pdf (Entwurfs-PDF als Ressource) oder image (erste Seite als Bild).
requestYesDie Rechnung wie bei rvg_create_invoice: Berechnung, Empfänger, Rechnungsangaben.
rueckfragenVerneintNoRückfragen, die der Nutzer verneint hat (eigenes Argument neben request, nicht darin); sie fehlen dann im Ergebnis. Gib die Liste in jedem weiteren Aufruf wieder mit.

Output Schema

NameRequiredDescriptionDefault
netYes
vatYes
hintYes
grossYes
appliedNo
previewYes
amountDueNo
pageCountNo
positionsYes
deductionsNo
addressBookNo
firmProfileNo
rueckfragenNo
expectedNumberNo
numberFromSeriesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / rueckfragenVerneint
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "anyOf": [
      +          {
      +            "properties": {
      +              "code": {
      +                "anyOf": [
      +                  {
      +                    "enum": [
      +                      "pauschale_fehlt",
      +                      "abwesenheitsgeld_fehlt",
      +                      "fahrtkosten_fehlen",
      +                      "sonstige_auslagen_reise",
      +                      "terminsgebuehr_einigung",
      +                      "terminsgebuehr_fehlt",
      +                      "einigung_zahlungsvereinbarung",
      +                      "vollstreckungsbescheid",
      +                      "grundgebuehr_fehlt",
      +                      "anrechnung_geschaeftsgebuehr",
      +                      "anrechnung_mahnverfahren",
      +                      "anrechnung_terminsgebuehr_mahnverfahren",
      +                      "anrechnung_erfolgsaussicht",
      +                      "anrechnung_zurueckverweisung",
      +                      "einigung_beweisverfahren",
      +                      "anrechnung_quellsatz",
      +                      "vorschuss_abzug"
      +                    ],
      +                    "type": "string"
      +                  },
      +                  {
      +                    "type": "null"
      +                  }
      +                ],
      +                "description": "Der code aus rueckfragen."
      +              },
      +              "pfad": {
      +                "anyOf": [
      +                  {
      +                    "type": "string"
      +                  },
      +                  {
      +                    "type": "null"
      +                  }
      +                ],
      +                "default": null,
      +                "description": "Nur in der Gesamtrechnung: der pfad aus rueckfragen, etwa angelegenheiten[1]; ohne pfad gilt der Eintrag für jede Angelegenheit."
      +              }
      +            },
      +            "required": [
      +              "code"
      +            ],
      +            "type": "object"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      },
      +      "maxItems": 50,
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Rückfragen, die der Nutzer verneint hat (eigenes Argument neben request, nicht darin); sie fehlen dann im Ergebnis. Gib die Liste in jedem weiteren Aufruf wieder mit."
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description corroborates them while adding real behavioral detail: nothing is issued, assigned or saved; the draft counts as one calculation request; the output carries an ENTWURF watermark and a provisional number; ONYST tariff produces letterhead/logo layout, otherwise standard layout; multiple firms without a preferred one causes rejection. It also discloses response signals (addressBook, firmProfile, hint with issued number, rueckfragen) and their side-effect-free handling rules.

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?

The purpose is front-loaded and nearly every sentence carries an operational rule, but the whole thing is one dense monolith of roughly two dozen clauses mixing layout rules, recipient bookkeeping, question policy, arithmetic guardrails and answer formatting. Some content restates schema or repeats the sibling's workflow, and the absence of any grouping makes the decisive rules (mode choice, don't re-issue, question handling) hard to locate at a glance.

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?

Complete for a nested, three-parameter tool with an output schema: it covers required inputs, fallback behavior when firm data is missing, cross-tool handoffs, and how to interpret the response (addressBook, firmProfile, hint, rueckfragen) well beyond what the output schema alone conveys. Nothing an agent needs in order to call it correctly and interpret the result 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% and the schema already documents preview, empfaengerId and rueckfragenVerneint in detail, so the baseline is 3. The description still adds decision-level meaning the schema lacks: pdf/image cost context so use them only when the host shows no views, and especially "nimm gleich beim ersten Aufruf pdf" when working headless; it also ties empfaengerId to a prior rvg_recipients_search call and requires resubmitting rueckfragenVerneint on every subsequent call.

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 first sentence gives a precise verb and resource ("Zeigt eine Rechnung als Entwurf, bevor sie ausgestellt wird") and immediately positions it against the sibling: "Rufe es für jede Rechnung zuerst, vor rvg_create_invoice." An agent can distinguish preview from create without opening either 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?

The description is explicit about when to use it (before every invoice), when to re-call it (on change requests such as adding the Postpauschale), which preview mode to pick per host capability, and when to hand off to rvg_recipients_search, rvg_recipient_save, rvg_firm_profile_update or rvg_create_invoice. It also states exclusions: do not ask for invoice date, service period or payment terms, and do not ask in the same turn while a Rueckfrage is open.

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