BuchhaltungsButler MCP-Server

Overview Schema Source Related Servers Discussions Admin

Buchungen zu Belegen anlegen

bb_postings_create_for_receipt_batch

Create postings for many existing receipts in one BuchhaltungsButler call, ideal for booking a month of incoming invoices at once.

Instructions

Legt die Buchungssätze zu mehreren vorhandenen Belegen in BuchhaltungsButler in einem Aufruf an. Zu nehmen, wenn viele Belege zu buchen sind, etwa ein Monat Eingangsrechnungen; für einen einzelnen Beleg bb_postings_create_for_receipt. Der Stapel ist nicht transaktional: success auf oberster Ebene sagt nichts über die einzelnen Einträge, das Array errors der Antwort nennt die gescheiterten. Die Antwort nennt die erzeugten Buchungen nicht; nachsehen mit bb_postings_search. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Eine festgeschriebene Buchung lässt sich nicht löschen, sondern nur mit bb_postings_cancel stornieren; der Storno bleibt dauerhaft sichtbar.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`receipts`	Yes	Die Belege mit ihren Buchungssätzen, je Eintrag ein Beleg. Der Body-Parameter der API heißt ebenfalls receipts und ist bereits eine Objektliste; umgeformt wird nur die Positionsliste innerhalb eines Eintrags. Höchstens 50 Einträge je Aufruf. Ein abgelehnter Stapel wird nicht teilweise verarbeitet.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`created`	No
`message`	No
`success`	Yes
`endpoint`	No
`reversal`	No
`_contract_warnings`	No
`fields_not_returned`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 13, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that the batch is non-transactional, that top-level success says nothing about individual entries, that failures appear in the response's errors array, and that the response does not list the created postings. It also warns that data is written to real accounting records and that finalized postings can only be cancelled, not deleted.

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

Conciseness5/5

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

Front-loads purpose, then when-to-use and the alternative, then behavioral caveats. Every sentence carries distinct information (batch semantics, follow-up lookup, irreversibility), with no filler.

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?

Given an output schema exists, return values need no restating, yet the description still flags the crucial non-transactional response shape. Combined with the annotations and schema, an agent has everything needed to call this complex batch write correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the nested receipt/position fields are already fully documented. The description adds no syntax or format detail for the receipts parameter itself (e.g., the 50-entry cap lives in the schema), so the baseline 3 applies.

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 (anlegen), resource (Buchungssätze), and scope (mehrere vorhandene Belege, in einem Aufruf). It explicitly names the singular sibling bb_postings_create_for_receipt, so the agent can distinguish the two 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?

Explicitly says when to use it (viele Belege, etwa ein Monat Eingangsrechnungen) and routes the single-receipt case to bb_postings_create_for_receipt. It also points to bb_postings_search for verification and bb_postings_cancel for reversal, covering the surrounding workflow.

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

Deploy Server