ledger
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ledger_appendA | Append one action record to a tamper-evident, hash-chained log. Returns the record's chain hash. Use this to log every consequential action (tool calls, payments, decisions) so the history can later be proven unaltered. |
| ledger_verifyA | Verify the hash chain over the log. Returns a three-valued verdict: ok=true means EVERY row verified; ok=null means no break was found but unchained |
| prove_my_conductA | Log a batch of things you just did to your own tamper-evident ledger, and get back one chain head you can hand your principal as proof. Returns {rows, head_hash, chain_verified}: |
| verify_peer_ledgerA | Another agent handed you its exported ledger as JSONL text — decide whether to trust it. Recomputes the hash chain over the text alone (no access to their machine, no writes on yours) and returns {ok, rows, first_break, declared_breaks}. |
| declare_breakA | Your own ledger is broken — something was written into it out of band. Name the break instead of hiding it. This APPENDS (never edits) a row pinning the orphaned line's exact bytes, the reason, and the date, so a known break stops reading like an unexplained one. It does NOT restore a green: the verdict becomes bounded (ok=null) and the break stays counted in |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a distinct part of the ledger lifecycle, but verification-related tools overlap in behavior: ledger_verify, prove_my_conduct, and verify_peer_ledger all return three-valued chain verdicts. The descriptions are explicit about local vs peer vs proof use cases, so an agent can disambiguate with care.
Naming is mixed: ledger_append and ledger_verify use a noun_verb pattern, while prove_my_conduct, verify_peer_ledger, and declare_break use verb_noun patterns. All names are snake_case and readable, but the inconsistent structural convention makes the set less predictable.
Five tools is well-scoped for a specialized ledger server. Each tool covers a meaningful operation without unnecessary bloat, and the count fits comfortably within the expected range for a focused tool set.
The core append, verify, declare-break, proof, and peer-verification operations are present, but there is no tool to export or read the local ledger as JSONL, which verify_peer_ledger explicitly consumes. This is a notable gap that forces agents to obtain the ledger text through out-of-band means.