Skip to main content
Glama

memory_consolidate

Run a dry-run consolidation analysis: detect exact duplicates, near-duplicate merges, protective tier demotions, and alias suggestions from recall misses. Optionally execute the tier moves.

Instructions

Run the deterministic consolidation planner over the live store and return the full plan: exact_dupes (same-source_hash rows — a store-invariant breach report; keep = lowest seq), merge_proposals (near-duplicate clusters by significant-token containment; tainted never clusters with untainted), tier_moves (protective demotions only: quarantine on live taint evidence for externally-imported records, archive for superseded records that expired or aged >180d with zero recalls; NEVER a promotion to active), and alias_proposals (u-r5 miss-ledger: deterministic vocabulary hints mined from the recall-miss ledger — each recorded miss term is paired with every existing indexed-vocabulary word sharing a >=4-char folded prefix (prefix-on-fold ONLY: no fuzzy, no edit-distance, no scoring, no embedder), {term, candidate, miss_count} ordered miss_count desc then term asc then candidate asc, capped at the top 20; a term that already carries a taught alias is skipped, and a term with no candidate still surfaces as {term, candidate:null, miss_count}. The loop: memory_retrieve records a miss -> this proposes -> you teach memory_alias -> the SAME query grounds). Default is a pure DRY-RUN: nothing is written. apply_tiers:true executes ONLY the tier_moves (set_tier per move, each audited); merge proposals, dupe repairs, AND alias_proposals are NEVER executed or auto-taught by this tool — teaching an alias stays a caller act through memory_alias; the caller is always the deciding actor. Applied tiers are observable on every read surface: memory_get carries tier, memory_list rows mark (and filter by) non-active tiers, memory_export renders tier markers, and memory_retrieve counts archived/quarantined exclusions under their OWN reasons (tier fences dominate the superseded fence). Everything returned is ADVISORY_NOT_AUTHORITY.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
apply_tiersNo`true` → EXECUTE the plan's tier_moves (set_tier per move, audited). Merges and exact-dupe repairs are NEVER executed — they stay proposals for the caller regardless of this flag. Omitted or `false` → pure dry-run: report only, nothing written.
Behavior5/5

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

With no annotations, the description fully discloses behaviors: dry-run default, advisory nature, never auto-teaches, tier moves only applied if explicitly requested, and observable effects on read surfaces. No contradictions; transparency is high.

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?

The description is very verbose and dense, containing multiple long sentences without breaks or lists. While detailed, it could be more concise and structured for easier parsing by an AI agent. It earns its place but at the cost of conciseness.

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 the complexity of the tool (four plan types, taint/expiry rules, interactions with memory_retrieve and memory_alias), the description covers all necessary information, including edge cases like skipping alias teaching for terms with existing taught aliases. It is complete despite lacking an output schema.

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?

Schema coverage is 100% with one parameter (apply_tiers). The description adds value by explaining that even when true, merges and dupe repairs remain proposals, which is beyond the schema's boolean description. Rich context beyond schema.

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 it runs a deterministic consolidation planner over the live store and returns a full plan with four components (exact_dupes, merge_proposals, tier_moves, alias_proposals). It distinguishes from siblings by clarifying that alias proposals are for calling memory_alias, making the purpose very specific.

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

Usage Guidelines5/5

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

Explicitly states default is dry-run, apply_tiers executes only tier_moves, and merges/dupe repairs are never executed. Provides when-not-to-use (e.g., never auto-teaches aliases) and references memory_alias as the appropriate tool for teaching. Offers clear context on when to use this tool versus alternatives.

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