Loading ToolBench
Self-hostable, OSS, multi-tenant shared memory hub for AI agents (markdown + git + MCP)
agora-kb demonstrates strong naming conventions (verb_noun pattern: kb_remember, kb_query, kb_read, kb_neighbors, kb_context, kb_status, kb_curate) and comprehensive descriptions (100-300 chars, well above the 34-char p10 baseline). All 7 tools have detailed, context-rich descriptions explaining WHAT they do, WHEN to use them, and how they compose into an agentic navigation loop. Input schemas are present with typed parameters and descriptions. However, output schemas are not explicitly documented in the source code, descriptions reference return shapes (e.g., '{id, queued, inbox_depth}' for kb_remember) but formal JSON Schema definitions for responses are not visible. Error handling guidance is minimal; tools lack recovery hints or categorization (retryable vs. fatal). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite kb_remember and kb_curate being write operations.
Return the built ADR-0027 gold pack (the same handler backs the agora://gold/{pack} resource, the gold_context prompt, and the web GET /api/gold/{pack}). Retrieve pre-built context packs for agent consumption.
Run a real consolidation against the configured adapters.yaml backend. Executes curator worker recover + run operations to materialize inbox events into the wiki.
Return the ADR-0021 local ego-graph around a note (depth clamped by existing cap). Walk a note's link neighborhood to follow connections and explore related content.
Deterministic evidence search; render the QueryResult faithfully. Returns {query, status, hits} where status is 'ok' or 'not_found' and each hit carries {repo, path, anchor, line, excerpt, match_reason, score} citations.
Read a specific note by path; return body + frontmatter + outgoing links. The agentic navigation loop: kb_query returns flat hits (citations, not synthesis); kb_read opens a cited note; kb_neighbors walks its link neighborhood.
Output schemas not formally documented. Descriptions mention return shapes (e.g., '{query, status, hits}' for kb_query) but no JSON Schema definitions are visible in source. LLMs cannot reliably parse unstructured output or plan downstream tool calls without explicit response schemas.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. kb_remember and kb_curate are WRITE operations; kb_query, kb_read, kb_neighbors, kb_context, kb_status are READ_ONLY. Annotations enable agents to reason about safety and retry semantics.
Error handling lacks recovery guidance. No descriptions explain what to do on failure (e.g., 'If kb_query returns no hits, try a broader search term'). Errors are not categorized as retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Append one immutable inbox event; return {id, queued, inbox_depth}. Non-blocking — it only appends to the per-writer inbox (CQRS write side); the captured item becomes queryable only after the curator consolidates (eventual consistency). The writer is fixed by server config, never taken from the caller.
Return server health and metadata: StateStore + live inbox/failed counts. Provides operational status of the knowledge base.
kb_context and kb_status descriptions are generic (70-75 chars). kb_context says 'Retrieve pre-built context packs' without explaining what a 'pack' is or when to call it. kb_status says 'Provides operational status' without detailing what fields are returned.
kb_neighbors 'depth' parameter lacks constraints. Description says 'clamped by MAX_GRAPH_DEPTH' but does not state the actual limit (e.g., 'max 5'). LLMs cannot infer numeric bounds from prose.