Loading ToolBench
Read, write, search, and traverse your vault from Claude Desktop and any AI assistant — via a built-in MCP server, no external server to run.
The Obsidian MCP plugin provides 8 tools with generally present but inconsistently detailed definitions. Tool names follow verb_noun patterns (dataview-query, graph-search-traverse), which is good. Descriptions exist for all tools and are substantive (ranging 90-300+ chars). However, parameter descriptions are sparse or missing in several tools, and output schemas are not documented in the source code provided. The vault and edit tools have broad, multi-action interfaces that blur responsibility boundaries. Error handling descriptions are largely absent. Composition is problematic: the vault tool tries to do too much (read, write, create, update, delete, list, search, move, copy, rename, combine, split, concatenate), violating single-responsibility. The plugin does show signs of maturity (it uses zod for schema validation, has comprehensive test coverage per Makefile), but tool definitions lack the precision expected for production agent work.
List all pages in the vault with metadata (path, name, size, created/modified dates, tags, links, aliases). Supports filtering by source folder or tag.
Execute a Dataview query (DQL or JavaScript) against vault data. Returns query results with type information, values, headers, and workflow suggestions.
Partial file editing operations: append, prepend, replace text, patch specific sections (headings, blocks, frontmatter fields), find-replace with fuzzy matching, and line-by-line operations.
Generate embeddings and vector search operations on vault content. Supports semantic similarity search and embedding generation.
Search and traverse the vault graph starting from a document, following links to find matching content. Returns traversal chain with snippets and workflow suggestions.
Traverse the vault graph using tag connections in addition to links. Supports tag-based filtering and analysis of tag connection strength between documents.
vault tool violates single-responsibility principle. It combines read, write, create, update, delete, list, search, move, copy, rename, combine, split, concatenate operations into one tool. LLMs will struggle to select this tool when only one action is needed, and error recovery is ambiguous.
edit tool similarly conflates multiple concerns (append, prepend, replace, patch, window, at_line). Should be split into edit_append, edit_replace, edit_patch, etc. so LLMs can pick the exact operation without guessing.
Output schemas are not documented in source code. Rubric requires documented return types for A+ quality. Users and LLMs cannot plan downstream calls or extract data when they don't know what fields to expect.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
System-level operations including fetch_web (HTTP requests to external services), platform information, environment details, and system status queries.
Primary vault operation tool supporting read, write, search, list, delete, move, copy, rename, combine, split, and concatenate operations on files and directories.
vault tool parameter 'action' accepts a free-form string without enum constraint. Description lists possible values (read, write, create, update, delete, list, search, move, copy, rename, etc.) but does not enforce them. LLMs will hallucinate invalid actions.
edit tool parameter 'action' similarly lacks enum constraint. Valid values are listed (append, prepend, replace, patch, window, at_line) but not formally defined as enum.
system tool's 'action' parameter is under-described. It says 'System action: fetch_web, platform, info, status' but does not explain what each does or when to use which. LLMs cannot select intelligently.
graph-search-traverse and graph-tag-traverse have many optional numeric parameters (maxDepth, maxSnippetsPerNode, scoreThreshold, beamWidth) with no stated ranges or defaults. Unbounded numbers risk invalid API calls.
No evidence of error handling guidance in tool descriptions. Descriptions do not explain what happens on failure, whether errors are retryable, or how LLMs should recover. Pattern recovery-guide recommends explicit recovery paths.
Dataview tools (dataview-query, dataview-list-pages) return unstructured results per description ('Returns query results with type information, values, headers'). No indication of pagination support. If queries return hundreds of rows, context window will be exhausted.
vault tool description states it is READ_ONLY but also lists WRITE actions (write, create, update, delete, move, copy). Risk classification contradicts the action set. Should clarify which actions are safe to retry vs destructive.