memory-arbiter-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MEMORY_ARBITER_CLIENT | Yes | Client identifier for the tool (e.g., zcode, codex, cursor, claude-code) | |
| MEMORY_ARBITER_DB_PATH | Yes | Path to the shared SQLite database file | |
| MEMORY_ARBITER_AGENT_ID | Yes | Agent identifier for the client (e.g., zcode-default) |
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 |
|---|---|
| memoryA | Daily memory operations: remember, find, batch_find, read, update, judge, status, help. Call memory(action="help") to discover accepted fields, judge requirements, value enums, update modes, and action_required paths before relying on a result that requests attention. update edits in place: <=3 local edits use patches=[{old_text,new_text}] (atomic all-or-nothing, one version bump); full rewrites use new_content; a single small edit may use old_text/new_text. batch_find runs up to 8 queries in one call and returns one merged index page (dedup by memory_id, matched_query_ids per item). find is an index page: results carry metadata + content_chars + a bounded outline (offsets usable directly as read span starts), not full content — content_mode (v0.15.10, preview default) is a single-choice enum: "hits" adds hit_spans (vector-matched unit text + span coordinates, never truncated; >=50% coverage upgrades an item to full text), "full" returns whole texts. Score compares only within the page; if the top page misses, reword the query or add tags_filter instead of deep paging. The size block meters the returned page (tokens_estimate + display_hint). |
| memory_reviewA | Read-only inspection: overview, doctor, conflicts, conflict_detail, history, expired, audit, entities, help. Use memory_review(view="help") for accepted fields. Inspect conflict_detail before judging a conflict so its members, value groups, revision, and apply state are visible. |
| memory_governB | Authorized governance: retire, merge near-duplicates, apply/replan/resolve conflicts, confirm, and manage workspaces. Every state-changing action requires explicit user authorization for that action, then authorized=true. Call memory_govern(action="help") for exact actions, accepted fields, impact notes, and confirmation semantics. |
| memory_repairB | Maintenance: evidence rebuild, conflict scans (scheduled-task spec under help topic scheduled_tasks), full-library duplicate sweeps (scan_duplicates), history cleanup, entity assignment, pending activation, backup replay, notices, and semantic runtime control. Use memory_repair(task="help") for notice handling and semantic_control actions. Semantic notices are advisory; read both memories before dismiss or resolve, and never pass a notice directly to judge or resolve_conflict. |
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 4 tools
The four tools are mostly distinct: review is read-only, govern is state-changing, repair is maintenance, and memory is daily operations. Some overlap exists between govern and repair (both can handle conflicts/duplicates), but the descriptions clarify the intended separation.
All tool names use a consistent memory_ prefix with a single verb (review, govern, repair, memory). The pattern is predictable, though the fourth tool 'memory' breaks the verb_noun convention by repeating the server name instead of using an action verb.
Four tools is a reasonable, focused count for a memory management server. Each tool is broad with many sub-actions, so the count feels slightly thin but appropriate given the consolidated command surface.
The tool set covers the core memory lifecycle: create/read/update/find, review, conflict resolution, and maintenance. Minor gaps exist (no explicit delete/destroy action visible, and some sub-actions are hidden behind help), but the surface appears functionally complete for its domain.