Beancount.io

Move Entry Sources

moveEntrySources

Destructive

Move entries into another ledger file in one commit: each entry's source text leaves its file byte for byte and is appended to toPath in ledger order. listLedgerEntries with include_source returns each entry's hash and sha256sum. Refused, writing nothing: a toPath the ledger does not load unless includeFrom is given, a stale sha256sum (CONFLICT), an entry already in toPath, and a move that adds a bean-check error (VALIDATION_FAILED, unless allowInvalid). dry_run previews without committing. revertCommit undoes the commit.

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": {
      "entries": "<entries>",
      "toPath": "<toPath>"
    },
    "name": "moveEntrySources"
  }
}

Input Schema

Name	Required	Description
`dryRun`	No	Alias of dry_run, as REST and GraphQL spell it.
`ledger`	No	Ledger as owner/name; see the server instructions.
`toPath`	Yes	Repository path of the .bean or .beancount file the entries move into; created when absent.
`dry_run`	No	Run every check and return the preview without committing
`entries`	Yes
`includeFrom`	No	A file the ledger loads that gains include "<toPath>" (relative to it) when toPath is not loaded yet. Without it, an unloaded toPath is refused.
`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.

AddedNov 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare destructive and non-idempotent, and the description goes well beyond them: source text leaves its file byte for byte, entries append in ledger order, writes are refused atomically ('writing nothing'), and specific failure codes (CONFLICT for stale sha256sum, VALIDATION_FAILED with newLedgerErrors) are named with the allowInvalid escape hatch. That is exactly the behavioral detail an agent needs before invoking 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?

Two dense sentences, front-loaded with the action and followed by the preconditions, discovery hint, and recovery path. Every clause carries information, though the packed refusal list reads as a run-on and could be split for faster scanning.

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 an output schema, rich annotations, and 88% parameter coverage, the description fills the remaining gaps: prerequisites for obtaining hashes, atomicity guarantees, refusal modes with error codes, preview behavior, and the undo path via revertCommit. Nothing essential to calling this destructive tool correctly 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 already 88%, so the schema carries most parameter documentation. The description still adds real meaning by tying sha256sum to the CONFLICT refusal, explaining how includeFrom unblocks an unloaded toPath, and framing dry_run as a full-check preview, which are interactions the per-field schema text does not fully spell out.

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?

The description opens with a specific verb and resource plus scope: 'Move entries into another ledger file in one commit,' and clarifies that only the source text moves, byte for byte, appended in ledger order. That distinguishes it from sibling mutators like deleteEntrySources or updateEntrySource without needing their schemas.

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 gives strong operational routing: call listLedgerEntries with include_source first to obtain entryHash/sha256sum, use dry_run to preview, and revertCommit to undo. It also enumerates the exact refusal conditions. It stops short of explicitly contrasting when to choose this over deleteEntrySources or updateEntrySource, so it is not a full when/when-not guide.

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.