Skip to main content
Glama
ohneben

Buchhaltungsbutler MCP

by ohneben
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Receipts: restore deleted receipt by id_by_customer

receipts_restore
Idempotent

Restore a receipt marked as deleted in Buchhaltungsbutler by its per-customer ID. Use it to undo a prior deletion and bring the receipt back into the customer's records.

Instructions

🟡 WRITE · reverts state: Reverts a prior state change (un-confirm a posting, restore a deleted receipt). Reversible.

restore deleted receipt by id_by_customer

Restore a marked as deleted receipt for a specified customer account by id_by_customer. You can get the "id_by_customer" by using the "/receipts/get method" first.

Use to bring back a receipt that was deleted with receipts_delete.

Endpoint: POST /receipts/restore/id_by_customer

Input Schema

NameRequiredDescriptionDefault
id_by_customerYesRequired per-customer record ID obtained from the corresponding list tool.

Output Schema

NameRequiredDescriptionDefault
messageNoblank
successYesSuccess boolean
id_by_customerNoblank

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.5
    • addedInput schema / properties / id_by_customer
      Added value: +{
+  "description": "Required per-customer record ID obtained from the corresponding list tool.",
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / required
      Added value: +[
+  "id_by_customer"
+]
  2. Addedv1.1.2

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare write, non-destructive, idempotent and open-world; the description adds the meaningful extra fact that the operation is a reversal and is "Reversible," which reassures an agent that the delete can be undone. It does not cover auth/permission requirements or what happens when the id refers to a non-deleted receipt, so it isn't fully transparent.

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

Conciseness3/5

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

The real instruction is front-loaded and short, but the opening boilerplate (emoji header plus a parenthetical that lists un-confirm-a-posting, an unrelated operation) and the restated bold title duplicate content without adding information. Roughly a third of the text is template noise for a single-parameter tool.

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

Completeness4/5

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

With one required parameter, full schema coverage, annotations, and an output schema, the description supplies everything an agent needs to select and call it. The only gap is failure/precondition behavior for ids that aren't in a deleted state.

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 the schema already explains `id_by_customer` as a per-customer record ID. The description adds a pointer on how to obtain it ("/receipts/get method"), but that hint conflicts in wording with the schema's "obtained from the corresponding list tool," so it adds marginal rather than clarifying value — baseline 3.

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?

"Restore a marked as deleted receipt for a specified customer account by id_by_customer" gives a specific verb plus resource and implies the inverse relationship to `receipts_delete` in the sibling list. The generic header line ("reverts a prior state change... un-confirm a posting, restore a deleted receipt") is template text that muddies the scope slightly by naming operations belonging to other tools, and the phrasing "a marked as deleted receipt" is awkward.

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?

It explicitly names the trigger case — "Use to bring back a receipt that was deleted with `receipts_delete`" — and states the prerequisite of obtaining the id via the get method first. It doesn't state when *not* to use it (e.g. an already-live receipt, or an alternative restore path), which keeps it below a 5.

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