amem
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | No | Named workspace to bind for MCP, passed as ?workspace=<name> in the HTTP MCP URL or via --workspace when using stdio. | |
| AMEM_PASSPHRASE | No | Passphrase to unlock the local amem database when it has been locked with `amem lock`. |
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 | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| amem_contextA | Retrieve compact local amem memory for a query. Use before exploring files or calling a remote LLM with a large prompt. Pass workspace for named app memory, not only git repos. |
| amem_recipeA | Return the generic amem remember contract: when to call amem_context vs amem_remember. Use if you are unsure whether to read or write memory. Same recipe for every MCP host. |
| amem_rememberA | Store a durable local fact in amem (stays on this machine). Use kind |
| amem_supersedeA | Retire outdated claims so they stop appearing in context: marks them superseded (kept for history, not served). Pass |
| amem_reposA | List what amem is monitoring. Each item has kind git or workspace. Workspaces also have a stable slug (MCP id); the display name can differ. Use when asked which projects, workspaces, or repos amem knows about. |
| amem_statsA | Usage and savings stats (local lookup time, estimated tokens/ms saved, hit rate) for one workspace/repo or everything. Use when asked how much amem helped, how often it hit, or usage over time. |
| amem_graphA | Dump stored facts for a workspace or git repo: claims, components, flows, and recent activity. Use when asked what amem remembers about a project. Prefer amem_context for a ranked packet for the current question. |
| amem_statusA | Binding, policy, and counts for one workspace/repo, plus the full monitored inventory. Omit workspace for a machine-wide overview. |
| amem_skill_listA | List stored skills (procedures the agent learned) as an index of names and descriptions only. Cheap — call this first, then amem_skill_view to load the one you need. Skills are longer procedures; use amem_context for small durable facts. |
| amem_skill_viewA | Load the full body of one skill by name, or a supporting file inside it. Call this only after amem_skill_list (or the 'Relevant skills' section of an amem context packet) shows a skill worth following. |
| amem_skill_saveA | Save a non-trivial multi-step procedure you just worked out as a reusable skill. Use after solving something worth repeating — a workflow, a dead end you found the way past, or a correction the user gave you. Provide a full SKILL.md in |
| amem_task_listA | List deferred agent tasks (Kanban) for a workspace/repo. Use for work to do later — not durable facts (use amem_remember for those). Default excludes done tasks. |
| amem_task_addA | Create a deferred agent task on the project Kanban (default backlog). Use for work that should not get lost in chat. Durable facts still go through amem_remember. |
| amem_task_updateB | Update a task title, notes, anchors, or move its Kanban status (backlog/next/doing/blocked/done). |
| amem_task_completeC | Mark a deferred agent task as done on the Kanban board. |
| amem_usage_reportA | Report what you actually did with the last amem context packet, so its savings estimate becomes a measurement instead of a guess. Call this once after you have finished acting on a packet. Do NOT estimate tokens — just list which of the anchors amem gave you you ended up opening anyway (anchors_opened), and whether the packet answered the question without further exploration (answered). amem computes the saving from the real size of the files you did not have to open. Reporting that you opened everything is a useful and expected answer. |
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 16 tools
Most tools target distinct actions or resources: memory retrieval, remembering, superseding, skills, tasks, and usage reporting are clearly separated. A few boundaries are softer, especially amem_context vs amem_graph vs amem_status and amem_stats vs amem_usage_report, but the descriptions largely clarify intended use.
All tools share the amem_ prefix and snake_case, which helps. However, naming conventions are mixed: some use resource_action (amem_skill_view, amem_task_add), some are bare verbs (amem_remember, amem_supersede), and others are nouns or noun phrases (amem_context, amem_repos, amem_usage_report).
At 16 tools, the set is slightly heavy but still within a reasonable range for a memory server with skills, tasks, inventory, and usage reporting. Each tool appears to have a real role, though some consolidation could make the surface lighter.
Core lifecycle operations are present: memory read/write/retire, skill list/view/save, task list/add/update/complete, and usage/stats reporting. Minor gaps exist around explicit deletion or unmonitoring, and skills/tasks lack full delete/update coverage, but most workflows are supported.