ctxkeeper
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CTXKEEPER_DIR | No | Project memory directory. Default: <root>/.ctxkeeper. | |
| CTXKEEPER_ROOT | No | Force the project root (absolute path). Default: auto-detected. | |
| CTXKEEPER_GLOBAL_DIR | No | Global memory directory. Default: ~/.ctxkeeper/global. | |
| CTXKEEPER_MAX_FILE_KB | No | Max size of a file read into context. Default: 300. | |
| CTXKEEPER_DISABLE_CODE_SEARCH | No | Set to 1 to expose memory tools only. Default: unset. |
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
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| project_briefA | Start here. Returns a token-budgeted brief for this project: detected stack, run/test commands, files to read first, git state, open TODOs, decisions, gotchas, and recent work logs. Replaces exploratory file reads at session start. |
| rememberA | Persist a decision, gotcha, fact, command, todo, or note to the local project store (or global store). Use this whenever the user states a preference, you make a non-obvious choice, or you discover something future sessions should know. Identical entries are deduplicated. |
| recallA | Search saved memories with keyword/CJK-aware ranking (title, tags, files, content; importance and recency weighted). Filter by type, tag, or scope. Use before asking the user to repeat context. |
| forgetA | Archive a memory by ID so it stops appearing in briefs and recall. Archive is reversible: pass restore=true with the same ID. Use when a decision is superseded or a note is wrong. |
| todoB | Manage the durable project todo list. action=add needs title; action=list shows open items (set include_done=true for all); action=done/reopen needs id. Todos survive sessions and appear in project_brief. |
| log_workA | Append a short, timestamped work-log entry (what changed, which files, commands, outcome, next steps). Call this before ending a session so the next agent can resume without re-reading everything. |
| context_packA | Given a concrete question, return a token-budgeted pack of the most relevant code excerpts (with path:line citations) plus matching project memories. Use this BEFORE broad greps or reading whole files; it cuts token use and round trips. |
| statusA | Show the detected project root, store paths, memory/todo/worklog counts, git state, and limits. Use when setting up the server or debugging why nothing is recalled. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| onboard | Ask the agent to load the project brief and summarize the current state. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| project_brief | A token-budgeted onboarding brief for the current project (stack, commands, TODOs, decisions, gotchas, recent work). |
TDQS
Scored across 8 tools
Most tools have distinct roles: remember/recall/forget form a clear memory lifecycle, todo manages a separate list, and log_work and status are unambiguous. project_brief and context_pack both return token-budgeted context, but their scopes (session-start overview vs question-specific excerpts) are described well enough to distinguish them.
The set mixes simple verbs (remember, recall, forget), noun-like names (todo, status), and compound names (project_brief, log_work, context_pack). No single predictable convention is followed, though all names are readable and mostly snake_case.
Eight tools is well-scoped for a project-context memory server, with each tool covering a distinct operation. There is no obvious bloat or missing essential capability at this count.
The surface covers memory creation, search, archival with restore, todos, work logs, briefs, status, and context packing, providing solid lifecycle coverage. Minor gaps exist, such as no direct memory-edit operation or bulk cleanup beyond archiving by ID.