Buchhaltungsbutler MCP

Settings: get postingaccounts

postingaccounts_list

Read-onlyIdempotent

Lists posting accounts from the chart of accounts so you can find the right account number before booking, with paging and filters to exclude debtors, creditors, or base accounts.

Instructions

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

get postingaccounts

Get all postingaccounts

Use to list the chart of accounts, for example to find the posting account number for office supplies before booking.

Not bank accounts. For the bank, cash and credit-card accounts transactions belong to, use accounts_list.

Supports limit and offset; a full SKR chart runs to several hundred rows. Do not assume rows is the grand total: continue paging until empty and check progress, or filter instead. v1 offers no delete endpoint for posting accounts.

Endpoint: POST /settings/get/postingaccounts

Input Schema

Name	Required	Description
`limit`	No	limit of the results, default is 1000 results. If specified, the field will be validated.
`order`	No	the order of the results.The following options are valid:postingaccount_number ASC \| DESCname ASC \| DESCtype ASC \| DESC. If specified, the field will be validated.
`offset`	No	offset of the results, default is 0. If specified, the field will be validated.
`exclude_debtors`	No	exclude all debtor postingaccounts from result. If specified, the field will be validated.
`exclude_accounts`	No	exclude all base accounts (e.g. bank accounts) from result. If specified, the field will be validated.
`exclude_creditors`	No	exclude all creditor postingaccounts from result. If specified, the field will be validated.
`exclude_postingaccounts`	No	exclude all postingaccounts from result. If specified, the field will be validated.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.1.5Nov 1, 2026
- changedOutput schema / properties / data / items / properties / name / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / data / items / properties / parent_postingaccount_number / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / data / items / properties / postingaccount_number / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / data / items / properties / type / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
Changed2 schema fields changedv1.1.3Sep 26, 2026
- changedOutput schema / properties / data / items / properties / parent_name / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / data / items / properties / subtype / 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 read-only, idempotent, non-destructive behavior, but the description adds useful operational context: large result sets, paging until empty, and no delete endpoint in v1. It does not cover auth or rate limits, but for this read-only listing tool the added pagination behavior is the main gap-filler.

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 read-only status and use case are front-loaded, and the paragraph is generally efficient. There is some redundancy from the emoji header, bold title, repeated 'Get all postingaccounts', and endpoint line, but it does not obscure the key guidance.

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 has an output schema, so return values need not be explained. The description covers purpose, alternative tool selection, pagination limits, and the lack of a delete endpoint, which is complete enough for an agent to call this list endpoint correctly.

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 description coverage is 100%, so all seven parameters are already documented in the schema. The description mentions `limit` and `offset` pagination but does not add meaning for `order` or the exclude flags, so it only marginally supplements the 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?

The description gives a specific verb and resource ('Get all postingaccounts') and explicitly frames it as listing the chart of accounts. It also distinguishes it from the sibling `accounts_list` for bank/cash/credit-card accounts, so an agent can select it without opening both 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?

It states a concrete use case ('find the posting account number for office supplies before booking') and names the alternative tool when bank accounts are needed. It also gives pagination guidance, including continuing until empty and filtering instead of assuming `rows` is the total.

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

Deploy Server