Three tools is a small surface, and read-only. What earns the setup is everything around the connection: parallel URL probing, fastest-wins selection, a 30-second health check and exponential backoff, plus a published container image. If Obsidian runs on Windows and your agent runs in WSL2 or Docker, that is the part that usually breaks, and this is the piece it was written for.
An MCP server that talks to the Obsidian Local REST API plugin running in the desktop app, so an agent can search your vault and pull a note's content and metadata. Its distinguishing feature is connection handling: give it several candidate URLs and it tests them in parallel, keeps the fastest, re-checks health every 30 seconds, and fails over on its own — which is what makes it survive a WSL2 gateway IP change or a Docker network restart.
- A note's content and metadata fetched by vault path — `get_note_content`
- Notes found by a query string, and the same query run as a semantic search — `obsidian_search`, `obsidian_semantic_search`
- Any note addressable as a resource under `obsidian://{path}`, so a client can reference it without a tool call
- A `/health` endpoint when HTTP transport is on, reporting transport state and whether auth is enabled
Obsidian on the desktop with the Local REST API plugin enabled, and the key it shows you in `API_KEY`. `API_URLS` takes a JSON array or semicolon-separated list of vault URLs — that is the recommended form; `API_HOST` and `API_PORT` still work as the older single-URL config but give you no failover and no health monitoring. Run it as `@oleksandrkucherenko/mcp-obsidian` 1.0.3 over stdio, or as the container `ghcr.io/oleksandrkucherenko/obsidian-mcp:latest`. Over HTTP it binds `MCP_HTTP_PORT` (default 3000) at `MCP_HTTP_PATH` (default `/mcp`), and it only requires an `Authorization: Bearer` header when you set `MCP_HTTP_TOKEN` — set it before the port leaves your machine.
One command plus a key — claude mcp add obsidian -- bunx -y @oleksandrkucherenko/mcp-obsidian, then supply credentials