M3 Memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| m3_callA | Invoke ANY m3 catalog tool by name without loading its domain — the low-token path to the full tool surface, and the way to reach every tool not loaded at startup. Single call: pass |
| memory_writeA | Store a new memory and, by default, embed it for semantic search. For a new fact; to replace a specific memory whose id you know use memory_supersede, and to edit one in place memory_update. An embedded write is checked against existing memories of the same type from the same agent: if it closely matches one (cosine > 0.92 by default) but says something different, the old one is superseded automatically. type='auto' lets the LLM choose the type. |
| memory_supersedeA | Replace one specific memory, by its full id, with a new version. Use it when you know which memory a new fact replaces; memory_write's automatic contradiction check may link the wrong one or none. Non-destructive: the old memory is closed, not deleted (still retrievable by id, in memory_history and in as_of search, linked new -> old by a 'supersedes' edge); it only leaves default search. Pass content to create the successor (type, title, importance and scope you omit are inherited), or replacement_id (a full UUID) to retire old_id into an EXISTING active memory without creating one: the way to clean up duplicates. Exactly one of the two. old_id must be the full UUID; a prefix is rejected (full UUID required for mutation safety; memory_get accepts a prefix). To remove a memory use memory_delete. |
| memory_searchA | Find memories by meaning and keywords: hybrid by default; search_mode semantic (vector only) or keyword (lexical only). Returns the top k matches, ranked, with their ids; grade the ones you use with memory_grade. Narrow with type_filter, agent_filter, user_id, scope or conversation_id; as_of searches the store as it was at a past time. Use chatlog_search for captured chat turns and files_search for indexed files. |
| memory_getA | Retrieves a full MemoryItem; accepts full UUID or 8-char prefix; ambiguous prefixes return an error. |
| chatlog_searchA | Search chat_log rows. FTS5 keyword when query is non-empty; filter-only when empty. |
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 6 tools
The four memory_* tools have distinct roles (write creates, supersede replaces by id, search finds, get retrieves), and chatlog_search targets a separate domain. The main overlap is m3_call, a generic gateway that can invoke any catalog tool including the memory ones, so an agent must decide between a direct tool and the universal escape hatch.
memory_write/supersede/search/get follow a clean prefix_verb pattern, and chatlog_search keeps a second domain prefix with the same convention. m3_call is an outlier prefix but is clearly a distinct gateway rather than an inconsistency in the memory family.
Six tools is a tidy surface for a memory service and each earns its place. The caveat is that m3_call is a proxy for a much larger catalog, so the visible count understates the real surface an agent must navigate.
Write, supersede, search, get and chatlog search cover the core loop, but the descriptions reference memory_update, memory_delete and memory_grade which are not loaded as tools, forcing agents through m3_call for routine update/delete/feedback. That is a notable gap for a CRUD lifecycle.