Skip to main content
Glama

manage_memory_store

Destructive

Manage persistent agent memory stores by compressing text into semantic triples, consolidating, exporting, listing, resetting, or deleting them. Use to store and purge episodic knowledge locally.

Instructions

Manages the complete lifecycle of persistent agent semantic memory stores, including compression, consolidation, export, listing, reset, and deletion, distinguishing from 'query_memory_store' and 'prune_code_snippet' by storing, compressing, and purging episodic memories rather than querying relations or pruning source code.

Parameters:

  • operation (str, optional, default='list'): Memory lifecycle operation: 'list' to show active memory stores, 'compress' to encode text into semantic triples, 'decompress' to decode memory code, 'consolidate' to merge memory, 'export' to dump graph, 'reset' to clear all memory, 'delete' to remove a specific store.

  • content (str, optional, default=''): Text document or knowledge content to compress or store when operation is 'compress'.

  • store_name (str, optional, default='default'): Identifier of the target memory store to manage.

  • project_root (str, optional, default='.'): Workspace root where memory stores are managed (default: current directory).

Behavior:

  • State-Modifying / Destructive: Consolidates or updates local memory state; 'reset' and 'delete' operations remove stored memory data from disk.

  • Non-idempotent for state modifications; idempotent for 'list' and 'export'.

  • 100% Offline: Fully local storage management without external synchronization.

  • Auth & Rate Limits: Zero authentication or credentials required; completes in <50ms.

  • Error Handling: Validates operation parameter and returns clear error for unrecognized modes.

Usage Guidelines:

  • When to use: Store new semantic knowledge, consolidate episodic memories, export knowledge graphs to JSON/HTML, list active memory stores, or clear/reset agent memories.

  • When NOT to use: Do not use for querying existing knowledge triples or causal chains from memory (use 'query_memory_store' instead); do not use for pruning source code snippets or diff streams (use 'prune_code_snippet' instead).

Returns: Status report confirming memory consolidation, export file path, list of active memory stores, or confirmation of reset/deletion.

Input Schema

NameRequiredDescriptionDefault
contentNoText document or knowledge content to compress or store when operation is 'compress'.
operationNoMemory lifecycle operation: 'list' to show active memory stores, 'compress' to encode text into semantic triples, 'consolidate' to merge memory, 'export' to dump graph, 'reset' to clear all memory, 'delete' to remove a specific store.list
store_nameNoIdentifier of the target memory store to manage.default
project_rootNoWorkspace root where memory stores are managed (default: current directory)..

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv7.3.2
  2. Removedv7.0.1
  3. Addedv7.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, the description discloses which operations destroy on-disk data ('reset' and 'delete' remove stored memory data from disk), the idempotency split per operation, zero auth, sub-50ms latency, and error handling for unrecognized modes. The only weakness is that the tool-level idempotency statement is coarser than the per-operation reality, and no warning is given that 'reset' is irreversible/unscoped.

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?

Front-loaded and well-sectioned with headers, but the Parameters block duplicates the 100%-covered schema verbatim and adds bulk without value, and the opening sentence is a long run-on. Roughly a third of the text is redundant given the structured fields.

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

Completeness4/5

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

For a destructive, multi-mode lifecycle tool the description covers operations, destructive semantics, auth, latency, errors, and alternatives; an output schema exists so the brief Returns line is sufficient. The one gap is the operation-vocabulary mismatch ('decompress') between description and schema, leaving the exact valid mode set ambiguous.

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

Parameters3/5

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

Schema description coverage is 100%, so the description's parameter block largely restates what is already structured. It does add the 7-value operation vocabulary, but it lists a 'decompress' operation that is absent from the schema's own operation description, creating an inconsistency an agent could trip on rather than added clarity.

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 opens with a specific verb+resource ('Manages the complete lifecycle of persistent agent semantic memory stores') and enumerates the concrete operations (compress, consolidate, export, list, reset, delete). It explicitly distinguishes itself from query_memory_store and prune_code_snippet, so an agent can route correctly without opening the schema.

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?

Dedicated 'When to use' and 'When NOT to use' sections name the exact sibling alternatives and the conditions that select them ('querying existing knowledge triples or causal chains' → query_memory_store; 'pruning source code snippets' → prune_code_snippet). Both positive and negative routing is covered.

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