Skip to main content
Glama
cks850711

Obsidian CLI MCP Server

by cks850711

obsidian-cli-mcp-server

A local MCP server that wraps the official Obsidian CLI (v1.12+), giving LLM agents full access to 80+ vault operations through a single tool.

  • Zero network dependencies — no API keys, no cloud services; everything runs locally

  • Single-tool design — one obsidian_exec tool accepts any CLI command, so new Obsidian CLI features work instantly without updating the server

  • Safety-first — dangerous commands (eval, devtools, etc.) are blocked at two layers; all execution uses spawn without shell interpretation, preventing command injection

  • Dual execution mode — direct spawn for terminal environments + HTTP relay for Electron-hosted clients (Claude Desktop, Cowork)

Prerequisites

  • Obsidian v1.12.4+ with CLI enabled (Settings → General → Command line interface)

  • The obsidian binary in your PATH (or set OBSIDIAN_CLI_PATH)

  • Node.js ≥ 18

  • expect (pre-installed on macOS; needed for search / search:context)

Related MCP server: Obsidian MCP Server

Quick Start

# Clone and build
git clone https://github.com/cks850711/obsidian-cli-mcp-server.git
cd obsidian-cli-mcp-server
npm install
npm run build

Configuration

Claude Code

Add to your Claude Code MCP settings:

{
  "mcpServers": {
    "obsidian-cli": {
      "command": "node",
      "args": ["/absolute/path/to/obsidian-cli-mcp-server/dist/index.js"]
    }
  }
}

Claude Desktop

{
  "mcpServers": {
    "obsidian-cli": {
      "command": "node",
      "args": ["/absolute/path/to/obsidian-cli-mcp-server/dist/index.js"]
    }
  }
}

Note: Claude Desktop is an Electron app, and spawning the Obsidian CLI (also Electron) from it causes a SingletonSocket IPC conflict. You must start the HTTP relay server from a terminal first — see HTTP Relay below.

Available Tools

obsidian_exec

Execute any Obsidian CLI sub-command and return its output.

Parameter

Type

Required

Description

command

string

CLI sub-command and arguments (without the leading obsidian)

vault

string

Target a specific vault by name

Examples:

command="help"
command="read file=MyNote"
command="search query=\"meeting notes\" limit=10"
command="create name=NewNote content=\"Hello world\""
command="files folder=Projects ext=md"
command="tasks todo"
command="tags counts sort=count"
command="properties file=MyNote"
command="backlinks file=MyNote"
command="bookmarks"

For the full list of available CLI commands, run command="help".

obsidian_blocked_commands

Returns the list of CLI commands that are blocked by this server for safety reasons. Takes no parameters.

HTTP Relay

When the MCP server runs inside an Electron process tree (e.g., Claude Desktop), the Obsidian CLI binary hangs due to Electron's SingletonSocket IPC mechanism. The relay server solves this by running in a separate terminal.

# Start the relay (keep this terminal open)
npm run relay
# Default: http://127.0.0.1:27182

The MCP server automatically tries the relay first, then falls back to direct spawn. No configuration needed — just start the relay before using the MCP server from Electron-based clients.

Environment variable

Default

Description

OBSIDIAN_RELAY_PORT

27182

Relay server port

OBSIDIAN_CLI_PATH

obsidian

Path to the Obsidian CLI binary

Auto-Start on Demand (macOS)

Keeping a terminal window open just to host the relay is inconvenient — especially for sandboxed clients (VMs, containers) that can reach the relay over HTTP but cannot start a process on the host.

The included launchd agent solves this: touching a trigger file starts the relay. Any client that can write to the repository directory can bring the relay up without a human opening a terminal.

Install

bash scripts/install-relay-agent.sh

That is the whole setup — no paths to fill in, no config to edit. The script derives the repository location from its own position on disk, generates the .plist accordingly, and loads it with launchctl. Re-running it is safe (it reloads in place).

The generated agent lives at ~/Library/LaunchAgents/com.obsidian-cli-mcp-server.relay.plist and is not stored in the repository, so no absolute paths are ever committed.

To remove it:

bash scripts/install-relay-agent.sh --uninstall

What it does

Touching the trigger file causes launchd to run scripts/start-relay.sh, which:

  1. Exits immediately if the relay is already listening (repeated triggers are harmless)

  2. Refuses to start if the port is occupied by something else, rather than fighting over it

  3. Locates the obsidian binary — env var → PATH → common install paths → Spotlight — since it lives inside the app bundle and is not on launchd's default PATH

  4. Launches Obsidian if it is not already running (the CLI needs a live instance to talk to)

  5. Starts the relay in the foreground, letting launchd own the process

The relay runs with no controlling terminal and no window; its output goes to logs/relay.log.

Client                       Host (macOS)
──────                       ────────────
relay not responding
      │
      ▼
touch .relay-trigger ──────► launchd notices mtime change
                                    │
                                    ▼
                             start-relay.sh
                               ├─ ensure Obsidian is running
                               └─ start relay on :27182
      │                             │
      ▼                             ▼
retry after ~5s ───────────► relay ──► Obsidian ──► vault

Triggering it

touch /path/to/obsidian-cli-mcp-server/.relay-trigger

Then wait ~5 seconds and retry. Notes:

  • Use touch. Creating or deleting the file is unnecessary, and some sandboxes permit touch while blocking unlink.

  • launchd throttles a job to once per 10 seconds — spamming the trigger does nothing.

  • The agent is deliberately configured without RunAtLoad and KeepAlive, so the relay starts only when triggered. Add both keys to the generated plist if you would rather have it start at login and restart automatically on crash.

Tell your agent about it

Installing the agent is only half of it. Unless the LLM client knows the trigger exists, it will still report "the relay is down" and wait for a human — which is exactly the problem this was meant to remove.

Put the recovery procedure somewhere the client loads on every session, not in a doc it has to go looking for: the failure needs to be self-healing at the moment it happens. For Claude Code that means CLAUDE.md; other clients have their own equivalent (system prompt, rules file, agent instructions).

Something like:

### If the Obsidian relay is not responding

Do not ask me to start it. Recover it yourself:

1. `touch <repo>/.relay-trigger`
2. Wait 5–10 seconds, then retry the command.

A launchd agent on the host watches that file and starts the relay
automatically. Use `touch` — do not create or delete the file. launchd
throttles to once per 10 seconds, so space out retries. Only report back
if two attempts fail, and include the command and error output.

Replace <repo> with the absolute path to this repository as seen from the client — for sandboxed clients that is the path inside the sandbox, not on the host.

Troubleshooting

tail -20 logs/relay.log                                  # what happened
launchctl list | grep obsidian-cli-mcp-server            # is the agent loaded

Symptom

Cause

spawn obsidian ENOENT

Obsidian not installed, or in a non-standard location — set OBSIDIAN_CLI_PATH

Relay starts but commands fail

Obsidian's CLI is disabled — enable it in Settings → General → Command line interface

Nothing happens on touch

Agent not loaded; re-run the install script

Security

Blocked Commands

The following commands are blocked by default to prevent unintended side effects:

Command

Reason

eval

Arbitrary JavaScript execution inside Obsidian

restart

Restarts the Obsidian app

devtools

Toggles Electron DevTools

dev:cdp

Chrome DevTools Protocol — arbitrary method execution

dev:css

CSS inspection

dev:debug

Debugger attach/detach

dev:dom

DOM query

dev:mobile

Mobile emulation toggle

The blocklist is enforced at two layers — both the MCP server (cli.ts) and the relay server (relay-server.ts) independently reject blocked commands. To customize, edit src/constants.ts.

Command Injection Prevention

All commands are executed via Node.js child_process.spawn without a shell (shell: false by default). User input is parsed into an argv array by a custom parser (parse-args.ts) — not by sh -c. This means:

  • Shell metacharacters (;, |, $(), ` `, &&) are not interpreted

  • The executable is always the fixed obsidian binary — it cannot be changed by user input

  • No command substitution, variable expansion, or piping is possible

For search / search:context (which require a TTY), commands are wrapped with expect. Arguments are quoted using Tcl brace-quoting ({...}), which is fully literal with no substitution.

Architecture

LLM (Claude)
  │
  │  MCP (stdio)
  ▼
┌──────────────────────┐
│  MCP Server          │
│  (index.ts)          │
│                      │
│  obsidian_exec tool  │
│  ┌────────────────┐  │
│  │ isBlocked()    │──│── Layer 1: block dangerous commands
│  │ parseArgs()    │──│── Parse without shell
│  └───────┬────────┘  │
└──────────┼───────────┘
           │
     ┌─────┴──────┐
     ▼             ▼
┌─────────┐  ┌───────────┐
│  Relay  │  │  Direct   │
│  Server │  │  Spawn    │
│ (HTTP)  │  │           │
│ :27182  │  │           │
└────┬────┘  └─────┬─────┘
     │             │
     ▼             ▼
   ┌─────────────────┐
   │  obsidian CLI   │
   │  (Electron)     │
   └─────────────────┘

Development

npm run dev       # Watch mode (tsx)
npm run build     # Compile TypeScript
npm test          # Run parse-args unit tests
npm run relay     # Start HTTP relay server

License

MIT

Available Tools

2 tools
obsidian_blocked_commandsA

Returns the list of Obsidian CLI commands that are blocked by this MCP server for safety reasons.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It indicates a read-only operation returning a list, but lacks details on potential caching, update frequency, or format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundancy, front-loaded with key purpose. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and a simple return type (list), description is adequate. Could be improved by hinting at output format, but otherwise complete for this complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. Description does not need to add param info; baseline for zero-param tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'returns' and the resource 'list of Obsidian CLI commands that are blocked', distinguishing it from the sibling 'obsidian_exec' which executes commands.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives such as obsidian_exec. Usage is implied as a safety check before executing commands, but not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

obsidian_execA

Execute any official Obsidian CLI command and return its output.

This tool wraps the obsidian CLI binary installed on the host machine. Pass the sub-command and arguments as a single string (without the leading obsidian binary name).

Blocked commands (configurable): eval, restart, devtools, dev:cdp, dev:css, dev:debug, dev:dom, dev:mobile

Common examples: command="search query="meeting notes" limit=10" command="read file=MyNote" command="tasks todo" command="tags counts sort=count" command="create name=NewNote content="Hello world"" command="properties file=MyNote" command="backlinks file=MyNote" command="files folder=Projects ext=md" command="bookmarks" command="help search"

For a full list of commands, use: command="help"

Args:

  • command (string, required): The CLI sub-command and arguments

  • vault (string, optional): Target vault name

Returns: The raw stdout from the CLI. If the command fails, stderr and exit code are included.

ParametersJSON Schema
NameRequiredDescriptionDefault
vaultNoTarget a specific vault by name. Omit to use the active vault.
commandYesThe Obsidian CLI command to execute, e.g. "search query=hello limit=5" or "read file=MyNote". Do NOT include the leading `obsidian` binary name — just the sub-command and its arguments.

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description covers returned stdout/stderr/exit code and blocked commands. Lacks details on side effects or security implications, but acceptable for a CLI wrapper.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections, front-loaded purpose, examples, args, and returns. No superfluous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-param tool with no output schema, description covers all necessary aspects: usage, blocked commands, return format, and examples.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. Description adds value by explaining command format (excluding leading 'obsidian') and giving concrete examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it executes Obsidian CLI commands and returns output. Distinguishes from sibling tool by focusing on execution, while the sibling manages blocked commands.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides extensive examples and mentions blocked commands and how to get full list via 'help'. Does not explicitly state when not to use it, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.1.1
    • First observedobsidian_blocked_commands
    • First observedobsidian_exec

TDQS

A4.2/5.0
Disambiguation5/5

Only two tools with clearly distinct purposes: one executes CLI commands, the other lists blocked commands. There is no ambiguity between them.

Naming Consistency5/5

Both tools follow the 'obsidian_' prefix pattern and use descriptive names ('exec' and 'blocked_commands'), maintaining consistent naming conventions.

Tool Count3/5

With only two tools, the server feels minimal. While a single generic execution tool can cover many operations, having only one functional tool may be insufficient for complex agent workflows, though it is acceptable for a thin CLI wrapper.

Completeness4/5

The main tool can execute any allowed Obsidian CLI command, providing broad coverage. However, it lacks structured tools for common operations (e.g., read, search, create), requiring agents to parse string outputs, which introduces minor gaps.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables AI assistants to read, write, search, and navigate Obsidian vault notes with support for CRUD operations, full-text search, graph navigation, daily notes, and frontmatter management.
    4,785
    -
  • A
    license
    A
    quality
    D
    maintenance
    Enables AI assistants to interact with Obsidian vaults for creating, reading, searching, and managing notes, daily notes, TODOs, session reports, and backlinks through both stdio and HTTP/SSE transports.
    10
    4,785
    4
    MIT
  • F
    license
    C
    quality
    F
    maintenance
    Provides LLM agents with comprehensive access to Obsidian vaults via the official Obsidian CLI bridge. It enables users to read, search, and modify notes, tasks, properties, and plugins while the Obsidian desktop app is running.
    54
    15
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cks850711/obsidian-cli-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server