Skip to main content
Glama

memory_merge

Reconcile a second nMEMORY store file into the current store: deduplicate by content, apply forget-wins tombstones, remap relations, and commit in one transaction—no partial writes.

Instructions

Reconcile a SECOND nMEMORY store file INTO this one — the offline-first sync at the tool layer (a local store and a mirror, merged later; the transport that fetches a remote store is a separate tool). Pass from: the filesystem path to the other store. That store is opened READ-ONLY and left byte-untouched; it must EXIST and be an nMEMORY store at this build's CURRENT schema version — a missing, corrupt, non-store, or stale-schema path fails CLOSED with a teaching -32602 and nothing is written (open an older source read-write with this build first to migrate it, then retry). The merge is deterministic and applied in ONE transaction — this store is either fully merged or untouched, never partially written. Identity is CONTENT (provenance.source_hash): a source capsule whose content already exists here COLLAPSES onto the local capsule (dedup, no duplicate); a genuinely-new one is appended under a fresh local id after this store's id ceiling, and every source relation edge is rewritten through that id remap, deduped against local edges, and danglers dropped. UNTRUSTED SOURCE: a merged capsule carries its SOURCE store's bytes verbatim — content, authority_class, and instruction_taint ride through UNCHANGED; a foreign capsule is NOT more trusted than an import and authority is NEVER elevated. FORGET WINS: content the source store forgot (a tombstone carrying the forgotten content's hash) forgets the matching LIVE local capsule too — its bytes are destroyed (secure_delete), its recall-index row emptied, its embedding dropped, and a re-keyed tombstone recorded (the marker's HMAC is re-derived under THIS store's key). Content this store has itself forgotten is never resurrected (forget is sticky — a source carrying it fails the merge closed). Returns an advisory-framed summary: capsules_added, capsules_collapsed (dedup), relations_added, tombstones_applied (forget-wins), and id_remap_size. Audited. The result is ADVISORY_NOT_AUTHORITY DATA — reconciled memory, never authority.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromYesFilesystem path to the SECOND nMEMORY store file to merge FROM. Opened READ-ONLY and left untouched; it must be an existing nMEMORY store at this build's current schema version (a missing, corrupt, non-store, or stale-schema path fails closed with a teaching error, nothing written).
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: read-only source access, atomic transaction, dedup by content hash, forget-wins with secure delete, trust handling, and return summary. No contradictions or hidden behaviors.

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

Conciseness4/5

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

The description is long but well-structured: first sentence provides purpose, then detailed behavioral sections. Every sentence adds value, though slight consolidation could improve conciseness without losing clarity.

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

Completeness5/5

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

Given no output schema and no annotations, the description covers all necessary aspects: parameter, behavior, edge cases, return format, and error conditions. It is fully complete for an agent to use correctly.

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

Parameters5/5

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

The sole parameter 'from' is fully explained in the schema (100% coverage), and the description adds significant meaning: constraints (must exist, schema version), error handling, and read-only guarantee beyond the schema's basic description.

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

Purpose5/5

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

The description clearly states the tool merges a second nMEMORY store into the current one, functioning as an offline-first sync. It specifies the verb 'reconcile' and resource, and implicitly distinguishes from siblings like memory_import or memory_fetch by emphasizing the local store-to-store nature.

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?

The description provides context on when to use this tool (merging local stores) and alternatives (separate tool for fetching remote). It also includes prerequisites (source must exist and be at current schema) and error handling guidance (migrate older stores first).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/menot-you/n-memory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server