Loading ToolBench
Interact with Obsidian vault via Local REST API
The Obsidian MCP server provides 9 tools for vault file operations with basic implementations, but falls significantly short of production-grade quality across multiple dimensions. Naming follows verb_noun conventions and is generally clear (list_vault, read_file, create_file, etc.). However, descriptions lack depth and context. Parameter schemas are present but minimal, most parameters are simple strings with descriptions but no validation constraints (enums, patterns, min/max bounds). Output is returned as plain strings rather than structured JSON, forcing LLMs to parse emoji-prefixed text. Error handling returns human-readable messages but lacks categorization (retryable vs fatal) and recovery guidance. No tool has documented return schemas. The implementation shows basic competency but misses patterns essential for reliable agent operation: no pagination for search results, no output field consistency for chaining, no input validation beyond presence checks, no security considerations for path traversal, and no confirmation steps for destructive operations.
Append content to the end of an existing file in the vault.
Create a new file in the vault with the given content.
Delete a file from the vault.
List files and folders in a specific directory of the vault.
List all files and folders in the root of the Obsidian vault.
Move a file from source path to destination path in the vault.
All tools return unstructured string output with emoji prefixes instead of structured JSON. LLMs must parse 'Error: ...' or '✅ Created...' text, which wastes tokens, is error-prone, and violates the response-shaper pattern.
Destructive operations (delete_file) lack confirmation or dry-run capability. An agent error could silently delete files without recovery option. No pre-flight check or confirmation request pattern.
No input validation for path traversal attacks. Parameters like 'filepath' and 'dirpath' are accepted raw and passed to API without sanitization. Malicious input like '../../../etc/passwd' could exploit the Obsidian API.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Read the contents of a file in the vault.
Search for text across all files in the vault.
Overwrite an existing file in the vault with new content.
API_KEY and HOST are credentials exposed in environment variable names in Dockerfile and code. While environment variables are safer than parameters, the Dockerfile example sets them as ARG, which can leak in image history.
obsidian_search lacks pagination support. No limit or offset parameters, no total count in response, no next_cursor. A large vault could return thousands of results, exhausting context and causing timeout.
Parameter descriptions are minimal and generic. E.g., 'Search query string' does not explain regex support, case sensitivity, field scope, or result limits. Most descriptions are 20-40 chars and lack actionable context.
No input schema constraints (enums, patterns, min/max). Parameters accept any string. E.g., 'context_length' is typed as string but should be integer with range 1-1000. No type validation or bounds checking.
Error responses do not categorize as retryable, user-fixable, or fatal. A 'Connection timeout' error is retryable; 'API key invalid' is not. Agents cannot make intelligent retry decisions.
No output schema documentation. LLMs have no structured expectation of response fields. E.g., obsidian_list_vault returns an array 'files' from the API but the response string embeds it in prose without schema clarity.
Mutual exclusivity and parameter relationships undocumented. obsidian_create_file vs obsidian_update_file both write content but create_file silently overwrites if the file exists (PUT semantics). No guidance on when to use each.
No audit logging or permission gates. Any agent with access can delete any file. No logging of who (which agent/client) called which tool, with which parameters, or when. Compliance and incident response are impossible.