mysharedbrain
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VAULT_DIR | No | Directory for the markdown vault (default: ./vault) | ./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": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_noteA | Create a new markdown note. Folders are created from the id path. |
| read_noteB | Read a note by id. |
| update_noteB | Replace a note's content by id. |
| delete_noteA | Soft-delete a note to trash (restorable with restore_note). |
| restore_noteA | Restore a trashed note back into the vault. |
| move_noteC | Move/rename a note. |
| list_notesA | List note ids, sorted, with optional folder prefix and pagination. |
| read_notesA | Read several notes at once; missing ids are reported, not fatal. |
| append_noteA | Append content to the end of a note. Prefer over full rewrites. |
| patch_noteB | Replace (or append to) the section under a heading. Surgical edits. |
| list_directoryA | Direct children of a folder: subfolders and note ids. |
| get_frontmatterD | A note's YAML frontmatter (tags, etc.). |
| set_frontmatterB | Merge keys into frontmatter (null value deletes a key). |
| search_by_tagD | Notes carrying a frontmatter tag. |
| note_historyB | Every logged interaction with one note (reads, finds, edits …). kind filters to one category: read | find | write | move | delete | capture | job | other. Returned with per-kind counts for that file. |
| get_backlinksB | Notes linking to this one via [[links]]. |
| get_outgoingC | [[Link]] targets a note points to. |
| recent_changesA | Latest audited vault and capture changes, newest first (paged). Returned with per-kind counts for the whole log, the same shape the per-note history reports for one file. |
| search_notesB | Search notes by name and content (ripgrep). |
| give_feedbackA | Teach the brain: queue feedback the librarian applies later. This is the self-learning loop — the single most important tool here. Either hand over the information itself (a correction, a fact, content for a missing note) or say where to get it (a source to check, what is missing). The entry lands in the capture queue as pending and the librarian reviews it (applied/approved/rejected) before the vault changes. "kind is one of: edit | missing | request | question. |
| ask_questionA | Ask the librarian. Answered from the vault when possible, otherwise filed as an automated question for future retrieval. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| ask_librarian | Ask the librarian; misses are queued for future retrieval. |
| file_feedback | Teach the brain: queue feedback the librarian applies later. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| vault_index | All note ids in the vault, sorted. |
TDQS
Scored across 21 tools
Most tools are clearly distinct (create/read/update/delete/move/list/append/patch), but read_note vs read_notes and list_notes vs list_directory could cause minor confusion. The descriptions help clarify the differences, so overall the set is well-disambiguated.
The majority follow a consistent verb_noun pattern (create_note, read_note, update_note, delete_note, restore_note, move_note, list_notes, search_notes). Minor deviations like get_frontmatter vs set_frontmatter and note_history vs recent_changes are still readable and mostly consistent.
21 tools is on the higher end but appropriate for a note/knowledge management server covering CRUD, frontmatter, links, search, history, and feedback. Each tool serves a distinct purpose, though a few could potentially be consolidated.
The tool surface is comprehensive: full note lifecycle (create/read/update/delete/restore/move), batch reads, surgical edits, frontmatter management, search, backlinks/outgoing links, history, recent changes, and a feedback loop. There are no obvious dead ends for the stated purpose of a shared brain/note vault.