Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
QCDOC_MEM_DATA_DIRNoDirectory where memory data is stored. Defaults to ~/.qcdoc-mem.
QCDOC_MEM_LLM_API_KEYNoAPI key for the LLM provider used for automatic extraction from conversations. Optional; can be omitted if the provider's own environment variable (e.g., OPENAI_API_KEY) is set.

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

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
memory_searchA

Search long-term memory for facts matching a natural-language query.

Use this before asking the user to repeat themselves. Searches fact content (keyword and, when a retrieval index exists, ranked matching) and returns the best matches with their category and confidence.

memory_contextA

Load the user's memory as text ready to put in your context.

Call this once near the start of a task. The returned context string is the backend's own injection format and should be treated as opaque text -- prepend it to the conversation rather than parsing it.

memory_getA

Return the complete stored memory document for a user.

Prefer memory_search or memory_context for normal use; this returns everything (summaries plus the full fact list) and is intended for inspection, export or debugging.

memory_rememberA

Store one durable fact about the user.

Use this when the user states a preference, corrects you, or shares context worth carrying into future sessions. Do NOT use it for transient details of the current task, and do not re-save something you already saved -- an identical fact is detected and returned as status="duplicate" instead of being stored twice.

memory_remember_conversationA

Hand a conversation to the backend to extract facts from automatically.

This is the hands-off write path: instead of deciding fact-by-fact what to save, send the turns and let the backend's LLM extraction decide. Requires an LLM to be configured on the server; without one this returns an error rather than silently storing nothing.

memory_update_factA

Edit an existing fact by id; omitted fields keep their value.

Use this instead of saving a new fact when something changed -- for example when the user switches tooling. Get the fact_id from memory_search first.

memory_delete_factA

Delete a single fact by id.

Use when the user says a stored fact is wrong or no longer applies.

memory_forgetA

Erase stored memory for a user (or for one agent bucket).

This is destructive and irreversible. Pending extractions for the same scope are cancelled as part of the call, so a queued update cannot resurrect the memory afterwards. Use it when the user asks to be forgotten, not to tidy up individual facts -- use memory_delete_fact for that.

memory_flushA

Force pending memory extractions to run now, within a time budget.

Useful before shutting down, or when a client wants the memory written before it reports success.

memory_statusA

Report the memory backend's configuration and health.

Use to check whether a model is configured (extraction needs one), where data is stored, and which identity the defaults resolve to.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
status_resourceServer status as an MCP resource.

TDQS

A4.3/5.0

Scored across 10 tools

Disambiguation5/5

Each tool targets a distinct operation: read whole memory, search, context injection, manual write, automatic extraction, update, delete, bulk forget, flush, and status. The only near-overlap (memory_get vs memory_context) is explicitly disambiguated in descriptions, and memory_remember vs memory_remember_conversation clearly separates manual from backend-extracted storage.

Naming Consistency4/5

All tools share the memory_ prefix and use snake_case, mostly following a memory_<verb> pattern. memory_context is a noun-style endpoint and memory_status/remember_conversation vary slightly in structure, but the overall pattern remains predictable.

Tool Count5/5

10 tools is well-scoped for a memory backend: read, search, context load, manual write, automatic extraction, update, delete, full erase, flush, and status. Each tool earns its place with no redundant bloat.

Completeness5/5

Covers the full lifecycle of persistent facts: create (remember/remember_conversation), read (get/search/context), update, delete, plus admin operations (flush/status) and destructive forget. No obvious dead ends for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues