secondbrain-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SB_RAG_DB | No | Path to the index database. Defaults to <vault>/.secondbrain/index.db | |
| SB_VAULT_ROOT | No | Path to the markdown vault directory. If not set, serves the demo vault. | |
| SB_AGENT_LABEL | No | Label for audit attribution, useful when multiple clients share the vault. |
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 |
|---|---|
| read_noteA | Read a standard note by vault-relative path; returns the full-content hash. Private notes are never readable. |
| list_notesA | List note paths (private notes excluded), newest first; optional folder prefix and substring pattern. |
| search_notesA | Keyword search over indexed notes; falls back to a linear vault scan when the index is empty. |
| rag_searchB | Retrieval with per-note scores and traceability fields. Excerpts are candidates: call read_note before citing. |
| rag_reindexC | Incrementally re-index the vault into a rebuildable derived index. |
| rag_statusA | Index health metadata (document/chunk counts, schema version) without exposing note contents. |
| create_inbox_noteA | Create a note in an inbox directory (Web/Conversations/Files). Never overwrites an existing file. |
| append_noteB | Append to a note under a per-file lock with optimistic-concurrency check on expected_hash. |
| update_metadataA | Update an allowlisted set of frontmatter fields (status/tags/agent_generated/...); other keys are dropped. |
| move_noteA | Move a note within the vault (never into a private area); destination must not exist. |
| archive_notesA | Archive notes by (note, hash, category) entries into the review area with a batch rollback manifest. Run dry_run first. |
| list_archivesB | List archive batches with their restore accounting. |
| restore_archiveB | Restore an archived batch back to its original paths; skips already-restored, missing, altered or occupied entries. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools are clearly separated by action and resource, and the archive/restore group is unambiguous. However, search_notes and rag_search both offer retrieval over notes, and list_notes' substring filter partially overlaps with search_notes, so an agent could occasionally pick the wrong one.
Tool names follow a consistent snake_case verb_noun pattern: read_note, list_notes, move_note, append_note, update_metadata, archive_notes, restore_archive. The rag_* tools use a domain prefix but still read predictably, so the naming convention is coherent throughout.
Thirteen tools is a well-scoped count for a note-management server covering capture, retrieval, organization, metadata, and archiving. Each tool has a clear role and none feel redundant or extraneous.
The core note lifecycle is well covered: create via inbox, read, list, search, move, append, metadata update, archive, and restore. The main gaps are the lack of a direct content-replacement operation and a permanent delete/purge, though append and archive/restore mitigate most practical needs.