Skip to main content
Glama
ohneben

Buchhaltungsbutler MCP

by ohneben
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Postings: cancel posting

postings_cancel
DestructiveIdempotent

Cancel a posting to take it out of the books. Unfixed postings are deleted; fixed ones are reversed with a balancing entry.

Instructions

🔴 DESTRUCTIVE · deletes data: Deletes or cancels a record. Confirm with the user before calling. Receipt deletes are restorable; cost-location deletes are not. Cancelling a posting deletes it if it is not yet fixed, otherwise it books a reversal posting.

cancel posting

Cancel a specified posting. Postings that are not fixed are deleted, fixed postings are cancelled by creating a reversal posting.

Use to take a booking out of the books entirely.

This is stronger than the postings_unconfirm_* tools: those keep the posting and only clear its confirmation, this one removes or reverses it. Prefer unconfirming when the goal is to edit and rebook.

The effect depends on the posting: one that is not yet fixed is deleted outright, a fixed one stays and is offset by a reversal posting, which leaves two visible entries in the journal. Confirm with the user before calling.

Endpoint: POST /postings/cancel

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
posting_id_by_customerYesThe id_by_customer of the posting.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageNoSuccess message
successYesSuccess boolean

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.2
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "message": {
+      "description": "Success message",
+      "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

A4.2/5.0
Behavior4/5

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

The description goes well beyond the destructiveHint annotation by explaining what happens to fixed vs non-fixed postings, the two-visible-entries consequence of reversals, and the requirement to confirm with the user. The note that 'receipt deletes are restorable; cost-location deletes are not' adds context but is somewhat disconnected from a postings-cancel operation and could cause confusion.

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 description front-loads the destructive warning and confirmation requirement, which is good. However, the fixed/unfixed deletion vs reversal behavior is explained multiple times in different paragraphs, and the endpoint line plus generic delete preamble add redundancy that could be trimmed without losing safety-critical information.

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?

For a single-parameter tool with an output schema and safety annotations, the description covers purpose, side effects, user confirmation, and alternatives to sibling tools. It stops short of top marks because the restorability sentence feels tangential and idempotency is only implied by annotations, not clarified in the description.

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?

The schema already provides 100% coverage for the single parameter, describing it as 'The id_by_customer of the posting.' The description does not add further semantic detail about where this identifier comes from or how it resolves to a posting, so the baseline of 3 is appropriate.

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?

Identifies the exact operation ('Cancel a specified posting') and the resource it acts on phosphorylate. It also distinguishes itself from the postings_unconfirm_* sibling tools by explaining the deletion vs reversal semantics, so an agent can disambiguate purely from the description.

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 states when to use the tool ('Use to take a booking out of the books entirely') and contrasts it with alternative unconfirm tools, including a concrete preference rule ('Prefer unconfirming when the goal is to edit and rebook'). It also instructs the agent to confirm with the user before calling, which is strong 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

Other Tools