Placing content relative to a heading or a block reference is what makes it usable on a real vault: a summary lands under the section it belongs to and the note keeps its structure.
A bridge to a running Obsidian instance through the Local REST API community plugin. Seven tools read the vault as it exists right now and write back into it.
- The vault listed from the root, or a single directory listed on its own (`list_files_in_vault`, `list_files_in_dir`)
- The contents of one note read back (`get_file_contents`)
- A text query searched across every file in the vault (`search`)
- Content inserted relative to a heading, a block reference or a frontmatter field — placed, not appended (`patch_content`)
- Content appended to an existing note, or to a new one created for it (`append_content`)
- A file or directory deleted from the vault (`delete_file`)
`uvx mcp-obsidian` on Python 3.11 or newer, plus the Obsidian Local REST API community plugin installed and enabled — that plugin is where `OBSIDIAN_API_KEY` comes from. `OBSIDIAN_HOST` and `OBSIDIAN_PORT` default to 127.0.0.1 and 27124, so you only set them if you moved the plugin. Obsidian has to be running for any of it to answer. One dependency pin to respect: the tool handlers use the `mcp` 1.x low-level server API, so installing it against `mcp` 2.0 or newer crashes at import with `AttributeError: 'Server' object has no attribute 'list_tools'`.
One command plus a key — uvx mcp-obsidian, then supply credentials
