Loading ToolBench
Local retrieval layer and optimizer for your Markdown knowledge base. CLI + MCP server: ranked evidence for any AI client, stale-note detection, session harvesting.
NeuroStack demonstrates solid definition quality with well-documented tools, clear naming conventions, and comprehensive parameter descriptions. All 11 tools follow verb_noun naming patterns (vault_read_file, vault_remember, vault_search, etc.). Descriptions are detailed and contextual, ranging from 150 - 400+ characters, well above the 10 - 1024 baseline. Most parameters include type information and context-specific descriptions. However, output schemas are not explicitly documented in the visible code, tool responses are described narratively but lack formal JSON Schema output declarations. Error handling is mentioned conceptually (e.g., 'near_duplicates' in vault_remember) but recovery guidance is minimal. The vault_read_file tool demonstrates strong parameter design with offset/limit for pagination and size_chars + truncated flags in responses, matching pattern:paginated-result. vault_context and vault_search show good composition design with flexible filtering and token budgets. Risk classifications are present (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) but not modeled as formal tool annotations.
Get a compact ~500 token session brief. Includes: recent vault changes with summaries, git commits, recent memories, top connected notes, time-of-day context.
Assemble task-scoped context for session recovery after /clear or new conversation. Unlike session_brief (time-anchored status snapshot), this is task-anchored: it retrieves memories, triples, summaries, and session history relevant to a specific task description, respecting a token budget.
Delete a specific memory by ID. The memory leaves the working set (search, drift, ranking) but is archived, not destroyed — `neurostack memories restore ID` brings it back.
Search or list agent-written memories. Without a query, lists recent memories. With a query, searches by content using FTS5 + semantic similarity.
Merge two memories. Source is folded into target; source is deleted. Use this after vault_remember reports near_duplicates. Keeps the longer content, unions tags, keeps the more specific entity type, and tracks the merge in an audit trail.
Output schemas not explicitly documented. While parameter input schemas are well-defined (types, descriptions, ranges), return types and field structures are only described in narrative text. LLMs cannot reliably parse unstructured response descriptions to extract chaining IDs (e.g., memory_id after vault_remember) or downstream dependencies.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) absent. Risk levels are manually documented in the source (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) but not exposed to clients via formal tool annotations. Clients cannot automatically determine tool safety or retry semantics without parsing descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Memories whose knowledge should be promoted into vault notes. Deterministic worklist, four buckets (issue #92): 'debt' (tagged promotion-debt), 'drift' (unresolved memory_drift rows), 'dead_handoffs' (stale context memories that read as handoffs; 'open-thread' tag exempts), 'uncovered' (durable memories whose nearest note chunk is below the similarity floor — no covering note exists). Read-only; a downstream agent writes the notes and clears entries via vault_update_memory/vault_forget.
Read a markdown file from the vault. By default returns the whole file. For a large note, pass `offset` and/or `limit` (both measured in characters of the decoded text) to read a bounded slice and page through it instead of pulling the whole body into context — the footprint fix behind lean reference mode (issue #62). When a bound is applied the result also carries `size_chars`, the `offset` used, and `truncated` (True when content remains past the returned slice).
Save a memory - persist an observation, decision, or learning for future retrieval. Memories are searchable alongside vault notes. Use this to record: - Architecture decisions made during a session - Bug root causes discovered - Conventions or patterns established - Context that should survive across sessions
Search the vault. One query, results ranked best first. Pick `depth` by what you are going to do with the answer: - Answering a factual question ("what IP", "which model") -> "triples". - Deciding which note to open -> "summaries", or reference_only=True. - About to edit or act on a note's content -> "full". - Unsure -> leave "auto", which starts cheap and escalates. Transcript evidence says agents mostly leave "auto" and sometimes invent values like "shallow" or "quick". Only the four names above are accepted; anything else raises rather than silently falling back, because a silent fallback reads as a working search returning the wrong footprint.
Get pre-computed summary for a note by path or search query. Returns 2-3 sentence summary + frontmatter (~100-200 tokens) instead of reading the full file (~500-2000 tokens).
Update an existing memory. Only provided fields are changed.
Error handling lacks recovery guidance. Tools document constraints (e.g., 'Absolute paths, .., dot-prefixed segments rejected' in vault_read_file) but do not specify error responses or suggest corrective actions. An LLM receiving 'Path validation failed' has no guidance on how to retry.
Destructive operations lack confirmation or dry-run patterns. vault_forget and vault_merge are permanent deletions but offer no confirm-before-execute or preview mechanism. Agents cannot safely explore the impact of merging memories before committing.
Parameter interdependencies not fully documented. vault_search accepts 'depth' with four specific values (triples, summaries, full, auto) and a note that other values are rejected with errors, but this constraint could be clearer in parameter schema. vault_update_memory offers add_tags and remove_tags alongside tags (replace), but interaction semantics need explicit documentation.