Skip to main content
Glama
ohneben

Buchhaltungsbutler MCP

by ohneben

Transactions: add transaction

transactions_add

Add a transaction to a payment account. Specify account number, recipient or sender, amount, and booking date to record a deposit or withdrawal.

Instructions

๐ŸŸก WRITE ยท creates data โ€” Creates new records (receipts, transactions, postings, invoices, master data). Not idempotent โ€” calling twice may create duplicates. add transaction Add a transaction to a payment account of the specified customer.

Endpoint: POST /transactions/add

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoThe transaction type (e.g. 'Direct debit'). If specified, the field will be validated. An empty string is not considered a valid type.
amountYesThe transaction's amount (positive for incoming and negative for outgoing payments) in the account's currency. '0.00' is not considered a valid transaction amount.
accountYesThe posting account number (e.g. '1200') of the account to which to add the transaction. The account must exist as a payment account for the customer.
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.
purposeNoThe transaction purpose - may also be an empty string.
to_fromYesThe payment recipient or sender
currencyNoThe transaction currency. Currently we support the following currencies: AED, AUD, BGN, BRL, CAD, CHF, CNY, COP, CYP, CZK, DKK, EUR, GBP, HKD, HRK, HUF, IDR, ILS, INR, ISK, JPY, KRW, LTL, LVL, MTL, MXN, MYR, NOK, NZD, PEN, PHP, PLN, QAR, ROL, RON, RUB, SEK, SGD, SIT, SKK, THB, TRL, TRY, UAH, USD, VND, ZAR If specified, the field will be validated. An empty string is not considered a valid type.
bank_codeNoThe bank code (or BIC) of the payment recipient or sender. If specified, the field will be validated. An empty string is not considered a valid bank code.
bank_nameNoThe bank name of the payment recipient or sender. If specified, the field will be validated. An empty string is not considered a valid bank name.
value_dateNoThe transaction's value date in format 'YYYY-MM-DD HH:II:SS' (e.g. '2017-04-26 00:00:00'). If not specified, the value date will be set to the same value as the booking date. If specified, the field will be validated. An empty string is not considered a valid date.
booking_dateYesThe transaction's booking date in format 'YYYY-MM-DD HH:II:SS' (e.g. '2017-04-26 00:00:00').
booking_textNoThe booking text - may also be an empty string.
account_numberNoThe account number (or IBAN) of the payment recipient or sender. If specified, the field will be validated. An empty string is not considered a valid account number.
payment_referenceNoThe payment reference id. If specified correctly, the added transaction will match with the corresponding receipt.
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds value by stating 'WRITE ยท creates data' and 'Not idempotent โ€” calling twice may create duplicates', but does not go beyond annotations significantly. No additional context on permissions or side effects.

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?

The description is very concise: two sentences plus the endpoint, with a clear emoji and warning. No unnecessary information.

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

Completeness2/5

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

Despite having 14 parameters and no output schema, the description does not explain return values, error handling, or the structure of the response. For a write operation, this is a significant gap.

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 descriptions for all 14 parameters. The tool description does not add any extra meaning beyond the schema; it only mentions the endpoint. Baseline 3 is appropriate.

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 description clearly states 'Add a transaction to a payment account of the specified customer' along with the endpoint. The title 'Transactions: add transaction' also reinforces the purpose. It distinguishes from siblings like 'transactions_addBatch' by focusing on a single transaction.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as 'transactions_addBatch' for batch additions or other transaction-related tools. It does not mention preconditions or exclusion criteria.

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