SecondBrain
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SECONDBRAIN_CONFIG | No | Path to the secondbrain.yaml configuration file. If not set, the server uses the default config at ~/.config/secondbrain/secondbrain.yaml. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| memory_searchB | Search the user's shared SecondBrain with hybrid keyword and local semantic retrieval before substantive tasks. |
| memory_getB | Read a SecondBrain note or retrieve a historical catalog entry such as H0372. |
| memory_relatedA | Traverse one or two ontology hops around a canonical SecondBrain note, optionally filtered by relation type. |
| memory_captureA | Append durable user, decision, project, knowledge, or inbox memory. Ordinary personal information is allowed; credentials are rejected. |
| memory_updateC | Safely append a dated section to an existing Markdown note in SecondBrain. |
| memory_candidate_createC | Create an idempotent review candidate without changing canonical Markdown. |
| memory_candidate_listC | List the isolated candidate review queue; candidates never appear in memory_search. |
| memory_candidate_getC | Get one memory candidate by ID. |
| memory_candidate_approveA | Preview approval by default; apply only to an existing Markdown target with an explicit matching SHA-256. |
| memory_candidate_rejectC | Reject a candidate without changing canonical Markdown. |
| memory_candidate_expireC | Expire a candidate without changing canonical Markdown. |
| memory_recentC | Return recent per-tool session memory logs. |
| memory_statusA | Check SecondBrain index and automatic harvester status. |
| memory_rebuildB | Rebuild the local keyword and semantic index after substantial note changes. |
| memory_auditB | Audit canonical memory for stale active notes, duplicate aliases, identity conflicts, unresolved ontology links, open questions, and source provenance. |
| memory_evalB | Run the SecondBrain retrieval regression suite and report recall@k and mean reciprocal rank. |
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 16 tools
Each tool targets a distinct action/resource: search vs. get vs. recent logs, and a clean memory_candidate_* sub-namespace (get/list/create/approve/reject/expire) that is explicitly isolated from canonical memory. The three write paths (capture, update, candidate_create) are clearly differentiated by descriptions. No two tools appear interchangeable.
All 16 tools use a uniform memory_ prefix in snake_case with a predictable verb_noun structure (memory_get, memory_search, memory_capture, memory_update). The memory_candidate_* lifecycle is a consistent nested naming sub-pattern rather than a deviation.
16 tools is at the upper edge of comfortable, driven by a full five-tool candidate-review lifecycle. For a knowledge base with retrieval, audit, eval, and index management, each tool earns its place, though the surface is slightly heavy.
The surface covers the full lifecycle: creation (capture/create), read (get/search/related/recent), update (update, approve), review governance (candidate list/approve/reject/expire), plus audit, eval, rebuild, and status. Append-only design intentionally omits canonical delete, so no meaningful dead ends remain.