Loading ToolBench
Financial correctness and release-control runtime for autonomous money-moving agents
Ledgergate demonstrates strong domain-specific design with well-structured financial tools. All 7 tools have explicit schemas with proper type definitions and descriptions. Naming follows verb_noun convention (post, reverse, open_transaction, advance, refund, balance, trial_balance). Schemas are comprehensive with nested objects, enums, and constraints (e.g., currency pattern ^[A-Z]{3}$, side enum [debit|credit]). However, descriptions are terse (10-60 chars) and lack context about when to use each tool, prerequisites, or recovery guidance. Parameter descriptions are minimal or absent. Error handling is not visible in tool definitions. Output schemas are undocumented. Tool composition is sound, each tool has single responsibility and idempotency keys support retry semantics.
Advance a transaction's lifecycle; a settle carries its entry.
The balance of one account, with the journal cursor it was read at.
Open a payment transaction for an amount.
Post a balanced journal entry.
Refund part or all of a settled transaction, with the entry that moves it.
Reverse a posted entry by id.
Every account's debits and credits, with the journal cursor.
Tool descriptions are under 60 characters and lack context. 'Post a balanced journal entry' does not explain when to use post vs advance, what prerequisites exist (balanced postings?), or what the response contains. LLMs cannot distinguish tools or plan multi-step sequences without richer descriptions.
Parameter descriptions are missing or trivial. The 'approval' parameter appears in 5 tools but has only 'an Ed25519 approval artefact issued by `ledgergate approve`', no guidance on when it is required, how to obtain it, or what happens if omitted. The 'entry' parameter in advance and refund lacks any description.
Output schemas are not documented. Tools return structured data (journal entries, balances, trial balance) but the response format is invisible in tool definitions. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2025-06-18+ | v2 |
Error handling and recovery guidance are absent from tool definitions. No indication of which errors are retryable, which require user intervention, or what the LLM should do if a posting is unbalanced or an approval is invalid.
The 'approval' parameter is required for write operations but its acquisition path is opaque. Tool descriptions do not explain the approval workflow or reference a separate 'ledgergate approve' command. This creates a hidden dependency that LLMs cannot discover.