Loading ToolBench
Local recorder for AI conversation history. Transportable AI memory — MCP server for the Bob protocol. Local-only, no cloud, no embeddings.
brain-mcp demonstrates strong definition quality with clear, specific tool names and comprehensive parameter schemas. All 7 tools are explicitly registered with detailed descriptions and well-structured input schemas. However, there are gaps in output schema documentation and some parameter descriptions lack actionable detail around constraints and error guidance. The tool descriptions are exceptionally well-written (150-250 chars each), explaining not just WHAT the tool does but WHEN to use it and the philosophical commitment to citations and abstention. Schema depth is solid with type definitions, descriptions, and appropriate defaults. The main weakness is that output structure is not formally documented, forcing LLMs to infer result shapes from descriptions alone.
Sync lake/ + manifest/ to dest (pure-add, content-addressed), then verify by re-hashing sampled files at the destination. The verify can fail — that is the point.
Spool depth, heartbeat file ages (side-effect mtimes, never self-report), floor totals. Distinct from health: a backing-up spool is invisible to health until it becomes staleness.
Raw floor bytes for a cited span. Pass the citation's sha256 as expect_sha256 to verify; a mismatch is reported, never repaired.
Origin-vs-floor staleness per lane. fresh = floor holds everything the agent's own files show; stale = the agent has content the recorder missed; unknown = unmeasured, NOT healthy (mandatory reason attached).
Time-ordered recent messages, every row cited. An empty result states its coverage — silence never renders as an answer.
Keyword (BM25) search over all recorded conversations. Every hit carries a mechanically verifiable citation; zero hits return an explicit abstention with coverage. role='user' answers 'what did I say'; order='time_asc' reads a thinking trajectory.
Output schemas are not formally documented in tool definitions. LLMs must infer result structure from prose descriptions alone, risking misunderstanding of returned fields and types.
brain_capture_status and brain_health descriptions mention concepts ('spool depth', 'heartbeat file ages', 'staleness vs fresh') without defining them for LLM clarity. An LLM unfamiliar with recorder internals cannot confidently interpret these outputs.
The 'date' parameter in brain_sessions accepts 'Optional date or date range filter' but does not specify the format. Is it ISO 8601 (2024-01-15), YYYYMMDD, or natural language (today, last week)? LLMs will guess.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Session cards (agent, span, message counts, floor file) for a date or range. A whole session's raw text is brain_get(file, [1, n]).
brain_search 'min_rank' parameter lacks context on the BM25 ranking scale. Is it 0-1, 0-100, or unbounded? Without this, LLMs cannot reason about appropriate threshold values.
brain_get 'context' parameter description ('Number of context lines to include') doesn't explain behavior when lines span a file boundary or when context extends beyond file length. Edge-case handling is implicit.