| name | mnemos-memory |
| description | Read and write persistent memory via MNEMOS. Use when you need to recall prior decisions, infrastructure facts, project context, or established patterns across sessions, and when you have learned something new worth persisting (solved problem, validated pattern, architectural decision, team standard). Covers full-text and semantic search, create/update/delete memories, category-scoped queries, and knowledge-graph triples. |
MNEMOS Memory
MNEMOS is persistent memory shared across agent sessions. It is a network service, not a prompt. Reads and writes happen through the mnemos MCP server.
When to search MNEMOS
Before you commit to an approach on any of these, run a quick search_memories:
- Infrastructure — ports, hostnames, service locations, credential storage layout
- Decisions — architecture choices, tradeoffs the team has already settled
- Solutions — workarounds for known bugs, fixes already applied elsewhere
- Patterns — reusable approaches already validated
- Projects — current project state, owners, milestones
- Standards — conventions, quality gates, review criteria
If the user's task looks like something that might have been solved before, search first. One query is cheap; wasted work is not.
Search patterns
- Start broad with full-text:
search_memories(query="topic keywords", limit=10) before narrowing
- Filter by category when you know the domain:
search_memories(query="auth flow", category="decisions")
- Use semantic search for concept-level matches:
search_memories(query="...", semantic=true)
- Large context loads: use
POST /v1/memories/rehydrate directly via the REST API (this path is not an MCP tool in the current mnemos.mcp.stdio bridge). Chain multiple search_memories calls with a running token tally if you need to stay within MCP.
When to store
Store after:
- Solving a non-trivial problem (store the solution and the failure mode, not just the fix)
- Making an architectural decision with rationale (use
category=decisions; include why and tradeoffs)
- Discovering infrastructure shape (endpoint, port, auth scheme) that future sessions will need
- Establishing a pattern that other agents should follow (
category=patterns or standards)
Do not store:
- Session transcripts (the session ingest endpoint handles that separately)
- Temporary state that will be stale in a day
- Information the user will see in the diff (recent commits, current branch)
Minimum write shape
create_memory(
content="<concise prose — one paragraph, lead with the claim>",
category="<decisions|solutions|patterns|infrastructure|projects|standards>",
subcategory="<optional narrower tag>",
metadata={"source_agent": "<this skill's invocation context>"}
)
Content rules:
- Lead with the claim or fact, then supporting detail
- Keep under 500 words; if longer, split
- Include a why when you can — the memory is useless if a future reader can't judge whether it's still applicable
Knowledge graph
For relational facts (X owns Y, A depends on B, deadline of X is Y), use kg_create_triple instead of a free-text memory. Triples support temporal validity windows — mark valid_until when a fact goes stale rather than deleting.
Avoid poisoning
Before acting on a returned memory, check that it is still current:
- If it names a file path, verify the file exists
- If it names a port or hostname, verify reachability before trusting the endpoint
- If the user's current situation contradicts the memory, trust current reality and update the memory — don't act on stale data
Tools (via MCP)
| Tool | Purpose |
|---|
search_memories | Full-text or semantic search, category/subcategory filters |
list_memories | List memories with optional category / limit filters |
get_memory | Fetch a single memory by ID |
create_memory | Store a new memory |
bulk_create_memories | Create many memories in one call (bulk ingest) |
update_memory | Edit content or metadata |
delete_memory | Remove a memory |
kg_create_triple / update_triple / delete_triple | Knowledge-graph write ops |
kg_search / kg_timeline | Knowledge-graph read ops (list triples, subject timeline) |
get_stats | Category counts, compression statistics |
Rehydration (token-budgeted context load) is a REST-only endpoint (POST /v1/memories/rehydrate); not exposed as an MCP tool in the current mnemos.mcp.stdio bridge.
