Buchhaltungsbutler MCP

Settings: get debitors

debtors_list

Read-onlyIdempotent

List customers and retrieve debtor IDs for bookkeeping operations in Buchhaltungsbutler. Read-only tool to fetch debtor records with optional limit and offset.

Instructions

🟢 READ-ONLY: Fetches data. Makes no changes to the accounting records.

get debitors

Get all debitors

Use to list customers, for example to resolve a customer name to the debtor id the receipt and posting tools expect.

For suppliers you buy from, use creditors_list.

Supports limit and offset. v1 offers no delete endpoint for debtors, so they can only be created, listed and updated.

Endpoint: POST /settings/get/debtors

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	limit of the results, default is 25 results
`offset`	No	offset of the results, default is 0

Output Schema

TableJSON Schema

Name	Required	Description
`data`	No	An array of debitors
`rows`	No	Number of returned rows
`message`	No	blank
`success`	Yes	Success boolean

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.1.3Sep 26, 2026
- changedOutput schema / properties / data / items / properties / email / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / data / items / properties / uid_ch / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
Addedv1.1.2Sep 15, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive. Description reinforces this with 'READ-ONLY' and adds the endpoint, limit/offset support, and the note that v1 has no delete endpoint for debtors, providing lifecycle context beyond annotations.

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?

The description is front-loaded with safety and purpose, then usage guidance and limitations. It is efficient, though it repeats 'Get all debitors' in a heading which is minor.

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?

The tool is simple, and with full schema coverage, output schema, and safety annotations, the description covers the use case, alternatives, and API version limitations. Nothing essential is missing.

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 already fully documents limit and offset with defaults. Description only mentions they are supported without adding new semantics, so it adds no value beyond schema.

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 clear verb 'Get all debitors' and resource, and explicitly differentiates from creditors_list by referencing suppliers. Also explains the practical use case of resolving customer names to debtor ids.

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?

Explicitly says when to use: to list customers, and when not: for suppliers use creditors_list. Provides an example scenario, leaving no ambiguity.

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

Deploy Server