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. |
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 3 tools
The three tools split cleanly by intent: search finds notes by query, get-note fetches one note's full body by path, and recent answers a temporal 'what was I doing' question from session records. The only mild overlap is that search and get-note both surface note content, but the descriptions explicitly chain them (get-note takes a path 'as returned by librarian-search').
All three share a 'librarian-' namespace prefix with kebab-case suffixes, which reads as a deliberate, predictable family. The minor deviation is that 'recent' is an adjective rather than an action verb like 'get' or 'search', so the verb_noun pattern isn't fully uniform.
Three tools is on the thin side for a knowledge-vault server, covering only retrieval. Each tool earns its place and nothing is redundant, but the surface is narrow enough that agents will frequently hit the edge of it.
The read path is coherent (search -> get-note, plus recent for recall), but there is no write/capture, update, delete, or note-listing operation anywhere in the set. If this server is meant to be the user's memory, the inability to record anything new is a notable gap; if it is deliberately read-only, the gap is smaller but still limits lifecycle coverage.