Loading ToolBench
Local personal knowledge base with hybrid search, queryable by Claude via MCP
The second-brain MCP server defines 15 tools with consistent naming (all `brain_*` prefix) and reasonable input schemas. However, tool descriptions are brief (40-80 chars typically) and lack the context LLMs need for proper selection and usage. Parameter descriptions exist but are minimal. Most critically, output schemas are not documented in the visible code, we cannot verify what these tools return, which is essential for LLM planning. The codebase shows careful dependency pinning and well-commented setup, but the tool interface itself reads as functional but not optimized for agent interaction.
Find documents that reference a given document
Generate a brief summary of recent or high-priority documents
Accept and persist a suggested document connection
List suggested connections between documents
Identify communities and clusters in the knowledge graph
Extract and list entities from the knowledge graph
Ingest documents from stdin into the knowledge base
Output schemas not documented. None of the 15 tools include return value documentation in the visible code. LLMs cannot plan downstream tool calls or extract required fields without knowing what data structure they receive. This is a critical blocker for agentic reasoning.
Tool descriptions are too brief (40-80 chars). Most lack context on WHEN to use the tool vs. alternatives and what the LLM should expect. 'Hybrid search (full-text + semantic) over the knowledge base' does not explain the difference from brain_recall, when to prefer one, or the data structure returned.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Find documents that a given document references
List all documents in the knowledge base with optional filtering
Recall related documents based on semantic similarity to a query
Find documents that should resurface for review
Generate a weekly review of documents and insights
Hybrid search (full-text + semantic) over the knowledge base
Retrieve full content of a specific document by ID
List documents in chronological order
Parameter descriptions are minimal and lack constraint details. 'Maximum number of results to return' does not specify the range (e.g. 1-100). 'Document title' does not indicate if it must be unique or can contain special characters.
No error handling guidance visible. If brain_show receives an invalid document_id, what does the LLM get back? A 404? A structured error with recovery suggestions ('Try brain_search() to find valid documents')? Without this, LLMs cannot self-correct failed calls.
brain_ingest_stdin, brain_review_weekly, brain_connect_accept are write operations but lack confirmation/dry-run patterns. An LLM might accidentally ingest a malformed document or accept a wrong connection. No mitigation visible in the source.
Ambiguous tool overlaps. brain_search (hybrid search) and brain_recall (semantic recall) both accept 'query' and 'limit' parameters and appear to return documents. The descriptions do not clearly explain when an LLM should choose one over the other. This forces unnecessary reasoning and risks wrong selection.
brain_connect_list returns suggested connections, but the schema does not specify the data structure. Are connections returned as {from_id, to_id, score}? {source_doc, target_doc, reason}? Without this, the LLM cannot determine if brain_connect_accept parameters will work.
brain_ingest_stdin requires 'source' validated against sources.kind, but the tool definition does not document what valid source values are or how to discover them. An LLM has no way to know whether to pass 'email', 'file', 'vault', etc., without a prior discovery call.