Beancount.io

Revert Commit

revertCommit

Destructive

Undo one commit as a new commit. sha is the commit any write result returned (createLedgerFiles, appendLedgerText, addLedgerEntries, …), or main for the latest. Each file it touched goes back to its parent's contents in one atomic commit; CONFLICT if a later commit changed any of them. Pinned credentials can omit ledger. dry_run previews without committing.

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": {
      "sha": "<sha>"
    },
    "name": "revertCommit"
  }
}

Input Schema

Name	Required	Description
`sha`	Yes	The commit to undo: a sha that a write result returned or the commits read lists, or a branch name for its latest commit.
`dryRun`	No	Alias of dry_run, as REST and GraphQL spell it.
`ledger`	No	Ledger as owner/name; see the server instructions.
`dry_run`	No	Run every check and return the preview without committing
`message`	No	The revert commit's message; defaults to `Revert "<subject>"` and the sha it reverts.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing atomicity ('one atomic commit'), failure semantics ('CONFLICT if a later commit changed any of them'), the exact file-level effect (files revert to parent contents), and auth behavior ('Pinned credentials can omit ledger'). Annotations already flag destructive/non-idempotent, so this additive context is the right contribution.

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, each carrying a distinct fact, with the core action front-loaded. The phrasing 'sha is the commit any write result returned' is slightly telegraphic, costing a small amount of clarity, but nothing is padding.

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, non-idempotent write tool with an output schema and full annotation coverage, the description supplies everything an agent needs before calling: effect scope, conflict failure mode, credential/ledger handling, and the preview path.

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 100%, so the baseline is 3, but the description adds real meaning: it explains accepted sha sources, notes that 'ledger' may be omitted under pinned credentials, and clarifies that dry_run previews without committing. Only the default message format is left purely to the schema.

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 ('Undo one commit as a new commit'), and immediately clarifies that the revert is itself a new commit rather than a history rewrite, which is the key distinction an agent needs. No sibling performs a revert, so no explicit sibling differentiation is required.

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?

Explains when this applies (undoing a single commit), where the sha comes from (a write result or 'main' for latest), and routes preview intent to dry_run. It does not name any alternative tool or exclusion, but there is no overlapping sibling operation to steer away from.

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.