Skip to main content
Glama

memory_store_tool

Store and index memories with semantic deduplication and automatic relationship inference for persistent AI assistant context.

Instructions

Store a new memory with semantic indexing, deduplication, and automatic relationship inference.

FAST PATH: If daemon is running, queues for async embedding (<10ms response). The daemon handles embedding and storage in the background.

Auto-linking behavior:

  • ALWAYS works using embedding similarity (no LLM required)

  • Creates 'relates_to' edges for memories above similarity_threshold

  • If LLM available, upgrades edge types to supersedes/contradicts/caused_by

  • Set auto_link=False to disable automatic edge creation

Args: content: The memory content text memory_type: Type of memory (preference, decision, pattern, session) namespace: Scope of the memory (default from RECALL_DEFAULT_NAMESPACE config) importance: Importance score from 0.0 to 1.0 (default from RECALL_DEFAULT_IMPORTANCE config) metadata: Optional additional metadata as dict auto_link: If True, automatically create edges to similar memories (default: True) similarity_threshold: Minimum similarity for auto-linking, 0.0-1.0 (default: 0.6) max_auto_links: Maximum auto-created edges per memory (default: 5) use_llm_classification: If True, use LLM to refine edge types (default: True)

Returns: Result dictionary with: - success: Boolean indicating operation success - queued: True if queued via daemon (fast path) - queue_id: Queue ID if queued via daemon - id: Memory ID (if sync path used) - content_hash: Content hash for deduplication (sync path only) - auto_relationships: List of automatically inferred relationships (sync path only) - error: Error message (if failed)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYes
memory_typeNosession
namespaceNo
importanceNo
metadataNo
auto_linkNo
similarity_thresholdNo
max_auto_linksNo
use_llm_classificationNo
queue_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers comprehensive behavioral information. It explains the dual execution paths (fast async vs sync), auto-linking behavior with embedding similarity and optional LLM upgrades, default values, and return structure. This covers performance characteristics, side effects, and operational details that annotations would typically provide.

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 well-structured with clear sections (purpose, fast path, auto-linking behavior, Args, Returns) and front-loads the core purpose. While comprehensive, it's appropriately sized for a complex tool with 10 parameters. Minor points deducted for some redundancy between the auto-linking description and parameter explanations.

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 tool's complexity (10 parameters, no annotations, no output schema initially), the description provides complete context. It explains the tool's purpose, behavioral characteristics, all parameters with semantics, and the return structure. The 'Returns' section effectively serves as an output schema, making the description self-contained and comprehensive.

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?

With 0% schema description coverage and 10 parameters, the description fully compensates by providing detailed explanations for all parameters in the 'Args' section. Each parameter gets a clear semantic explanation beyond just the parameter name, including defaults, ranges, and behavioral implications (e.g., 'auto_link=False to disable automatic edge creation').

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's purpose: 'Store a new memory with semantic indexing, deduplication, and automatic relationship inference.' It specifies the verb ('store') and resource ('memory') with distinguishing features (semantic indexing, deduplication, relationship inference) that differentiate it from siblings like memory_list_tool or memory_recall_tool.

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 clear context about when to use the tool (storing new memories with specific features) and mentions the 'FAST PATH' behavior with daemon. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, which would be needed for a perfect score.

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/blueman82/recall'

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