Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
OPEN_MEMEX_HOMENoOverride the storage root (default is %APPDATA%\open-memex on Windows, ~/.local/share/open-memex on macOS/Linux; the pre-rename MY_O_MEMORY_HOME name is still honored as a fallback).
OPEN_MEMEX_CONFIGNoOverride the config file path (default is ~/.config/opencode/open-memex.jsonc; the pre-rename MY_O_MEMORY_CONFIG name is still honored as a fallback).

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
}

Tools

Functions exposed to the LLM to take actions

NameDescription
memory_addA

Save a fact, preference, decision, or note to persistent local memory. Call this PROACTIVELY whenever the user shares something worth remembering across sessions — project conventions, tool choices, personal preferences, decisions made, error fixes and their causes. Worth saving: decisions and their reasons, preferences, conventions, gotchas, approaches tried and abandoned. Not worth saving: one-off task details or anything re-derivable from the code. Do not wait to be asked. For facts you infer yourself rather than the user stating, propose them first and save only on approval. Keep each memory to one self-contained statement; attach aliases when the parameter is available. If a note tells you the user's own wording was already stored verbatim this turn, that statement is already saved: do not retry it in a rewording — save only what that text does not contain, or use memory_supersede on the given id. Default scope is the current project; use the personal scope for facts about the user that apply across all projects.

memory_searchA

Search persistent memory by keyword (BM25 full-text). Returns matching memories from the current project and/or personal scope. Call before asking the user about past decisions, conventions, or preferences they may have told you before. Search well: break the question into its concepts and try 2–3 phrasings per concept — synonyms, the user's other language, shorter keyword forms — and check the other scope too, before concluding nothing is stored.

memory_listA

List memories in a scope, newest first, as a numbered inventory. Each line keeps the raw fields — [type] id=… created=… source=… — say them back to the user in plain words (source=user → 'you told me this'; inference → 'I inferred this, check me'; keyword → 'caught from your own wording'), never read the raw id aloud unless they ask. When the user asks 'what do you remember about me?', use scope=both and present the inventory conversationally. The user may point at an entry by its number ('delete #3'): numbers are only valid for the listing you just produced — re-run memory_list, read the candidate back in full, and get a confirmation before calling memory_forget (deletion is permanent). include=all is the audit view (superseded versions, retracted, archived also shown).

memory_supersedeA

Replace an existing memory with a newer version. The old memory is kept as history (status: superseded) and retrieval returns the new one. Use when a saved fact becomes outdated and should be replaced rather than duplicated.

memory_forgetA

Delete a memory by id. Use when the user asks to forget something. Deletion is permanent: before deleting, restate the memory's content to the user and get a confirmation. With soft=true the memory is hidden instead (retracted: out of lists and search, file kept, one-way).

memory_statusA

Show the project memory sync pipeline: drafts waiting in the outbox (appdata), memories in the repo awaiting review or published, and any repo files not yet committed. Call this at session start, when the server reports drafts waiting for review, or when the user says 'sync memory' (or '同步记忆'); then ask the user which drafts to sync. (MCP server and the open-memex sync-status CLI; the opencode native plugin does not expose this tool.)

memory_submitA

Move outbox drafts into the repo memory dir for review: copies the drafts in as proposed (or keeps a local approval), commits locally on the current branch, and moves the outbox originals out. Never creates a branch on its own — pass branch= only with the user's explicit approval for the full chain. Prints the push and PR commands — those need the user's explicit approval and are never run automatically. (MCP server and the open-memex submit CLI; the opencode native plugin does not expose this tool.)

memory_proposeA

Copy personal memories into the project outbox as review drafts. The personal originals stay put. (MCP server and the open-memex propose CLI; the opencode native plugin does not expose this tool.)

memory_promoteA

Advance a project memory one step up the review ladder (proposed → approved → published), or reject it with a note. Rejected memories are never deleted — they can be revised and resubmitted. (MCP server and the open-memex promote CLI; the opencode native plugin does not expose this tool.)

memory_resolveA

List git-conflicted memory files, or attempt a field-level 3-way merge of one. Semantic conflicts are reported, never auto-resolved. (MCP server and the open-memex resolve CLI; the opencode native plugin does not expose this tool.)

memory_pr_statusA

Read the current branch's GitHub PR and map its review state onto each in-repo memory: merged PR → published, PR approval → approved (approved_by = reviewer), changes-requested → suggestion only. Report by default; apply=true performs the mapped transitions locally (no push). (MCP server and the open-memex pr-status CLI; the opencode native plugin does not expose this tool.)

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 11 tools

Disambiguation4/5

Core operations (add, search, list, supersede, forget) are clearly distinct. The workflow-stage tools (promote, submit, propose) and the two status tools (status, pr_status) have adjacent purposes, but descriptions differentiate them well enough that misselection is unlikely.

Naming Consistency5/5

Every tool uses a consistent memory_ prefix with snake_case verb or verb_noun naming (memory_add, memory_search, memory_pr_status, memory_supersede). The pattern is predictable and uniform throughout.

Tool Count5/5

11 tools is well within a comfortable range and each maps to a distinct action in a memory lifecycle (CRUD, search, review promotion, git sync). No tool feels redundant or filler.

Completeness4/5

The surface covers the full memory lifecycle: create, search, list, supersede, forget, review-ladder promotion, git conflict resolution, and outbox-to-repo sync. Minor gaps exist (e.g., no explicit memory_update/edit or bulk operations) but core workflows are complete.

Maintenance

ActivityMaintained
ResponsivenessResponsive