Loading ToolBench
Semantic memory layer for Obsidian vaults — local-first indexing, multi-signal retrieval
Server has 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (vault_search, vault_fts, vault_entity, vault_facts, vault_status, vault_remember, vault_store_fact). Descriptions are present (avg ~120 chars) and explain WHAT each tool does. However, parameter descriptions lack detail on constraints, formats, and valid ranges. Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (no recovery guidance, no categorization). topK parameters lack min/max bounds in descriptions. vault_remember and vault_store_fact are write operations but lack confirmation/dry-run patterns. No tool annotations (readOnlyHint/destructiveHint) present.
Look up an entity (person, project, concept) by name or alias. Returns entity details or null.
Get all known facts about an entity. Returns structured subject-predicate-object triples.
Full-text keyword search over vault chunks (BM25). Fast and exact. Use vault_search for semantic/conceptual queries.
Store a memory entry in the daily notes. Appends text to the daily note for the given date.
Semantic search over the Obsidian vault. Returns relevant text chunks ranked by semantic similarity, entity matching, graph relations, and fact overlap.
Get vault index statistics: count of notes, chunks, entities, facts, and relations.
Output schemas not documented. LLMs cannot predict response structure (e.g., vault_search returns 'hits' array, but field names and types are not declared). Agents cannot plan downstream tool calls without knowing what fields to extract.
Parameter constraints missing from descriptions. topK parameters accept 1-100 or 1-50 but descriptions do not state min/max bounds. LLMs may pass invalid values (0, negative, >100). Descriptions should include 'Number of results (1-100, default 5)' format.
Write operations (vault_remember, vault_store_fact) lack confirmation or dry-run patterns. Agents cannot preview changes before committing. No error recovery guidance if write fails (e.g., 'date format invalid' should suggest YYYY-MM-DD).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Store a structured fact. Creates entity if it does not exist. Format: subject-predicate-object (e.g. "Alice works_at Globex").
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Clients cannot distinguish safe reads from destructive writes. vault_remember and vault_store_fact should be marked destructiveHint=true; vault_search, vault_fts, vault_entity, vault_facts, vault_status should be marked readOnlyHint=true.
Error handling is minimal. No recovery guidance in error responses. If vault_entity returns null or vault_store_fact fails due to invalid predicate, LLM receives no hint on what to try next. Should return 'Entity not found. Try vault_search() to discover entities.' or 'Invalid predicate. Use: works_at, is_a, uses, located_in.'