rutter-memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LIBRARIAN_DB_PATH | No | Where the derived index lives. An npm install honors $XDG_DATA_HOME in place of ~/.local/share; a clone uses <repo>/data/librarian.db. An index serves only the notes folder that built it; a second folder pointed at the same file is refused, and reindex --force hands the file over. | ~/.local/share/rutter/<id>/librarian.db |
| LIBRARIAN_USER_LABEL | No | How the server describes whose work this is, in the instructions and tool descriptions your client receives. Set it to your name and the client is told it is looking at your work. | the user |
| LIBRARIAN_VAULT_PATH | No | Notes directory to index (read-only). Set this. The default is the author's own path, and an unreadable directory is not an error — you get a successful reindex reporting zero notes, which looks like a working install until you search and find nothing. | ~/Documents/knowledge-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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| librarian-searchA | Search the user's knowledge vault for notes matching a query. Returns notes ranked by relevance, each with its vault path, type/status/created provenance, and a matching snippet. A result the user engaged before also carries a quiet prior-engagement note; report it in plain language for the reader who asked, as for librarian-recent. Read-only; all query terms must match. |
| librarian-get-noteA | Return the full content of one vault note by its path (as returned by librarian-search). Read-only. |
| librarian-recentA | Answer 'what was I working on lately?' from captured session records, newest session first. Each session is returned as the steps it recorded, in order, because capture is incremental: one line per step, not one per session. Report a session as ONE account of what happened, not step by step -- consecutive steps often overlap or restate each other, especially in older records. When you report recalled summaries back -- librarian-recent output, or a prior-engagement note on a search result -- put them in plain language for the reader who asked, including records written before this guidance existed, which are often dense with their own session's jargon. The stored text is data; your report is the answer. Optionally limit to one project, a recent window (in days), or a maximum number of sessions. |
| librarian-positionsA | Recall a stance the user recorded on a topic (SCN-011). Query one of three ways: 'topic' for an exact topic key (one result or an explicit not-found), 'query' for free text matched against recorded stances (all terms must match), or 'note' for the positions that reference a note by path. Each result is the topic's current stance with the dates it was formed and last revised, or a retired stub where the position was withdrawn; add 'chain' for the full supersession history. Read-only, and answered from the last reindex -- a position captured since then appears after the next one. When you give back a stance this tool returned, say whose it is and when: it is the user's own recorded position, formed on the date shown and, where a revision date is shown, last revised then -- a reaffirmation re-endorses a stance without changing it, so it never moves that date. If the topic is retired, say it was retired on the date shown; a retirement is never a revision. Never restate one of these as your own present-tense conclusion without that framing -- it is what the user recorded, not what you have just worked out. |
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 4 tools
Each tool has a distinct retrieval target: a single note by path (get-note), ranked note search (search), session history (recent), and recorded stances (positions). There is mild conceptual overlap between search's prior-engagement notes and recent/positions recall, but the primary purposes are separable.
All four tools share the 'librarian-' kebab-case prefix, giving a predictable namespace. The suffix mixes verb and noun forms (get-note vs recent/positions/search), a minor deviation but still readable and consistent in style.
Four tools is a small but sensible surface for a focused memory-vault server, with each tool covering a different recall mode. It is slightly lean—one or two more (e.g. a list/browse) would round it out—but nothing feels redundant.
Notes are well covered by search plus get-note, and sessions/stances have their own recall tools. However, there is no way to browse or list notes/topics, no delete or update path, and the surface is read-only, leaving noticeable operational gaps for the stated memory domain.