Loading ToolBench
MCP server plugin for Obsidian that enables Claude and other AI models to interact with Obsidian vaults through semantic search, file operations, and vector database management
The Obsidian MCP Server provides 10 well-organized tools with complete type schemas and generally good descriptions. Most tools follow verb_noun naming conventions and include helpful usage guidance. However, there are notable gaps: output schemas are not documented, error handling lacks recovery guidance, and some parameter descriptions could be more precise about constraints and formats. The server handles both read-only and destructive operations but does not implement confirmation/dry-run patterns for high-risk tools. Descriptions average ~150-200 chars (within baseline) and all parameters have type definitions, placing this in the B/C+ range.
Counts the number of indexed notes and chunks in your Obsidian Vault's Orama database. Useful for checking the indexing status or scope. If the count seems incorrect, consider re-indexing your vault.
Creates a new file with the specified content at the given path within your Obsidian Vault. This tool will fail if a file already exists at the specified `relative_path`. Ensure the path is correct and points to a non-existent file location.
Creates a new folder at the specified path within your Obsidian Vault. Creates parent folders as needed.
Creates an Obsidian wikilink from one note to another (e.g., `[[Target]]`) to help build your knowledge graph. By default, this appends the link to the end of the source file.
Deletes a file from your Obsidian Vault. Provide the relative path to the file. This action is irreversible.
Deletes a folder from your Obsidian Vault. By default, only empty folders can be deleted. Set `force` to true to delete non-empty folders and all their contents.
Output schemas are not documented for any tool. LLMs cannot predict the structure of responses, forcing them to infer field names and types from unstructured text output or JSON strings.
Destructive tools (delete_file, delete_folder) lack confirmation or dry-run patterns. No mechanism to prevent accidental deletion, agent can trigger irreversible operations without explicit user approval.
Error handling is minimal. Errors return strings or JSON but do not classify them as retryable/user-fixable/fatal or suggest recovery steps. Example: 'Error: Orama database not initialized' does not guide the agent on what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 76 | 2026-07-28+ | v2 |
| 2026-04-07 | F | 27 | - | v1 |
Edits a specific range of lines within a file. Provide the relative path, starting line number, ending line number (both 1-based and inclusive), and the new content to replace the specified lines.
Lists files and sub-folders within a specified directory of your Obsidian Vault. Use '.' for the vault root. If you don't see expected files, double-check the `relative_path` provided. Note: This tool cannot access folders outside the vault.
Reads the full content of a specific note or file within your Obsidian Vault. Provide the `relative_path` from the vault root. Optionally, set `line_number` to true to prepend line numbers to each line. If the content seems wrong or the file isn't found, verify the path is correct and the file exists within the vault.
Searches your Obsidian Vault notes (indexed in Orama) for content semantically similar to your query. Returns matching note snippets. If results aren't relevant, try rephrasing your query or adjusting the `similarity` threshold (lower for broader matches, higher for stricter).
Parameter constraints lack precision. 'similarity' parameter states 'Defaults to 0.6' but does not specify the valid range (0.0 - 1.0 assumed). 'count' parameter states 'Defaults to 3' but lacks upper/lower bounds, inviting the LLM to pass unreasonable values.
Tool descriptions lack dependency hints. For instance, create_link does not mention whether target_path must exist or whether create_target_if_missing should be used if it doesn't, the LLM must guess the correct invocation pattern.
create_folder accepts relative_path but does not document whether parent directories must exist or will be created automatically. The description says 'Creates parent folders as needed' but this should be clearer in examples or explicit notes.