obsidian-secondbrain-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OBSIDIAN_VAULT | Yes | The path to the Obsidian vault that the MCP server will operate on. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vault_infoA | Describe the vault: root path, folder taxonomy, note counts, method. Call this first in a session so you know the structure you are writing into. The taxonomy is data (.secondbrain/config.json), not code. |
| init_vaultA | Create the folder taxonomy and config file in an empty or new vault. Idempotent: existing folders and notes are left untouched. |
| list_notesB | List note paths, optionally restricted to one folder. |
| read_noteB | Read one note: frontmatter, body, tags and outgoing links. |
| create_noteC | Create a note. Refuses to clobber an existing note unless overwrite=true. |
| append_to_noteA | Append to a note, creating it if absent. The append-only primitive: prefer this over rewriting raw capture notes. |
| patch_sectionA | Insert text at the end of the section under |
| update_frontmatterB | Merge keys into a note's YAML frontmatter. |
| move_noteC | Move or rename a note inside the vault. |
| archive_noteA | Move a note into the archive folder. Nothing is ever deleted. |
| find_notesA | Find notes by NAME or path. Use this when you know roughly what a note is called. Use |
| search_notesA | Literal or regex search across note CONTENT, with surrounding lines. Plain text matching, no embeddings. Read the excerpts, judge relevance
yourself, then |
| search_by_tagB | Find notes carrying a tag (frontmatter |
| search_frontmatterA | Find notes by a frontmatter key, optionally matching an exact value. |
| backlinksC | Notes that link to this one via [[wikilink]]. |
| related_notesA | Graph neighbours of a note, scored: direct links either way, shared outbound links, shared tags. Each result says why it matched. Structural only — no semantics. Judge the candidates yourself. |
| recent_notesC | Notes modified in the last N days, newest first. |
| capture_sessionA | Persist the current session into the vault -- the YOU write the summary; this tool only files it. Before calling, compact the session yourself into: what was being done and why, decisions taken with their reasons, what is still open, which files/artifacts were touched. Write durable facts, not a transcript -- a reader six months from now should not need the conversation. Creates a note in the sessions folder marked undistilled, and drops a pointer into today's log. |
| log_entryA | Append a timestamped entry to the day's append-only log. For in-flight capture: a fact, a link, a half-formed idea. Never rewrite the log -- it is the raw stream distillation feeds on. |
| read_daily_logB | Read one day's log (ISO date, default today). |
| distill_queueA | Raw captures not yet distilled, oldest first, with their content. This is the core loop and it is YOUR job, not the server's: read each item,
pull out the ideas that will still matter later, write each one as a single
atomic note via |
| create_concept_noteA | Write one atomic note: one idea, stated as a claim.
|
| mark_distilledA | Mark a raw capture as distilled, recording which notes came out of it. |
| vault_healthA | Where the graph is fraying: undistilled backlog, orphan notes, unresolved [[links]], most-connected hubs, per-folder counts. Use it to pick the next maintenance job -- an unresolved link is usually a note worth writing; an orphan is usually a note worth linking. |
| build_mapB | Write a Map-of-Content index note over notes you have curated. |
| resurface_notesC | Random notes pulled up for re-reading -- the anti-write-only-vault move. Re-read them, then either link them somewhere new, sharpen the claim, or archive them if they no longer hold. |
| stale_notesC | Notes untouched for N+ days, oldest first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| compact_to_vault | Compact this session and file it in the vault. |
| distill | Run one distillation pass over the raw capture backlog. |
| review_brain | Audit the vault and propose the next maintenance moves. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 27 tools
Every tool targets a distinct operation: listing paths vs. searching by name/content/tag/frontmatter, editing via distinct primitives (create/append/patch/frontmatter), and graph-specific tools (related, backlinks, stale, recent). The search tools are clearly separated by what they search (name vs. content vs. tag vs. frontmatter), minimizing confusion. Even the distillation workflow tools (capture_session, log_entry, distill_queue, mark_distilled) each have non-overlapping responsibilities.
Most tools follow verb_noun snake_case (create_note, move_note, search_notes, build_map). A few are noun-first (vault_info, vault_health, backlinks) and one adjective_noun (distill_queue). The convention is predominantly consistent, and any deviations are clear from context. The minor inconsistency keeps it from a perfect score.
At 27 tools, this exceeds the typical 15-tool threshold, but the server manages a full Personal Knowledge Management system: CRUD, multiple search modes, graph analytics, session capture, distillation workflow, health checks, and map building. Each tool addresses a distinct need, so the count feels justified rather than bloated. It is on the heavy side but appropriate for the scope.
The tool surface is remarkably complete for a second-brain vault: full note lifecycle (create, read, append, patch, move, archive without deletion), comprehensive search (name, content, tag, frontmatter), graph operations (backlinks, related, stale, recent), a distillation pipeline (capture, log, distill, mark_distilled), and maintenance utilities (health, map, resurface). The only missing operation is permanent deletion, which is a deliberate design choice. This is a fully realized workflow.