Skip to main content
Glama
billy12151

memory-arbiter-mcp

by billy12151
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

memory

Store, search, read, and update shared AI coding context with conflict arbitration, enabling tools like Codex, Cursor, and Claude Code to reuse structured notes across sessions.

Instructions

Daily memory operations: remember, find, batch_find, read, update, judge, status, help.

workspace is required on remember — discover buckets once with memory_review(view="workspaces") (e.g., at session start) and reuse that list; re-query only when unsure or before deliberately creating a new bucket ('default' is the global pool).

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: 1..8 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; hit_window=N (default 0) extends each hit with +/-N neighbouring complete sentences, neighbours marked matched=false; hit_spans appears only on query-recall pages — browse/filter pages carry none; hits whose evidence row lags the memory's current version are dropped with a stale_hit_spans marker plus a re-query warning), "full" returns whole texts. Space-separated short CJK words (each <=4 chars, e.g. "向量 唯一键 冲突") are understood as keywords: semantically close memories whose content/subject contains a keyword rank higher (0.17.0; whole-word matching, generic words ignored). Offsets are 0-based Unicode code-point offsets into the content as indexed for the item's version; the evidence index may lag right after an edit (see vector_lag). 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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
actionNohelp

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.16.5
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "memoryDictOutput",
-  "type": "object"
-}New value: +null
  2. Addedv0.11.0

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: update is atomic all-or-nothing with one version bump, batch_find caps at 8 queries and dedups by memory_id, find returns an index page rather than full content, stale hit spans are dropped with a marker, and the evidence index may lag after an edit. It omits permissions/auth requirements and error semantics, and never states whether any action deletes data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the action list, but the find paragraph is one enormous nested parenthetical run-on that is hard to scan, and version tokens ('v0.15.10', '0.17.0') add noise without helping invocation. Most sentences do carry real information, so it is overloaded rather than padded, but the structure is weak for its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter dispatcher with no annotations and no output schema, the description is thorough about find, update, and batch_find but silent on the behavior of remember, read, judge, and status, which is a real gap given the tool's breadth. Pointing to memory(action="help") for field/judge/enum discovery partially covers the omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% with a free-form 'data' object and an undocumented 'action' string, so the description must compensate, and it largely does: it names the action values, the patches/new_content/old_text shapes, content_mode enum and default, hit_window default, tags_filter, and view="workspaces". It also delegates residual discovery to memory(action="help"), which is a legitimate mitigation for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line gives the resource (memory) and enumerates eight actions (remember, find, batch_find, read, update, judge, status, help), and 'Daily memory operations' loosely distinguishes it from the maintenance-flavored siblings memory_review/govern/repair. However, four of the actions (remember, read, judge, status) are never explained, so an agent cannot tell what half the tool actually does. It is a partial statement of purpose rather than a precise one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent to a sibling for a specific need ('discover buckets once with memory_review(view="workspaces") ... re-query only when unsure'), gives alternative parameter strategies ('patches' for 1..8 local edits vs 'new_content' for rewrites), and warns against deep paging ('reword the query or add tags_filter instead'). No explicit when-not-to-use-this-tool guidance exists, but the operational context is unusually concrete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools