Skip to main content
Glama
alex106

obsidian-secondbrain-mcp

by alex106

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
OBSIDIAN_VAULTYesThe 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 heading, adding the section at the end of the note if it is missing.

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. */? globs work; a bare word matches any name containing it.

Use this when you know roughly what a note is called. Use search_notes when you need to look inside the content.

search_notesA

Literal or regex search across note CONTENT, with surrounding lines.

Plain text matching, no embeddings. Read the excerpts, judge relevance yourself, then read_note the ones that matter.

search_by_tagB

Find notes carrying a tag (frontmatter tags or inline #tag). Nested tags match: ml also matches ml/rl.

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 /compact step.

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_note (linking to existing notes with [[Title]]), then call mark_distilled on the source listing what you produced. Skip anything ephemeral -- mark it distilled with an empty produced list.

create_concept_noteA

Write one atomic note: one idea, stated as a claim.

title should read as an assertion you could disagree with, not a topic label. claim is the idea in one or two sentences. links are titles of existing notes -- call find_notes or search_notes first so you link into the graph instead of creating an island.

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

NameDescription
compact_to_vaultCompact this session and file it in the vault.
distillRun one distillation pass over the raw capture backlog.
review_brainAudit the vault and propose the next maintenance moves.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 27 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues