Skip to main content
Glama

add_memory

Persist facts, preferences, or conversation context as a searchable memory. Automatically checks for duplicates and indexes it for later retrieval.

Instructions

Store a new memory with automatic deduplication and indexing. Use for persisting facts, preferences, or conversation context. Checks for duplicates by default (85% similarity threshold). Returns immediately; background processing handles indexing. Prefer over update_memory for new content. Returns: confirmation text. Side effects: creates memory record, updates search index, may skip if duplicate detected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asyncNoEnable background processing. true: returns immediately, indexes async. false: blocks until complete. Default: true.
contentNoPlain text content to store. Use instead of messages for simple facts. Either content or messages required, not both.
user_idNoUser namespace for memory isolation. Default: "oliver". Use consistent IDs to retrieve related memories.
messagesNoConversation messages to store. Use instead of content for multi-turn context. Each message needs role and content fields.
metadataNoKey-value pairs for categorization (e.g., {category: 'preferences', source: 'onboarding'}). Searchable via search_memory.
priorityNoCache priority. high: immediate L1 cache (24h TTL). medium: standard processing. low: L2 cache (7d TTL). Default: medium.
skip_duplicate_checkNoBypass duplicate detection. Use only when intentionally storing similar content. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv1.3.2
    • removedInput schema / properties / async / default
      Removed value: -true
    • changedInput schema / properties / async / description
      Previous value: -"Process asynchronously for better performance"New value: +"Enable background processing. true: returns immediately, indexes async. false: blocks until complete. Default: true."
    • changedInput schema / properties / content / description
      Previous value: -"Direct memory content (alternative to messages)"New value: +"Plain text content to store. Use instead of messages for simple facts. Either content or messages required, not both."
    • changedInput schema / properties / messages / description
      Previous value: -"Array of message objects (alternative to content)"New value: +"Conversation messages to store. Use instead of content for multi-turn context. Each message needs role and content fields."
    • changedInput schema / properties / metadata / description
      Previous value: -"Additional metadata"New value: +"Key-value pairs for categorization (e.g., {category: 'preferences', source: 'onboarding'}). Searchable via search_memory."
    • removedInput schema / properties / priority / default
      Removed value: -"medium"
    • changedInput schema / properties / priority / description
      Previous value: -"Processing priority (high = immediate cache)"New value: +"Cache priority. high: immediate L1 cache (24h TTL). medium: standard processing. low: L2 cache (7d TTL). Default: medium."
    • removedInput schema / properties / skip_duplicate_check / default
      Removed value: -false
    • changedInput schema / properties / skip_duplicate_check / description
      Previous value: -"Skip duplicate detection (use with caution)"New value: +"Bypass duplicate detection. Use only when intentionally storing similar content. Default: false."
    • removedInput schema / properties / user_id / default
      Removed value: -"oliver"
    • addedInput schema / properties / user_id / description
      Added value: +"User namespace for memory isolation. Default: \"oliver\". Use consistent IDs to retrieve related memories."
  2. First observedv1.3.1

TDQS

A4.6/5.0
Behavior4/5

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

The description goes well beyond the sparse annotations by disclosing deduplication with an 85% threshold, background indexing, side effects, and the possibility of skipping a duplicate. However, 'Returns immediately' is stated unconditionally even though the schema allows async=false to block until completion, so the description slightly oversimplifies behavior.

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 front-loaded and compact, with the core action and key behaviors in the first sentences. It loses a point for slight redundancy: the immediate-return and background-processing idea appears twice, once in prose and once in the side-effect list.

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?

Despite having seven parameters and no output schema, the description covers the use case, duplicate-check behavior, async return behavior, expected return value ('confirmation text'), and side effects. Combined with a fully documented schema, this is complete enough for an agent to invoke the tool correctly.

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 100%, so the baseline is 3. The description adds extra meaning by giving the default duplicate-detection threshold (85%) and by noting return behavior and side effects, which helps contextualize skip_duplicate_check and async. It does not deeply annotate each parameter, but the schema already does that.

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 and resource: 'Store a new memory with automatic deduplication and indexing.' It also names the exact use cases (facts, preferences, conversation context) and explicitly distinguishes itself from update_memory, so an agent can tell at a glance which operation this is.

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?

It states when to use the tool ('Use for persisting facts, preferences, or conversation context') and gives a direct sibling-route instruction: 'Prefer over update_memory for new content.' This is explicit enough for an agent to choose between the two most similar memory tools.

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