
Obsidian CLI MCP
io.github.dariuscorvusPublished by GitHub account dariuscorvusv0.4.1Updated Oct 24, 2026
Local MCP server for Obsidian Desktop via the official Obsidian CLI.
Overview
A local MCP server that drives the official Obsidian CLI, letting an assistant search, read and edit notes, tasks, files and Canvas boards in the running Obsidi
- What you can do
- Search and read the vault: full-text search, note listing and reading, tags, unresolved links, backlinks, outlinks, task lists and note diffs, plus binary file metadata and Canvas reading.
- When to use it
- When you want an AI assistant to work inside an Obsidian Desktop vault on macOS — finding notes, drafting or appending content, managing tasks and daily notes, or building Canvas boards — without leaving the app.
- Requirements
- macOS with Obsidian Desktop installed and running, the official Obsidian CLI enabled and registered as obsidian on PATH, and Node.js 18 or newer for the npm package. No vault name, token or config file is needed for the local default; the active vault is used.
Installation
In SourceWeft
- Open Obsidian CLI MCP in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
obsidian-cli-mcp
obsidian-cli-mcp is an MCP server for
the official Obsidian CLI. It exposes Obsidian vault search, note, task,
file, link, and native Canvas operations to an MCP client. The server does not
replace Obsidian: the CLI forwards requests to the running Obsidian desktop app.
The default transport is local stdio. Remote Streamable HTTP is available as an advanced, separately secured setup; it is not required for local use.
Requirements
- macOS with Obsidian Desktop installed and running.
- The official Obsidian CLI enabled in Obsidian: Settings → General →
Command line interface, then register
obsidianon yourPATH. - Node.js 18 or newer to run the published package. Bun is only needed to build or develop this source checkout.
This project requires the desktop CLI. It does not support obsidian-headless.
The Obsidian app must remain open while the MCP server is being used.
Check the Obsidian side first:
Quickstart with npm
Start the published v0.4.1 package from any directory:
The command speaks MCP over stdio and waits for an MCP client. It intentionally does not print protocol data to the terminal. Diagnostics go to stderr.
For a source checkout instead:
No vault name, vault path, token, Cloudflare account, LaunchAgent, or config file is required for the local default. The server uses the active vault that Obsidian exposes through the official CLI.
Connect an MCP client
For a client that accepts an mcpServers configuration, use the npm command:
If the client does not inherit your shell PATH, replace npx with the
absolute path printed by command -v npx. For a source checkout, use
command: "node" and args: ["/absolute/path/to/obsidian-cli-mcp/dist/main.js"].
Restart the client after changing its MCP configuration. The first useful sequence is:
-
Call
vault_searchwith a query that should exist in your vault, for example{ "query": "meeting", "limit": 10 }. -
Pass one returned path to
note_read, for example{ "path": "<path returned by vault_search>" }. -
Preview a safe note mutation before applying it:
This is a
note_createcall. It returns the planned action and exact CLI command without changing the vault. Only usedryRun: falseafter reviewing the plan.dryRunis a preview, not an authorization boundary. -
For Canvas, preview a native Canvas file and one text node:
This is a
canvas_createcall. Review the plan, then call it withdryRun: falseif you want to create the file. Usecanvas_readto inspect the native.canvasJSON afterward. Canvas tools preserve unknown fields, validate node/edge references, and do not require arbitrary eval.
Configuration and safe defaults
An empty or missing configuration is usable for a vanilla Obsidian vault. The
optional .obsidianmcprc.yaml is discovered from the server working directory.
For clients with an unpredictable working directory, set
OBSIDIAN_MCP_CONFIG to an explicit config-file path.
The default policy is deliberately local and bounded:
- The v0.4.0 server does not expose a generic
obsidian_evaltool.eval.enabledisfalseby default; internal fixed eval snippets used by a few safe operations are not a user-supplied JavaScript escape hatch. - Imports from arbitrary local files are disabled until
imports.allowedRootsis explicitly configured. URLs are never fetched. .obsidian,.git,.trash,.Trash,Trash, and.DS_Storepath segments are blocked by default. Addpaths.allowfor a narrower vault area and add project-specificpaths.denyprefixes for more sensitive content.- Mutations expose
dryRun.file_deleterequiresconfirm: trueandnote_deleteuses Obsidian trash by default; permanent deletion requires the explicitdelete.mode: hardconfiguration. - Git autocommit is off by default.
Read-only preset
Use an explicit allowlist when an MCP client should only inspect the vault:
Safe local preset
The default has safe local guardrails but is not read-only. For an explicit safe-local surface that allows normal note edits and Canvas creation while omitting deletion, file imports, file lifecycle operations, and arbitrary evaluation:
Full trusted local preset
Omit tools.allow to expose the complete built-in tool surface, while keeping
the default protected paths, trash deletion, disabled imports, and disabled
obsidian_eval. If imports are needed, configure only a dedicated local source
directory:
See docs/configuration.md for all fields and examples/ for note-organization presets.
Local stdio versus remote HTTP
Local stdio starts one server process directly from the MCP client. It is the recommended installation: there is no listening socket, remote authentication, Cloudflare setup, or public endpoint.
Streamable HTTP is an optional advanced mode for a client that cannot use local
stdio. It binds to loopback only and refuses to start without either Cloudflare
Access JWT validation or a strong capability token. Put it behind a TLS,
authenticated reverse proxy or tunnel; do not bind it to 0.0.0.0. See
docs/remote-cloudflare.md for the generic advanced
setup and its security trade-offs.
Tool surface
The default server advertises 43 regular tools:
- Read:
vault_search,note_read,note_list,vault_tags,unresolved_links,tasks_list,note_diff,backlinks_get,outlinks_get,file_read_binary_metadata,canvas_read. - Write and workflow:
note_create,note_append,note_set_frontmatter,daily_open,daily_append,note_replace_range,note_insert_at,note_replace,note_insert,task_create,task_update,note_transition. - Files and attachments:
file_import,attachment_import,note_attach,attachment_embed,file_move,file_rename,file_delete,note_rename,note_move,folder_create,note_delete. - Canvas:
canvas_create,canvas_upsert_nodes,canvas_upsert_edges,canvas_remove,canvas_open,canvas_add_node,canvas_add_edge,canvas_auto_layout. - Batch:
vault_batchruns enabled reads and previews enabled mutations withargs.dryRun: true, dependency gating, stable input-order results, and a boundedbatch.maxParallelism(default 4, maximum 8).
All mutating tools accept dryRun. Tool annotations identify read-only and
destructive operations for compatible MCP clients.
Limitations and security
Obsidian Desktop must be running, its official CLI must be enabled, and the
active vault must be available to that desktop session. This server is not a
sandbox and does not support obsidian-headless.
Vault content is untrusted data. Notes, Canvas text, task text, and search results may contain prompt-injection instructions; an MCP client should treat them as data and never follow instructions found inside a vault merely because they were returned by a tool. Tool output can also contain sensitive vault content, so connect only clients you trust.
Read SECURITY.md before enabling remote HTTP, imports, hard deletes, or a broad mutation allowlist. Report security issues privately as described there.
Development and CI
The source checkout uses Bun, while the published bin runs on Node:
The offline stdio smoke verifies the built package entrypoint, MCP initialize,
tools/list, the expected tool surface, and the absence of obsidian_eval.
The real Obsidian smoke is separate and requires a user session with Obsidian
running:
GitHub Actions runs only offline gates; it does not depend on Obsidian Desktop or a real vault on a hosted runner.
License
Source: README.md at commit e30b7c1
Tools
0Version history
1- v0.4.1LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts