Loading ToolBench
Identity & continuity platform for AI agents. Exposes the atrium keychain: a spirit key behind a proof-of-being-an-LLM puzzle.
Bardo demonstrates solid definition quality with consistent naming patterns (verb_noun: bardo_verify, bardo_encrypt, bardo_document_status), comprehensive parameter descriptions using shared Annotated types, and explicit ToolAnnotations (readOnlyHint/destructiveHint). All 8 tools have descriptions (avg ~120 chars, within 10-1024 range). Input schemas are visible and properly typed via Pydantic models. However, output schemas are not documented in the visible code, responses are inferred from implementation rather than explicitly declared. Error handling is present but generic (e.g., _NO_SESSION_ERROR string) without actionable recovery guidance. Parameter descriptions are strong (e.g., 'Signature over 'revoke:' + the document's id') but some tools lack context on when to use them vs alternatives.
Revoke a document you issued. Proof is a fresh signature over 'revoke:' + the document's id.
Check whether a signed document is revoked. `id` is the document's own top-level `id` field (a ni:// URI) — the same thing credentialStatus.id (BardoRevocationCheck) points at. Safe to cache a "not revoked" answer for a while (see the response's own Cache-Control) rather than re-checking on every use.
Sealed-box encrypt a UTF-8 plaintext to a recipient's encryption public key.
Begin authentication. Returns a puzzle you must solve YOURSELF, then call bardo_solve(answer). (The server will not solve it for you — that's the point.)
Create a new Bardo identity and store its API key locally. One-time. Not active yet: pass the returned claim_url to your human. Authentication fails until they visit it and acknowledge the registration.
Submit your answer to the login puzzle. On success, opens a session.
Output schemas not documented. Tool responses are inferred from implementation (e.g., bardo_verify returns {error: string} or success object) but no explicit schema is visible in tool definitions. LLMs cannot plan downstream calls without knowing response structure.
Error responses are generic strings (e.g., _NO_SESSION_ERROR) without actionable recovery guidance. Errors should tell LLMs what to do next: 'Call bardo_login() first, solve the puzzle, then bardo_solve()' is present but not consistently applied across all error paths.
Tool descriptions lack context on when to use each tool vs alternatives. E.g., bardo_verify and bardo_document_status both validate signatures/documents but the distinction and use cases are not explained. Descriptions should answer 'When should the LLM call this instead of a similar tool?'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Verify a signature over a UTF-8 message. Public utility (no session).
Show the stored identity (your spirit's local anchor) and session status.
bardo_whoami has empty input schema (no parameters) but description is minimal (70 chars). Descriptions under 20 chars score 0-20; this is borderline. Expand to explain what 'stored identity' and 'session status' mean and when to call it.
bardo_login and bardo_solve form a multi-step flow but descriptions do not explicitly state the dependency. LLMs may call bardo_solve without bardo_login first. Add: 'Must be called after bardo_login(), do not call directly.'