halflife-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HALFLIFE_HOME | No | Data directory. Defaults to a per-OS path: Linux ~/.local/share/halflife (or $XDG_DATA_HOME/halflife), macOS ~/Library/Application Support/halflife, Windows %APPDATA%\halflife. | |
| HALFLIFE_EMBED | No | Whether vector search is enabled (on if the vector extra is installed). Set to off to disable vector search. | on |
| HALFLIFE_EMBED_MODEL | No | Another fastembed model to use for embeddings. Recall thresholds are tuned for the default. | BAAI/bge-small-en-v1.5 |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| memory_briefA | What to know before starting work: the top preferences (up to 8) and procedures (6), the strongest facts (5) and the most recent episodes (3) for this scope (plus global). Bodies are clipped; use memory_get for a full memory. |
| memory_recallA | Search memory with hybrid keyword + vector + graph ranking. |
| memory_rememberA | Store one memory. kind: preference | procedural | fact | episodic | trace. content: the memory itself, short (for preference/procedural include why and how to apply). description: one keyword-rich line (used for matching; defaults to the first line). provisional: true when inferred rather than stated by the user. contradicts: id of a memory this one replaces. entities: [{"name", "type"}] for the specific files/tools/projects/people/concepts it is about (type: file, repo, tool, library, service, person, concept, ticket, command, project, organization). relations: [{"src", "rel", "dst"}] between those entities (rel: uses, depends_on, part_of, configures, fixed, caused, contradicts, supersedes, related_to, owns, prefers). source: where it came from (URL, file path). A near-duplicate reinforces the existing memory instead of creating a new one. |
| memory_reinforceA | A memory was confirmed or proved useful: raises its confidence, resets its decay and activates it if provisional. |
| memory_forgetA | Permanently delete a memory (file, graph, archived copy, index). Only when the user asks to forget something. |
| memory_getB | One memory in full, with its metadata and graph. |
| memory_listA | List memories of a scope (plus global), newest first. status: active | provisional. Use when the user asks what you remember. |
| memory_statsB | Counts per scope, kind and status; where the data lives; whether vector search is on. |
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 8 tools
The verbs are largely distinct: remember/get/forget/reinforce/stats are unambiguous. However, memory_recall, memory_list, and memory_brief all surface memories and could be confused—recall is query-driven search, list is scoped enumeration, and brief is a curated pre-work digest. The descriptions do clarify the boundary, so it's a minor overlap rather than a real ambiguity.
Every tool uses the same memory_ prefix followed by a short, readable suffix (recall, reinforce, forget, get, list, stats, brief, remember). The pattern is uniform throughout with no casing or convention drift.
Eight tools is well-scoped for a memory subsystem, with each tool earning its place (store, search, get, list, stats, reinforce, forget, brief). Nothing feels padded or missing.
The lifecycle is fully covered: create (remember), read (get/list/recall/brief), reinforce, and delete (forget), plus stats. Updates are handled via the contradicts/supersedes fields and reinforcement, so there is no dead end for the memory domain.