Loading ToolBench
Provider-agnostic CLI and MCP server that signs, hash-chains, and verifies compute usage receipts (GPU-hours, workload type, hardware) so any third party can audit them without trusting the issuer.
ComputeLedger defines 4 tools with complete input schemas (Zod + Pydantic), clear naming (verb_noun pattern), and exceptionally detailed descriptions (200-400 chars each). All parameters are typed and described. However, output schemas are documented only in prose, not as formal JSON Schema. Tool descriptions are excellent for domain experts but could be more concise for LLM parsing. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles (record_usage is WRITE, others are READ_ONLY). Error handling guidance is present but not structured as recovery patterns.
Lists every signed usage receipt recorded in the local ComputeLedger ledger, in insertion order. Call this to inspect or export local compute-usage history, e.g. before running verify_ledger, or to summarize usage across providers. Nothing must exist beforehand; a missing or empty ledger returns an empty list, not an error. Side effects: read-only, reads the local ledger file but never writes to it, makes no network calls, and is fully idempotent and safe to call repeatedly. Parameters: local (optional bool, default false) - true reads ./.computeledger/ledger.jsonl in the current directory instead of ~/.computeledger/ledger.jsonl in the home directory. Equivalent CLI: `computeledger ledger list --json` (add `--local` to match local=true). Returns a JSON array of full signed receipt objects, each with the same shape record_usage returns (version, id, timestamp, provider, hardware, usage, command, prevHash, publicKey, hash, signature). Feed any single entry into verify_receipt, or call verify_ledger to check the whole chain at once.
Records one unit of compute usage (provider, hardware, duration, and optional GPU-hours/FLOPs/workload type) as a signed, hash-chained receipt in the local ComputeLedger ledger, and returns that receipt as portable, independently verifiable proof of the usage claim. Call this after a workload finishes (or with measured/estimated values) when you need durable evidence of compute consumed, e.g. reconciling a provider's bill or building a cross-provider audit trail. Do not call it for read-only lookups (use list_ledger) or to check a receipt you already have (use verify_receipt). Requires a local Ed25519 keypair generated beforehand via `computeledger keys generate`; the call fails if none exists. Side effects: mutating and NOT idempotent, each call appends a new entry (fresh UUID and timestamp) to the local ledger file (~/.computeledger by default, or ./.computeledger when local=true) and reads the private key from disk. No network calls are made. On failure (missing keypair, invalid duration, etc.) it returns is_error=true with a JSON {"error": "<message>"} body instead of raising. Parameters: provider (str, e.g. 'aws', 'lambda-labs', 'on-prem'), hardware (str, e.g. 'nvidia-h100', 'nvidia-a100', 'cpu'), durationSeconds (float >= 0), gpuHours and estimatedFlops (optional float >= 0), workloadType (optional enum: training | inference | unknown), local (optional bool). Equivalent CLI: `computeledger record --provider aws --hardware nvidia-h100 --duration-seconds 3600 --gpu-hours 1 --workload-type training --json`. Returns the full signed receipt as JSON: version, id, timestamp (ISO-8601 UTC), provider, hardware, usage {durationSeconds, gpuHours, estimatedFlops, gpuUtilizationSamples, workloadType}, command, prevHash, publicKey, hash, and signature. Pass this object straight into verify_receipt to independently confirm it.
Output schemas documented in prose only, not as formal JSON Schema. LLMs cannot parse unstructured descriptions to infer response structure for downstream tool chaining.
Tool descriptions exceed 200 chars and include implementation details (e.g., 'reads the private key from disk', 'no network calls'). While accurate, these distract from the core action. Descriptions should be 50-150 chars for optimal LLM parsing.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles. record_usage is destructive and non-idempotent; verify_* and list_* are read-only and idempotent. Annotations enable agents to reason about safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Verifies every entry's signature AND the unbroken hash-chain linkage across the entire local ledger in one call, catching forged receipts as well as deleted, reordered, or spliced-in entries that a single-receipt check (verify_receipt) cannot detect on its own. Call this for a full integrity audit of the local ledger before trusting exported totals, or periodically as a tamper-detection check. Requires an existing ledger (see list_ledger); an empty ledger verifies as valid with entryCount 0. Side effects: read-only, reads the local ledger file but never writes to it, makes no network calls, and is fully idempotent and safe to call repeatedly. Parameters: local (optional bool, default false) - true reads ./.computeledger/ledger.jsonl in the current directory instead of ~/.computeledger/ledger.jsonl in the home directory. Equivalent CLI: `computeledger ledger verify --json` (add `--local` to match local=true). Returns {"valid": true, "entryCount": N} on success, or {"valid": false, "entryCount": N, "firstInvalidIndex": i, "firstInvalidReason": "<reason>"} on failure, pinpointing exactly which entry broke the chain and why (e.g. "chain_broken", "invalid_signature", "hash_mismatch", "unsupported_version", "malformed_receipt").
Independently checks whether a single signed ComputeLedger receipt is authentic and untampered, without needing to trust whoever issued it. Call this whenever you're handed a receipt (from record_usage, `computeledger record`, or a third party) and need to confirm it's cryptographically valid before trusting the usage numbers inside it. No prerequisites: it needs nothing on local disk beyond the receipt object itself, and does not require the signer's private key. Side effects: read-only, no ledger writes, no file access beyond the in-memory argument, no network calls. Fully idempotent, the same receipt always verifies the same way. It never raises on an invalid receipt, instead it returns a normal result with is_error=true, so check the 'valid' field rather than relying on an exception. Parameters: receipt (dict) - the full signed receipt object as produced by record_usage or `computeledger record` (must include version, hash, signature, and the other receipt fields). Equivalent CLI: `computeledger verify receipt.json --json`. Returns {"valid": true} on success, or {"valid": false, "reason": "<invalid_signature|hash_mismatch|unsupported_version|malformed_receipt>"} on failure, so callers can distinguish exactly why a receipt failed.
Error handling returns JSON objects with 'is_error' and 'error' fields, but no structured error classification (retryable, user-fixable, fatal). Agents cannot distinguish whether to retry, ask the user, or abort.
Parameter descriptions include implementation constraints (e.g., 'Requires a local Ed25519 keypair generated beforehand') but do not guide recovery. Should state: 'If missing, run `computeledger keys generate` first.'