mnemolith
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AETHER_PORT | No | The port the Aether Cache engine listens on. Set this if port 7380 is taken, then run `aether-cache setup` again. | 7380 |
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 |
|---|---|
| rememberA | Save a durable fact about this project so future sessions, in any AI tool, know it. Use this, not a built-in memory or notes file, whenever the user asks you to remember something about the project. |
| recallA | Search this project's shared memory by meaning. Call it at the start of every task, and whenever project-specific knowledge (setup, conventions, past decisions) might matter. Only current (active) memories are returned; outdated or replaced ones are skipped. |
| explain_memoryA | Show where a memory came from (which tool and session saved it, which files it's linked to) and everything that has happened to it since. Use it when a memory looks wrong or surprising. |
| mark_outdatedA | Mark a memory as no longer true, with a short reason. It stops showing up in recall but keeps its history, so you can still see what it said and why it was retired. |
| replace_memoryA | Retire an older memory because a newer one replaces it (e.g. "we use Postgres" replaced by "we migrated to MySQL"). The old memory stops showing up in recall but keeps its history. |
| check_staleA | Check whether any memory's linked files have changed since it was saved, and retire those memories. recall already does this automatically; call it directly after big changes. |
| confirm_memoryA | Mark a memory as still true (e.g. after it was retired because a linked file changed, but the fact itself didn't). Re-links it to the current version of its files. |
| sync_to_filesA | Write this project's current memories into the managed section of AGENTS.md / CLAUDE.md, so they're committed with the code: teammates and tools without Mnemolith see them, and changes show up in reviews. Call it when the user asks, or after a batch of new memories. |
| list_conflictsA | List pairs of memories in this project that may contradict each other and need a decision. |
| resolve_conflictA | Settle a possible conflict. replaces_old=True: the new memory replaces the old one (the old one is retired). replaces_old=False: both are true, keep both. Ask the user if you're not sure. |
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 10 tools
Most tools have clearly distinct purposes: recall vs remember, sync_to_files, explain_memory, and list_conflicts are unambiguous. However, several lifecycle tools (confirm_memory, mark_outdated, replace_memory, resolve_conflict) all change a memory's status, and replace_memory vs resolve_conflict(replaces_old=True) overlap conceptually, though descriptions differentiate their triggers.
All names are snake_case and verb-first, following a predictable verb_noun pattern (sync_to_files, check_stale, confirm_memory, explain_memory, list_conflicts, mark_outdated, replace_memory, resolve_conflict). The two single-verb names (recall, remember) are standard, readable, and consistent with the overall imperative style.
10 tools is well-scoped for a project-memory server, covering save, search, lifecycle state changes, conflict handling, provenance, staleness, and file sync without redundancy. Each tool earns its place and there are no obvious filler operations.
The surface covers the core memory lifecycle: create (remember), search (recall), update/retire (confirm, mark_outdated, replace_memory), conflict handling (list/resolve), provenance (explain_memory), staleness (check_stale), and export (sync_to_files). Minor gaps exist: no direct list/get-all-memories or content-edit operation, but recall and replacement largely work around these.