The difference shows in create_or_update_note and get_daily_note: both remove a decision the assistant would otherwise get wrong — does this note exist, and what is today's note actually called. find_related_notes is the one that pays off on a mature vault, because it uses the links you already made rather than keyword luck.
An MCP server that talks to a locally running Obsidian REST API. Alongside plain file operations it exposes vault-level ideas: daily notes, recently modified notes, frontmatter keys, and notes related by tags or links.
- list_directory with pagination, so exploring a large vault does not flood the context
- read_file, write_file with overwrite, append or prepend modes, and delete_item for files and directories
- create_or_update_note — an upsert with content and frontmatter, so the assistant never has to ask whether the note exists
- get_daily_note for a given date, handling the usual daily-note naming and folder conventions
- get_recent_notes, ordered by modification time
- search_vault across content, filenames and metadata, with path filtering
- find_related_notes — notes connected by shared tags, links or backlinks
- get_metadata_keys and get_metadata_values, to see what frontmatter the vault actually uses
- get_note and list_notes, kept for compatibility with earlier setups
Obsidian with the Local REST API running and reachable at an address you configure. A bearer token is optional and only needed if that API asks for one. Runs on Node or Bun.
One command — npx obsidian-local-rest-api-mcp