| FMRS | 60 / 100 · C | 84 / 100 · B | 60 / 100 · C |
|---|
| Reliability | 9 / 20 | 17 / 20 | 10 / 20 |
|---|
| Security and permissions | 13 / 20 | 16 / 20 | 11 / 20 |
|---|
| Maintenance | 10 / 20 | 16 / 20 | 10 / 20 |
|---|
| Documentation | 15 / 20 | 17 / 20 | 16 / 20 |
|---|
| Setup experience | 13 / 20 | 18 / 20 | 13 / 20 |
|---|
| Best for | - Users who want to access a local Obsidian vault through multiple MCP clients.
- Note workflows that need to preserve raw formatting for unmodified frontmatter fields.
- Knowledge-base users who need local file operations, search, and tag management.
| - Local assistants that need to work inside explicitly approved directories
- Individuals and development teams that want path-based data boundaries
| - Obsidian users already running the Local REST API plugin.
- MCP client users who need structured note search and surgical editing.
- Deployments that need vault access restricted by read and write folder allowlists.
|
|---|
| Not for | - Users without an Obsidian vault or local vault directory.
- Users seeking a remote network service, cloud-hosted service, or non-MCP integration.
- Users who do not want an AI assistant to access or modify vault content and structure.
| - Highly sensitive environments that cannot allow model access to local file contents
- Shared remote file-service use cases
| - Environments without the Obsidian Local REST API plugin installed and enabled.
- Teams seeking a cloud-native multi-user database or collaboration platform.
- Situations where note write access or local API-key management is unacceptable.
|
|---|
| Required permissions | - Requires Node.js 18 or later.
- Requires read access to the specified vault; writing, moving, and deleting also require the corresponding write permissions.
- The server can access allowed `.md`, `.markdown`, `.txt`, `.base`, and `.canvas` files.
- The AI assistant can see allowed file content, directory structure, and some file metadata.
| - Read access to every local directory listed in the configuration
- Filesystem write access when write or move tools are enabled
| - Requires OBSIDIAN_API_KEY to access the Obsidian Local REST API.
- By default, the full vault is accessible; OBSIDIAN_READ_PATHS and OBSIDIAN_WRITE_PATHS can restrict folders.
- All writes can be disabled globally with OBSIDIAN_READ_ONLY=true.
- HTTP deployments support none, jwt, or oauth authentication; JWT mode requires MCP_AUTH_SECRET_KEY.
|
|---|
| Risks and side effects | - The server provides full read/write access within its security boundaries, so incorrect instructions can modify or delete notes.
- Vault content, structure, and file metadata may be exposed to AI conversations with access.
- Permanent deletion may be unrecoverable; back up the vault before write operations.
- Path filtering does not isolate content, so sensitive data in allowed files remains readable.
| - Sensitive files inside an allowed directory may enter model context
- Write and move tools change real files; keep scopes narrow and maintain backups
| - Write tools can modify or delete vault content; obsidian_delete_note permanently deletes notes.
- Command-palette commands may be destructive and are disabled by default.
- An unauthenticated public HTTP deployment may let callers use the server's API key to access the vault.
- The HTTPS plugin endpoint uses a self-signed certificate and TLS verification defaults to false.
- The tag list and obsidian://tags resource are vault-wide and may expose tag names outside the read scope.
|
|---|
| Supported clients | Claude Desktop, Claude Code, OpenCode, Goose Desktop, ChatGPT Desktop, IntelliJ IDEA 2025.1+, Cursor IDE, Windsurf IDE, Ontheia, Microsoft Copilot Studio, OpenAI Codex | Claude Desktop, Cursor, Cline, Windsurf | Claude Desktop, Cursor, VS Code |
|---|
| Tools | 14 | 6 | 14 |
|---|