29/32proof of conceptModel Context Protocol
Vault MCP Server
Four tools that let any MCP client read, search and write the Obsidian vault.
What it solves
Notes kept in one app are out of reach for an AI assistant. Four tools let any MCP client search, read and write the vault.
How it runs
Five steps, input to output
Goes inA tool call from any MCP client
- 01
Connect
An MCP client reaches the server’s single endpoint over the tunnel.
- 02
Authenticate
Every request must carry the bearer token.
- 03
Search
search_vault finds the notes that match a query.
- 04
Read and list
get_note returns one note in full by its path. list_assets lists notes by type or folder.
- 05
Save
save_note writes a new note into a vault folder.
Comes outSearch results, a note in full, a list of notes, or a newly saved note
What it does
Four tools that let any MCP client read, search and write the Obsidian vault over a tunnel.
Three decisions
What shaped the build
One stateless endpoint
The server speaks Streamable HTTP on a single endpoint. Its requests are plain POSTs, which pass through the tunnel without being buffered.
The token rides on every request
All calls hit the same endpoint, so each one is checked for the bearer token.
A saved note reaches disk first
A new note is written to the vault regardless. If indexing fails, a later index build picks it up.
Built with
8 parts
- MCP SDK
- server implementation
- Streamable HTTP
- transport
- search_vault
- semantic search tool
- get_note
- read tool
- save_note
- write tool
- list_assets
- attachment listing
- Express
- HTTP endpoint
- Cloudflare Tunnel
- public endpoint