Beancount.io

Delete Entry Source

deleteEntrySource

Destructive

Delete one entry's source text, addressed by the entry_hash listLedgerEntries returns (as entryHash or entry_hash) and sha256sum from getEntryContext. The commit message is composed from the operation; there is no message argument. A write that would add a bean-check error the ledger did not have — deleting an entry a balance assertion depends on, re-dating it past one — is refused with VALIDATION_FAILED naming each new error; pass allowInvalid: true to commit it anyway. dry_run previews without committing.

Input Schema

Name	Required	Description
`dryRun`	No	Alias of dry_run, as REST and GraphQL spell it.
`ledger`	No	Target ledger as owner/name. Required for an unpinned credential; defaults to the credential's ledger restriction.
`dry_run`	No	Run every check and return the preview without committing
`entryHash`	No	The entry's hash.
`sha256sum`	Yes
`entry_hash`	No	Alias of entryHash, as list output spells it.
`allowInvalid`	No	Commit even when the write would add bean-check errors (VALIDATION_FAILED with newLedgerErrors), instead of refusing it.
`allow_invalid`	No	Alias of allowInvalid.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`error`	No
`result`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 26, 2026

addedInput schema / properties / allow_invalid

Added value: +{
+  "description": "Alias of allowInvalid.",
+  "type": "boolean"
+}

addedInput schema / properties / dryRun

Added value: +{
+  "description": "Alias of dry_run, as REST and GraphQL spell it.",
+  "type": "boolean"
+}

addedInput schema / properties / dry_run

Added value: +{
+  "description": "Run every check and return the preview without committing",
+  "type": "boolean"
+}

addedInput schema / properties / entryHash / description
```
Added value: +"The entry's hash."
```

addedInput schema / properties / entry_hash

Added value: +{
+  "description": "Alias of entryHash, as list output spells it.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "entryHash",
-  "sha256sum"
-]New value: +[
+  "sha256sum"
+]

addedOutput schema / properties / result / properties / dry_run
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / result / properties / preview

Added value: +{
+  "description": "Per-file affected text; populated on dry runs only.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "path": {
+        "type": "string"
+      },
+      "text": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "path",
+      "text"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / result / required

Previous value: -[
-  "summary",
-  "message",
-  "entryHash",
-  "wrote",
-  "entryHashes",
-  "validation"
-]New value: +[
+  "summary",
+  "message",
+  "entryHash",
+  "preview",
+  "dry_run",
+  "wrote",
+  "entryHashes",
+  "validation"
+]

First observedOct 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description goes well beyond that: it discloses the bean-check validation gate, the VALIDATION_FAILED error shape with per-error naming, that re-dating a balance-assertion dependency counts as a new error, and that the commit message is synthesized rather than supplied. That is exactly the context an agent needs before committing a destructive write.

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?

Four dense sentences, front-loaded with the operation and its addressing scheme before the validation caveat. Each sentence earns its place, though the alias/argument notes slightly overlap with what the schema already spells out.

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 destructive single-record delete with annotations and an output schema present, the description covers the gaps that matter: how to address the record, what gets validated, how to override, and how to preview. Nothing an agent needs to call this safely 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?

Schema coverage is 88%, so the schema carries most parameter documentation. The description still adds provenance the schema lacks — which upstream call produces entry_hash and which produces sha256sum — plus the negative signal that no message argument exists. It does not touch ledger scoping or the dryRun/allow_invalid aliases, which are schema-only.

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 with precise scope: delete ONE entry's source text, not the entry itself. It also names the addressing pair (entry_hash from listLedgerEntries, sha256sum from getEntryContext), which is enough for an agent to separate it from updateEntrySource and the plural deleteEntrySources without opening a schema.

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?

Clear about the precondition (you must already hold the hash and sha256sum from prior calls) and about the override path (allowInvalid: true) and preview path (dry_run). It does not explicitly name the sibling alternatives — updateEntrySource for editing versus deleteEntrySources for batch deletion — so the when-not condition is left implicit.

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

All Beancount.io tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.