Buchhaltungsbutler MCP

Transactions: get transactions

transactions_list

Read-onlyIdempotent

Retrieve bank transactions for a customer account using account number, date range, or payer/payee filters. Quickly locate specific booking records without modifying accounting data.

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

TableJSON 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

TableJSON 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.

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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description goes well beyond that, disclosing pagination pitfalls (overlapping offset pages, rows counting only the page, need for independent reconciliation), sort order changes when using id_by_customer_from, and the exclusivity of those parameters. It also states the endpoint. This adds significant behavioral context.

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 long but well-structured: it opens with the READ-ONLY note and a one-sentence purpose, then covers usage, then the detailed export strategy. Every section adds value; the pagination advice is essential given the API's quirks. Slightly verbose, but justifiably so for the complexity. A 4 reflects the balance.

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?

Given the complexity of the API (9 optional parameters, pagination traps, sorting behavior), the description is remarkably complete. It covers purpose, usage, pagination strategy, endpoint, and response overview (rows and array). The output schema covers the exact structure, so no need to repeat it. Nothing essential is missing.

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?

The input schema has 100% parameter description coverage, so the baseline is 3. The description adds meaningful guidance on how to use specific parameters for pagination—particularly the recommendation to use id_by_customer_from with limit and fixed filters, and the warning about offset. This goes beyond the schema's per-parameter descriptions, so a 4 is warranted.

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?

Clearly states 'Get transactions for a specified customer account' and 'search bank transactions by account and date range,' with an explicit contrast to transactions_get_by_id for fetching a single known transaction. Distinguishes itself from the many sibling list tools by naming its primary use case and its main alternative.

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 'Use to search bank transactions by account and date range' and 'To fetch one known transaction, use transactions_get_by_id.' It also provides detailed pagination guidance, recommending id_by_customer_from over offset for exports, including exact steps and caveats. This is exemplary usage guidance.

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

Deploy Server