BuchhaltungsButler MCP-Server

Overview Schema Source Related Servers Discussions Admin

Zahlungskonto anlegen

bb_payment_accounts_create

Creates a manually managed payment account in BuchhaltungsButler, such as a cash or credit card account without a bank connection. Use the matching posting account number.

Instructions

Legt ein manuell geführtes Zahlungskonto in BuchhaltungsButler an, etwa eine Kasse oder ein Kreditkartenkonto. Gedacht für ein Konto ohne Bankanbindung. Die postingaccount_number muss zur gewählten Art passen; die bestehenden Konten und ihre Nummern zeigt bb_payment_accounts_list. Ein Aufwands- oder Ertragskonto ist kein Zahlungskonto und gehört zu bb_postingaccounts_create. is_revision_safe wirkt nur bei einer Kasse und legt dauerhaftes Verhalten fest. 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
`name`	Yes	Bezeichnung des Zahlungskontos, zum Beispiel Kasse Ladengeschäft.
`is_revision_safe`	No	true macht eine Kasse revisionssicher: Gespeicherte Zahlungen verschwinden dann nur noch über eine Stornozahlung. Laut Spezifikation wirkt die Angabe nur bei 'cash' und legt dauerhaftes Verhalten fest.
`payment_account_type`	Yes	Art des Zahlungskontos: 'cash' für eine Kasse, 'bank/institution' für ein Bank- oder Geldinstitutskonto, 'other' für alles Übrige, etwa eine Kreditkarte. Der API-Parameter heißt type.
`postingaccount_number`	Yes	Sachkontonummer des neuen Zahlungskontos als ganze Zahl, zum Beispiel 1000 für eine Kasse. Welche Nummern der Mandant schon belegt, zeigt bb_payment_accounts_list.
`receipt_creates_transaction`	No	true legt zu jedem Beleg, der diesem Zahlungskonto zugeordnet wird, selbsttätig eine Zahlung an.

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?

Annotations declare non-read-only, non-idempotent, non-destructive, open-world, but the description adds genuinely new behavioral context: it writes to real BuchhaltungsButler data, the API offers no undo endpoint, and is_revision_safe permanently locks in behavior. That irreversibility disclosure is exactly the kind of context the annotations do not carry.

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 dense with useful routing and constraint information; every sentence carries content. There is mild redundancy where the postingaccount_number guidance repeats what the schema property description already states.

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

Completeness4/5

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

For a 5-parameter mutation tool with an output schema (so return values need no explanation), the description covers purpose, eligibility, cross-parameter constraints, alternatives, and irreversibility. It does not mention permission/auth prerequisites or error behavior when a posting account number is already taken, leaving a small gap.

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 adds a cross-field constraint not in the schema ('Die postingaccount_number muss zur gewählten Art passen') and points to bb_payment_accounts_list for used numbers. It slightly duplicates the schema's own is_revision_safe note, so it is above baseline but not fully additive.

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 and resource ('Legt ein manuell geführtes Zahlungskonto ... an') with concrete examples (Kasse, Kreditkartenkonto) and scopes it to accounts without a bank connection. It also names the sibling it must not be confused with (bb_postingaccounts_create), so an agent can route correctly 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?

Explicit when-to-use ('Gedacht für ein Konto ohne Bankanbindung'), explicit when-not ('Ein Aufwands- oder Ertragskonto ist kein Zahlungskonto') with the alternative tool named, plus a pointer to bb_payment_accounts_list for choosing postingaccount_number. Nothing is left to inference.

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

Deploy Server