Skip to main content
Glama
dennismenken

BuchhaltungsButler MCP-Server

by dennismenken

Kreditoren auflisten

bb_creditors_search
Read-onlyIdempotent

Lists supplier creditor accounts in BuchhaltungsButler with account number, name, and address, so you can look up the right vendor before assigning an incoming invoice.

Instructions

Listet die Kreditorenkonten des Mandanten in BuchhaltungsButler auf, also die Lieferantenkonten, mit Kontonummer, Name und Anschrift. Gedacht zum Nachschlagen, bevor eine Eingangsrechnung einem Lieferanten zugeordnet wird. Sachkonten, Zahlungskonten und Debitoren liefert dieser Endpunkt nicht; dafür bb_postingaccounts_search. Einen Filter kennt er nicht, und die Zahlungsfrist due_in_days liefert er nicht mit. Ohne ausdrückliches limit liefert die API nur 25 Zeilen.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoZeilen je Aufruf. Die API dokumentiert hier keine Obergrenze für limit. Wird der Aufruf mit 'invalid limit specified' abgelehnt, den Wert halbieren. Ohne ausdrückliches limit liefert die API nur 25 Zeilen; dieses Werkzeug sendet deshalb immer ein limit mit.
offsetNoZahl der zu überspringenden Zeilen. Die zweite Seite einer Suche mit limit=100 holt offset=100.
response_formatNo'concise' liefert nur die Felder, die einen Datensatz erkennbar machen und den nächsten Schritt erlauben. 'detailed' liefert den Datensatz so, wie die BuchhaltungsButler-API ihn ausgibt. Mit 'concise' beginnen und nur für die wenigen Datensätze auf 'detailed' wechseln, die wirklich geprüft werden müssen. Dieses Feld ist serverseitig und geht nicht an die API.concise

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes
messageNo
successYes
endpointNo
limit_usedNo
offset_usedNo
more_possibleNo
rows_returnedNo
_contract_warningsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world). The description adds real behavior: no filtering support, due_in_days is not returned, and the API's 25-row default when no limit is sent. It stops short of describing pagination semantics or the response_format trade-off, which are only in the schema.

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?

Well front-loaded: purpose first, then scoping exclusions, then the alternative tool, then the behavioral caveats. Slightly dense in the second half but every sentence adds information an agent needs.

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?

An output schema exists, so return values need not be re-explained. The description covers scope, exclusions, the sibling alternative, and the key API quirk. Only minor gaps remain (pagination chaining between offset/limit is left to the 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?

Schema coverage is 100% and each parameter (limit, offset, response_format) is documented in detail, including the retry-on-'invalid limit specified' hint. Baseline 3 applies; the description only restates the 25-row default already present in the limit description.

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?

Specific verb+resource ('listet die Kreditorenkonten ... Lieferantenkonten') with the returned fields named (Kontonummer, Name, Anschrift). It explicitly excludes Sachkonten, Zahlungskonten and Debitoren and points to bb_postingaccounts_search as the sibling for those, so an agent can distinguish it from every near neighbour.

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 a concrete when-to-use ('Gedacht zum Nachschlagen, bevor eine Eingangsrechnung einem Lieferanten zugeordnet wird'), explicitly states what it does not cover and where to go instead (bb_postingaccounts_search), and warns about the no-filter limitation.

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