Loading ToolBench
Governed memory for AI agents: explicit states, fail-closed sensitivity gates, quarantine-only writes (dependency-free MCP server) plus a blind-evaluation protocol skill.
Strong governance-focused design with clear, well-documented tools. All 8 tools have descriptions (avg 180 chars, within 10-1024 baseline). Input schemas present for all tools with proper types and enums. Tool names follow verb_noun pattern (governed_read, governed_search, governed_propose). Key strength: descriptions explain WHAT, WHEN, and governance implications. Weakness: output schemas not formally documented in source; error handling guidance minimal; no tool annotations (readOnlyHint/destructiveHint). Composition is excellent, each tool has single responsibility, clear data flow between read/propose/audit tools.
Read the audit log. Returns recent audit entries (tool calls, outcomes, metadata). Audit is append-only and never edited. Failures to audit are logged to stderr but do not fail the tool.
List all quarantine candidates. Returns metadata for each candidate (ID, creation time, kind, slug if applicable). Does not return candidate bodies.
Return server status: memory file count, breakdown by state and sensitivity, governance policy summary, and data directory locations.
Preview which memories would be included in context for a task, without returning bodies. Returns included and excluded memories with reasons. Useful for understanding what context is available before committing to a full read.
Propose a new memory or amendment. Creates a quarantine candidate file (never mutates canonical memory). Accepts kind ('new_memory' or 'amend_memory'), statement, and evidence. Returns candidate status and metadata. Writes are fail-closed: invalid enums and missing required fields are rejected.
Output schemas not formally documented. Tool descriptions explain what is returned (e.g., 'Returns frontmatter metadata (state, sensitivity, description, state_since) and body content'), but no JSON Schema definitions for response objects are visible in source code. LLMs cannot reliably extract fields or plan downstream calls without explicit output schemas.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While descriptions mention 'READ_ONLY' and 'WRITE' risk levels, these are not machine-parseable tool annotations. Agents cannot automatically classify tools as safe-to-retry or destructive without reading descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Read a quarantine candidate by ID. Returns the full candidate proposal with metadata. Candidates are never auto-promoted; reading a candidate does not mutate canonical memory.
Read a single memory by slug. Returns frontmatter metadata (state, sensitivity, description, state_since) and body content only if sensitivity is 'ordinary' or GOVERNED_EXPOSE_SENSITIVE=true. Non-releasable bodies are withheld with bodyWithheld=true.
Search memories by query. Returns ranked results with slug, description, state, sensitivity, and bodyIndexed flag. Non-releasable memories are matched on slug and description only; their bodies are never indexed. Reports bodySuppressedMatches and unreadableFiles.
Error handling lacks recovery guidance. Source shows fail-closed validation (e.g., 'invalid enums and missing required fields are rejected') but no visible error response structure or actionable guidance for LLMs. E.g., if slug validation fails, what should the agent do next?
Parameter descriptions lack format constraints. 'slug' parameter described as 'lowercase alphanumeric and hyphens, 1-120 characters, must start with alphanumeric' in tool description, but not in parameter schema description field. Constraint should be in both places for clarity.
No pagination guidance for list_candidates and audit_log. Both accept 'limit' parameter but no mention of offset/cursor, total count, or how to iterate large result sets. Agents may truncate results without knowing more exist.