Buchhaltungsbutler MCP

Transactions: get transactions

transactions_list

Read-onlyIdempotent

Fetches bank transactions for a specified account and date range, returning row counts and transaction data for reconciliation and review.

Instructions

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

get transactions

Get transactions for a specified customer account. The response includes the number of returned rows and an array of transaction datas.

Use to search bank transactions by account and date range.

To fetch one known transaction, use transactions_get_by_id.

For multi-page exports, prefer id_by_customer_from with limit and fixed account/date filters: it is exclusive and forces ID-ascending order. Start at 0, then use the greatest returned ID without incrementing it; omit offset. Validate IDs and forward progress and continue until empty. Offset pages have overlapped in observed filtered exports; deduplication and an empty final page do not prove completeness. Reconcile IDs/counts and signed amounts independently. rows counts the returned page, not the grand total; concurrent changes still need a separate check.

Endpoint: POST /transactions/get

Input Schema

Name	Required	Description
`limit`	No	A limit of returned data. If no limit is given, the default will be 500. Also the maximum limit is 500. If specified, the field will be validated.
`offset`	No	The offset for paging returned data. If no offset is given, the default will be 0. If specified, the field will be validated.
`account`	No	The account number of the account the transaction is stored to. If specified, the field will be validated.
`date_to`	No	The transaction's booking date in format 'YYYY-MM-DD' (e.g. '2017-04-26'). All transaction with booking date including and before given value will be returned. An empty string is not considered a valid date.
`to_from`	No	The payer/payee of the transaction. If specified, the field will be validated.
`date_from`	No	The transaction's booking date in format 'YYYY-MM-DD' (e.g. '2017-04-26'). All transactions with booking date including and after given value will be returned. An empty string is not considered a valid date.
`id_by_customer_to`	No	The id_by_customer as an integer. All transactions to given value will be returned. The transaction with the given value will NOT be returned! NOTE: By specifying this, the sort changes to id_by_customer ASC, even if you use this in combination with date params. If specified, the field will be validated.
`id_by_customer_from`	No	The id_by_customer as an integer. All transactions after given value will be returned. The transaction with the given value will NOT be returned! NOTE: By specifying this, the sort changes to id_by_customer ASC, even if you use this in combination with date params. If specified, the field will be validated.
`date_since_last_modified`	No	A date and time in format 'YYYY-MM-DD HH:MM:SS' (e.g. '2017-04-26 13:45:00'). If only 'YYYY-MM-DD' is specified, the time defaults to '23:59:59'. All transactions whose date_updated value is later than the specified value will be returned. If specified, the field will be validated. An empty string is not considered a valid date.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.1.5Nov 1, 2026
- changedOutput schema / properties / data / items / properties / amount / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / data / items / properties / booking_date / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / data / items / properties / id_by_customer / type
```
Previous value: -[
-  "string",
-  "integer"
-]New value: +[
+  "string",
+  "integer",
+  "null"
+]
```
- changedOutput schema / properties / data / items / properties / to_from / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / data / items / properties / value_date / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
Changed2 schema fields changedv1.1.3Sep 26, 2026
- changedOutput schema / properties / data / items / properties / id_by_customer / type
```
Previous value: -"string"New value: +[
+  "string",
+  "integer"
+]
```
- changedOutput schema / properties / data / items / properties / purpose / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
Addedv1.1.2Sep 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds genuinely non-obvious behavior: `rows` is the page count not the grand total, offset pages have been observed to overlap in filtered exports, and deduplication or an empty final page do not prove completeness. The warning to reconcile IDs/counts and signed amounts independently is exactly the kind of reliability caveat annotations cannot 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?

Purpose and the sibling pointer are front-loaded before the paging caveats, which is the right ordering. However the opening "🟢 READ-ONLY: Fetches data. Makes no changes to the accounting records." duplicates `readOnlyHint`, and the completeness warning is restated twice, costing some density.

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?

For a 9-parameter list endpoint with an output schema, the description covers filtering semantics, paging strategy, sort side effects, and result-count caveats. An agent has everything needed to call it correctly and to know when the returned page is not the full answer.

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?

With 100% schema coverage the baseline is 3, and the description does add operational meaning on top: `id_by_customer_from` is exclusive, forces ID-ascending order, and requires fixed account/date filters for safe export paging. Some of that restates the schema (exclusivity and sort change are already documented on the parameters), so it is additive but partly redundant.

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 ("Get transactions for a specified customer account") plus the filter axes (account, date range) and what the response contains (row count + transaction array). It explicitly names the sibling it is not ("To fetch one known transaction, use `transactions_get_by_id`"), so an agent can route correctly without opening either schema.

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 an explicit use case ("search bank transactions by account and date range"), an explicit alternative for the single-record case (`transactions_get_by_id`), and a conditional recommendation for bulk exports using `id_by_customer_from` with `limit` instead of offset paging. It even states the preconditions and the termination rule (start at 0, use greatest returned ID without incrementing, omit offset, stop on empty).

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

Deploy Server