Skip to main content
Glama
ohneben

Buchhaltungsbutler MCP

by ohneben

Postings: add receipt posting

postings_add_receipt

Add postings to a receipt by providing accounts, VATs, amounts, and texts. Requires creditor or debtor posting to be activated for the receipt.

Instructions

🟡 WRITE · creates data — Creates new records (receipts, transactions, postings, invoices, master data). Not idempotent — calling twice may create duplicates. add receipt posting Add postings for a specified receipt. Important: Receipt postings are only available if creditor or debtor posting is activated!

IMPORTANT: If you add postings to a receipt with foreign currency, you have to get that receipt (/receipts/get/id_by_customer) and find the calculated amount before performing this request.

Endpoint: POST /postings/add/receipt

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vatsYesAn array of vats. Usage: "vats" : ['vat of posting 1', 'vat of posting 2']. Possible vats: - 0_none ('keine Ust.') - 19_vat ('19% Ust.') - 7_vat ('7% Ust.') - 19_pre ('19% Vst.') - 7_pre ('7% Vst.') - 19_both_1 ('§13b 19% USt./VSt.') - 19_both_2 ('I.g.E. 19% USt./VSt.') - 7_both ('I.g.E. 7% USt./VSt.') - 19_both_1_no_pre ('§13b 19/16% USt.') - 19_both_2_no_pre ('i.g.E. 19/16% USt.') - 7_both_no_pre ('i.g.E. 7/5% USt.') - 19_pre_app ('19/16% Aufz. VSt.') - 7_pre_app ('7/5% Aufz. VSt.') - 19_both_app_1 ('§13b 19/16% USt./Aufz. VSt.') - 19_both_app_2 ('i.g.E. 19/16% USt./Aufz. VSt.') - 7_both_app ('i.g.E. 7/5% USt./Aufz. VSt.')
debtorYesThe number of the debtor. IMPORTANT: The field is only required, if you are posting to an outgoing invoice and if debtor posting is activated. If specified, the field will be validated.
amountsYesAn array of amounts. Usage: "amounts" : ['amount of posting 1', 'amount of posting 2'] Amount must be in format 0000.00
api_keyNoOptional. The BB customer api_key to act on. Defaults to the BB_API_KEY configured on the server — only set this to target a different customer.
creditorYesThe number of the creditor. IMPORTANT: The field is only required, if you are posting to an incoming invoice and if creditor posting is activated. If specified, the field will be validated.
postingtextsYesAn array of posting texts. Usage: "postingtexts" : ['text of posting 1', 'text of posting 2']
cost_locationsNoAn array of cost_locations. Usage: "cost_locations" : ['cost_location of posting 1', 'cost_location of posting 2']. If specified, the field will be validated.
postingaccountsYesAn array of postingaccount numbers. Usage: "postingaccounts" : ['number of posting 1', 'number of posting 2']
cost_locations_twoNoAn array of cost_locations_two. Usage: "cost_locations_two" : ['cost_location_two of posting 1', 'cost_location_two of posting 2']. If specified, the field will be validated.
receipt_id_by_customerYesThe id_by_customer of the receipt.
Behavior5/5

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

Description states it creates data and is not idempotent, consistent with annotations (readOnlyHint=false, idempotentHint=false). Adds value beyond annotations by mentioning potential duplicate creation and write operation.

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?

Description is longer than necessary, with redundant '🟡 WRITE' line and extensive VAT list that could be summarized. However, important notes are front-loaded and structured with bold headings.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks specification of return value/response shape. For a write tool with complex parameters, provides good usage context but not fully complete without output schema.

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?

Input schema has 100% coverage with thorough descriptions for each parameter, including usage examples. Description adds minimal extra meaning beyond what schema provides, so baseline score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Title and description clearly state 'Add postings for a specified receipt'. The verb+resource is specific. Does not explicitly differentiate from siblings like 'postings_add_batch_receipts', but the function is distinct due to the receipt parameter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit prerequisites (creditor/debtor posting activation) and important condition for foreign currency. Lacks explicit alternatives but gives actionable context for correct invocation.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ohneben/Buchhaltungsbutler-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server