Loading ToolBench
The most feature-complete MCP server for Obsidian vaults — search, read, write, tag, link analysis, graph traversal, canvas support, and more.
The server demonstrates solid definition quality with explicit schemas, descriptions, and thoughtful security patterns. Both tools have non-empty descriptions (exceeding 20 chars), documented input parameters with type constraints, and appropriate risk classification. The tool-seam architecture (src/lib/tool-seam.ts) shows disciplined error handling and untrusted-content trust-wrapping. However, schema completeness varies: index_vault uses optional fields with unclear defaults, and descriptions, while substantive, lack explicit guidance on when to use each tool versus similar alternatives. Error handling is present but recovery guidance is not consistently detailed. The server supports tool annotations and structured output, these are strengths. Output schemas are not formally documented (no explicit ToolResult schema in responses). The 'confirm' parameter in index_vault is a clever safety mechanism but requires explanation of what happens if not provided.
Append text to the end of an existing note without altering prior content. By default, inserts a leading newline if the file does not already end in one, so appended content starts on its own line. Use for log entries, running lists, or adding new sections. Fails if the note does not exist — use create_note to make a new note first.
Build or refresh the embedding index used by `search_semantic` and `find_similar_notes`. Splits readable notes into heading-aware chunks, sends those chunks to the configured embedding provider (Ollama by default, OpenAI optional), and persists the index to `<vault>/.obsidian/cache/mcp-pro-embeddings.json`. Requires `confirm: "send-vault-text-to-embedding-provider"` so callers explicitly acknowledge that vault text will leave this tool boundary. Incremental: notes whose content hash matches the prior pass are skipped. Use `force: true` to re-embed everything (e.g., after switching models). Emits progress notifications when the client subscribes.
Output schemas not formally documented. Tools return ToolResult (CallToolResult + content array) but no explicit schema is published describing the structure of successful responses or the _meta trust field. LLMs cannot reason about downstream field extraction.
index_vault 'confirm' parameter is a literal string with unusual constraint: must be exactly 'send-vault-text-to-embedding-provider'. The description explains the safety intent, but there is no explicit enum declared in the schema. The schema shows a 'literal' type annotation in the INPUT description but JSON Schema does not have a 'literal' type, should use enum: ['send-vault-text-to-embedding-provider'] with const constraint for clarity. This may cause LLM confusion about valid values.
append_to_note uses maxLength: 1000000 (1MB) for content parameter. This is reasonable but unbounded in practice, no guidance on what happens if vault is full, disk quota exceeded, or file size limits are hit. Error handling should specify: 'If the note would exceed <limit>, the operation fails with "Note too large." Consider splitting into multiple notes.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | <=2025-11-25 | v2 |
Both tool descriptions lack explicit 'When to use this' guidance. index_vault vs other semantic search methods (if any) are not distinguished. append_to_note could specify: 'Use for logs, running lists, or adding sections. For bulk updates or replacement, use a different tool.' This helps LLMs avoid over-using the tool.
Error classification missing. No explicit guidance on which errors are retryable vs user-fixable. For index_vault, what happens if the embedding provider is unreachable? If a note is unreadable? For append_to_note, what if the path is invalid or the note is deleted mid-operation? The tool-seam sanitizes errors but does not categorize them.