Skip to main content
Glama
Sign In
Buchhaltungsbutler MCP

Buchhaltungsbutler MCP

by ohneben
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Reports: create sums report

reports_create_sums

Request a sums and balances report (Summen- und Saldenliste) for all posting accounts. Returns an ID to retrieve the report once generated.

Instructions

🟡 WRITE · creates data: Creates new records (receipts, transactions, postings, invoices, master data). Not idempotent: calling twice may create duplicates.

create sums report

Triggers the creation of a sums report ("Summen- und Saldenliste"). The report is always created for all of the customer's postingaccounts.

The report is generated asynchronously in the background. The response contains the id_by_customer of the created report, which may be used to retrieve it once the generation has been finished.

A new report may only be requested once the generation of a previously requested report of the same type has been finished.

Use to request a sums and balances report (Summen- und Saldenliste). Step one of two.

To read the finished report, call reports_get_sums afterwards.

Runs asynchronously and returns an id. A new report may only be requested once the previous one has finished, and it replaces the previous one.

Endpoint: POST /reports/create/sums

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date_from": "<date_from>",
      "date_to": "<date_to>"
    },
    "name": "reports_create_sums"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseNoThe date the postings are taken into account by. Can be either 'date' ("Buchungsdatum") or 'date_delivery_else_date' ("Buchungs- und Leistungsdatum"). If specified, the field will be validated.
date_toYesThe last day of the period the report is created for, in format 'YYYY-MM-DD' (e.g. '2026-03-31').
file_csvNoIf true, a csv file will be created for the report additionally. If specified, the field will be validated.
file_pdfNoIf true, a pdf file will be created for the report additionally. If specified, the field will be validated.
date_fromYesThe first day of the period the report is created for, in format 'YYYY-MM-DD' (e.g. '2026-01-01').
archive_exportNoIf true, a zip archive containing the csv file and the postingaccount ledgers ("Kontenbl&auml;tter") will be created for the report additionally. If specified, the field will be validated.

Output Schema

NameRequiredDescriptionDefault
messageNoblank
successYesSuccess boolean
id_by_customerNoThe id_by_customer of the created report

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.2
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "id_by_customer": {
+      "description": "The id_by_customer of the created report",
+      "type": "string"
+    },
+    "message": {
+      "description": "blank",
+      "type": "string"
+    },
+    "success": {
+      "description": "Success boolean",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changedv1.1.0
    • removedInput schema / properties / api_key
      Removed value: -{
-  "description": "Optional. The BB customer api_key to act on. Defaults to the BB_API_KEY configured on the server — only set this to target a different customer.",
-  "type": "string"
-}
  3. Addedv1.0.2

TDQS

A3.6/5.0
Behavior4/5

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

Description adds meaningful behavior beyond annotations: asynchronous background generation, response contains id_by_customer, one report at a time, and that a new request replaces the previous one. Annotations already indicate write and non-idempotent, and the description reinforces these; it does not fully explain how the caller knows generation has finished, but output schema likely covers response details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is padded with redundant statements: async behavior and the one-report-at-a-time constraint are each stated twice, and the opening write-header is generic and partly misleading. A tighter version would front-load 'create sums report' and keep the constraint once.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations cover idempotency/write semantics, the description is reasonably complete for an async create tool: it names the follow-up read call, the id returned, and the serialization constraint. It does not explain how to detect completion or what happens if a request is made while another is still running, which is a notable gap for an async workflow.

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 has a solid description (date_from/date_to formats, file_csv/file_pdf/archive_export booleans, base selection). The tool description does not need to repeat these; it adds no extra parameter-level meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it 'Triggers the creation of a sums report' and names the German 'Summen- und Saldenliste', with the sibling 'reports_get_sums' explicitly distinguished as the follow-up read step. However, the opening generic line 'Creates new records (receipts, transactions, postings, invoices, master data)' is boilerplate that inaccurately implies a broader record-creation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage direction: 'Use to request a sums and balances report', 'Step one of two', and 'To read the finished report, call reports_get_sums afterwards'. It does not explicitly contrast with reports_create_bwa or other report variants, but the create-then-get flow is clear.

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

Deploy Server

Other Tools