BuchhaltungsButler MCP-Server

Overview Schema Source Related Servers Discussions Admin

Beleg an freie Buchung binden

bb_postings_assign_receipt

Assigns an existing receipt to an existing free posting in BuchhaltungsButler. Use it when a free posting was created without a receipt and only the link needs updating.

Instructions

Bindet in BuchhaltungsButler einen vorhandenen Beleg an eine vorhandene freie Buchung. Zu nehmen, wenn eine freie Buchung nachträglich ihren Beleg bekommen soll, etwa weil bb_postings_create_free ohne Belegbezug gebucht hat; die Zuordnung eines Belegs zu einer Zahlung leistet stattdessen bb_transactions_assign_receipt. Ändert den Buchungssatz nicht, sondern nur die Verknüpfung, und legt keine Buchung an. posting_id_by_customer muss auf eine freie Buchung zeigen, sonst lehnt die API mit error_code 10 ab. Schreibt in die echten Buchhaltungsdaten von BuchhaltungsButler. Die API bietet keinen Endpunkt, das rückgängig zu machen.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`posting_id_by_customer`	Yes	Die mandantenbezogene Nummer der freien Buchung, an die der Beleg gebunden wird, zu finden über bb_postings_search. Der Wert muss auf eine freie Buchung zeigen: Sie erkennt man daran, dass receipt_id_by_customer und transaction_id_by_customer beide null sind, oder am Filter account_filter mit dem Wert 'free booking'. In Suchergebnissen erscheint sie als String; hier ohne Anführungszeichen übergeben.
`receipt_id_by_customer`	Yes	Die mandantenbezogene Nummer des Belegs, der gebunden wird, zu finden über bb_receipts_search. In Suchergebnissen erscheint sie als String; hier ohne Anführungszeichen übergeben.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`changed`	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.8/5.0

Behavior5/5

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

Goes well beyond annotations to disclose key traits: it changes only the linkage and not the posting record, creates no posting, requires posting_id_by_customer to point to a free posting or the API rejects with error_code 10, writes to real accounting data, and cannot be undone as no API endpoint exists. Annotations (readOnlyHint=false, idempotentHint=false) are consistent and amplified.

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-loads the core action, then scenarios, sibling routing, hard constraint, data impact, and irreversibility. All sentences carry information, but it is dense and could be slightly tightened; still appropriately sized for a destructive, irreversible mutation.

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?

With an output schema present, return values need not be explained. The description covers the mutation's side effects, precondition (free posting), failure signal (error_code 10), data scope, and irreversibility — everything an agent needs to call it correctly.

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 baseline is 3, but the description adds meaning: posting_id_by_customer must reference a free posting and rejection yields error_code 10. The schema already documents how to find free postings and the string-vs-int note, so the description complements rather than duplicates.

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 ('Bindet') and resources ('vorhandenen Beleg an eine vorhandene freie Buchung'), and explicitly distinguishes itself from bb_transactions_assign_receipt by naming that sibling and the condition (Zahlung) under which it applies. An agent can tell this apart from the transaction-assignment sibling without opening schemas.

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?

Gives explicit when-to-use ('wenn eine freie Buchung nachträglich ihren Beleg bekommen soll'), a concrete trigger scenario ('etwa weil bb_postings_create_free ohne Belegbezug gebucht hat'), and names the alternative tool for the other case ('die Zuordnung eines Belegs zu einer Zahlung leistet stattdessen bb_transactions_assign_receipt').

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

Deploy Server