second-brain-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MISTRAL_API_KEY | Yes | Required for indexing and search. Without it the server starts, skips indexing with one warning, and search_history returns an error naming this variable for searches with a query (a ticket-only search needs no key). The index command exits with an error unless --dry-run is set. | |
| SECOND_BRAIN_DB | No | SQLite database file. Values are used as is: ~ is not expanded, so write absolute paths. | ~/.second-brain-mcp/brain.db |
| SECOND_BRAIN_NOTES | No | Markdown notes folder. Unset means conversations only. Values are used as is: ~ is not expanded, so write absolute paths. | |
| SECOND_BRAIN_TRANSCRIPTS | No | Claude Code transcripts folder. Values are used as is: ~ is not expanded, so write absolute paths. | ~/.claude/projects |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Searches the user's past Claude Code conversations and, when configured, their Markdown notes. For past work, a ticket id, a decision or "why did we do X", call search_history before searching files by hand. It matches meaning as well as exact words.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_historyA | Search the user's whole work history: raw Claude Code conversations (one document per exchange) and, when a notes folder is configured, their Markdown notes (decisions, topics, session notes). Use it before answering about past work: a ticket ("PROJ-123"), "why did we do X", "what was decided about Y", a bug that came back. Exact terms and meaning are both matched; results are grouped by session. Then use read_exchange to read the raw conversation around a hit. |
| read_exchangeB | Read the raw conversation around an exchange found by search_history. |
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 2 tools
The two tools have clearly distinct roles: search_history finds candidate exchanges, and read_exchange expands one specific hit into its surrounding raw conversation. The descriptions explicitly state the dependency ('read the raw conversation around an exchange found by search_history'), leaving no risk of misselection.
Both names follow the same verb_noun snake_case pattern (search_history, read_exchange), and the nouns describe complementary parts of a single retrieval workflow.
Two tools is on the thin side, but for a read-only search-and-retrieve server this is the minimal complete pair rather than an accidental omission. It earns its scope tightly, with no redundant or filler tools.
The dominant workflow (find an exchange, then read its context) is fully covered across both conversation history and Markdown notes. Minor gaps exist, such as no session listing, date/authority filtering, or pagination for long histories, but agents can work around these with query refinement.