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 |
|---|---|
| tools_list_domainsA | List m3 tool domains (memory, chatlog, files, entity, agent, tasks, conversations, diagnostics, admin) and their tool counts. Call |
| tools_load_domainC | Register a tool domain's full surface for the current MCP session. Use when you need tools beyond the essentials (memory_search, memory_write, memory_get, chatlog_search, chatlog_write, files_search). Valid domains: memory, chatlog, files, entity, agent, tasks, conversations, diagnostics, admin. |
| m3_help_capabilitiesB | Discover m3-memory tool capabilities, parameters, and availability. Allows filtering by a logical domain (memory, chatlog, files, entity, agent, tasks, conversations, admin, diagnostics) or searching by keywords. |
| m3_indexA | List m3 catalog tools (optionally one domain) as structured rows: name, domain, one-line summary, destructive flag, and arg specs (name/type/required). Use this to discover the exact args for any tool before calling it via m3_call — cheaper than a failed call. Read-only catalog metadata; never returns tool output. Domains: memory, chatlog, files, entity, agent, tasks, conversations, diagnostics, admin. |
| m3_callA | Invoke ANY m3 catalog tool by name without loading its domain — the low-token path to the full tool surface. Single call: pass |
| memory_writeA | Creates a MemoryItem and optionally embeds it for semantic search. Contradiction detection is automatic — if new content conflicts with an existing memory of the same type/title, the old one is superseded. Use type='auto' to let the LLM decide the best category. |
| memory_supersedeA | Explicitly supersede an existing memory with a new one. Use this to record an intentional update — 'this fact replaces that specific memory' — when you know the old memory's id. Unlike memory_write's automatic contradiction detection (a cosine + title heuristic that may link the wrong prior memory or none at all), this targets the given old_id deterministically. Non-destructive: the old memory is retained, its validity interval is closed (is_deleted=1, valid_to set), and a 'supersedes' edge is recorded new -> old. The old memory stays retrievable by id and via memory_history, and as_of-filtered search still sees it valid before the supersession point — it is only dropped from default search. Fields you omit (type, title, importance, scope) are inherited from the old memory, so pass only what changed. To hard-delete instead, that is a separate gated tool (memory_delete). old_id MUST be the full UUID — a prefix is rejected (full UUID required for mutation safety; memory_get accepts a prefix, this does not). Note: each supersede creates a NEW successor memory; call it once with the full id, do not chain supersedes. |
| memory_searchC | Search across memory items using semantic similarity or keyword matching. Filter by user_id and scope for isolation. |
| memory_getA | Retrieves a full MemoryItem; accepts full UUID or 8-char prefix; ambiguous prefixes return an error. |
| chatlog_writeB | Append one chat turn to the chat log DB. Provenance (host_agent, provider, model_id, conversation_id) is required. Writes are async-queued — returns the row id immediately. |
| chatlog_searchB | Search chat_log rows. FTS5 keyword when query is non-empty; filter-only when empty. |
| chatlog_statusB | One-call health summary of the chat log subsystem: mode, DB paths, row counts, queue depth, spill files, embed backlog, hook timestamps, redaction state, warnings. |
| agent_listB | List registered agents, optionally filtered by status and/or role. |
| task_listC | List tasks with optional filters. Newest updated first. |
| files_searchA | Hybrid FTS5 + vector search over file-ingestion leaves. Default: current versions only. Set include_history=True for time-travel queries. Use |
| files_indexA | Return file-level summaries for triage (wiki-index primitive). Cheap-first retrieval -- no leaf content. Use BEFORE files_search to decide which files are worth deep-reading. |
| files_getA | Fetch one record by UUID. Tries file_nodes then leaves. |
| files_statsC | Corpus-level counters: file_nodes, leaves, embed coverage, by-filetype. |
| files_healthC | DB integrity + FTS5 sync check. Set rebuild=True to fix drift. |
| files_corpus_listC | Enumerate corpora with row counts. |
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 20 tools
Several meta-tools (tools_list_domains, m3_help_capabilities, m3_index, tools_load_domain, and m3_call) all occupy the discovery/loading/calling space, making their boundaries unclear at a glance. While the core memory/chatlog/files tools are mostly distinct, an agent could easily pick the wrong meta-tool for a given task.
The vast majority of tools follow a consistent `{domain}_{action}` snake_case pattern, e.g. memory_get, chatlog_write, files_search, task_list. The m3_* and tools_* meta-tools deviate slightly but still use lowercase underscore naming and are readable.
At 20 tools, the set sits in the 16-25 range that feels heavy, especially with five meta-tools that could be consolidated. However, the multi-domain scope (memory, chatlog, files, agents, tasks, admin, etc.) provides some justification for the count.
Core memory workflows are well covered with get, search, write, and supersede, and chatlog/files have solid read/search/status surfaces. Minor gaps remain, such as no direct memory_delete or explicit entity/conversation/admin tools, though the m3_index/m3_call meta-layer can reach those catalog tools if needed.