Skip to main content
Glama
dennismenken

BuchhaltungsButler MCP-Server

by dennismenken

Bericht erzeugen und abholen

bb_reports_run
Destructive

Run a BWA or sum-and-balance report for a date range, wait for calculation, and get the result immediately—replacing any prior report of the same type.

Instructions

Erzeugt eine BWA oder eine Summen- und Saldenliste für einen Zeitraum, wartet auf die serverseitige Berechnung und liefert die fertige Auswertung im selben Aufruf zurück. Dabei wird geschrieben: /reports/create/bwa beziehungsweise /reports/create/sums ersetzt den zuvor erzeugten Bericht desselben Typs im ganzen Mandanten, und ein gleichzeitig arbeitender zweiter Nutzer verliert damit seinen Bericht. Ersetzt die zuvor in BuchhaltungsButler erzeugte Auswertung desselben Typs. Buchungsdaten ändern sich dabei nicht, und die Auswertung lässt sich jederzeit neu erzeugen. Viele Clients brechen den Aufruf nach rund 60 Sekunden ab; erzeugt und ersetzt ist der Bericht dann trotzdem und nur noch mit bb_reports_get_bwa oder bb_reports_get_sums abzuholen. Bei aktivem BB_MCP_READ_ONLY gesperrt; lesend bleiben diese beiden und bb_reports_get_ledger. Dateien wie PDF oder CSV liefert es nie.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
baseNoDatum der Periodenzuordnung, NUR bei report_type 'sums'. 'date' ist das Buchungs- oder Rechnungsdatum, 'date_delivery_else_date' das Leistungsdatum und ersatzweise das Buchungsdatum. Ohne Angabe 'date'. Bei report_type 'bwa' wird das Feld abgelehnt, bevor etwas hinausgeht: /reports/create/bwa kennt es nicht.
date_toYesLetzter Tag des Auswertungszeitraums als YYYY-MM-DD, zum Beispiel 2026-03-31. Ein leerer String wird abgelehnt; das Feld stattdessen weglassen. Der Zeitraum schließt diesen Tag ein; für ein vollständiges erstes Quartal also 2026-03-31 und nicht 2026-04-01.
date_fromYesErster Tag des Auswertungszeitraums als YYYY-MM-DD, zum Beispiel 2026-01-01. Ein leerer String wird abgelehnt; das Feld stattdessen weglassen. Der Zeitraum schließt diesen Tag ein.
report_typeYesWelche Auswertung erzeugt wird. 'bwa' ist die Betriebswirtschaftliche Auswertung, also Erträge und Aufwendungen im Zeitraum. 'sums' ist die Summen- und Saldenliste, also je Konto die Bewegungen und der Saldo. Der Wert geht nicht an die API, er entscheidet, welcher Endpunkt aufgerufen wird. Beide Arten blockieren sich gegenseitig nicht.
response_formatNo'concise' liefert nur die Felder, die einen Datensatz erkennbar machen und den nächsten Schritt erlauben. 'detailed' liefert den Datensatz so, wie die BuchhaltungsButler-API ihn ausgibt. Mit 'concise' beginnen und nur für die wenigen Datensätze auf 'detailed' wechseln, die wirklich geprüft werden müssen. Dieses Feld ist serverseitig und geht nicht an die API.concise
max_wait_secondsNoWie lange dieser Aufruf höchstens auf die Berechnung wartet, in Sekunden. Ohne Angabe 60, erlaubt 10 bis 240. Läuft die Zeit ab, ist der Bericht trotzdem erzeugt und der vorherige trotzdem ersetzt; die Antwort nennt dann die Kennung, mit der bb_reports_get_bwa beziehungsweise bb_reports_get_sums ihn nachholt. Dasselbe gilt, wenn der Client vorher abbricht: Viele tun das nach etwa 60 Sekunden, verifiziert ist das nicht für jeden. Dann kommt gar keine Antwort an, und die Kennung steht nur noch im stderr-Protokoll dieses Servers. Wer die Frist seines Clients nicht kennt, wählt deshalb höchstens 30. Das Feld ist serverseitig und geht nicht an die API.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
bundleYes
periodNo
statusYes
successYes
wait_msNo
attemptsNo
report_typeYes
integrity_errorNo
report_id_by_customerYes
uncompletedPostingsCountNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With annotations already declaring destructiveHint=true and idempotentHint=false, the description still adds substantial context beyond them: the replacement wipes the previous same-type report tenant-wide and can destroy a concurrent user's report, posting data is untouched, and a ~60s client timeout can kill the response while the report is still created.

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 purpose and the destructive replacement behavior, but it is long and repeats the replacement idea twice ('ersetzt den zuvor erzeugten Bericht desselben Typs...' and 'Ersetzt die zuvor in BuchhaltungsButler erzeugte Auswertung desselben Typs'), slightly diluting density.

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 destructive, timeout-prone generation tool with an output schema already present, the description covers side effects, concurrent-user impact, the abort/recovery path, read-only gating, and what is never returned (no PDF/CSV) — 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; the description still adds operational meaning, e.g. advising max_wait_seconds<=30 when the client timeout is unknown and explaining report_type selects the endpoint rather than being sent to the API, which goes beyond the field-level schema text.

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+resource chain ('Erzeugt eine BWA oder eine Summen- und Saldenliste für einen Zeitraum, wartet auf die serverseitige Berechnung und liefert die fertige Auswertung im selben Aufruf zurück') and implicitly distinguishes itself from bb_reports_get_bwa/bb_reports_get_sums, which it names as the retrieval path.

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 states when to use it (generate + fetch in one call), what to do when the wait elapses or the client aborts (fetch via bb_reports_get_bwa/get_sums), and the blocking condition (BB_MCP_READ_ONLY), naming the read-only alternatives bb_reports_get_bwa/bb_reports_get_sums/bb_reports_get_ledger.

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