Skip to main content
Glama

memory_store

Save one important fact into an encrypted, persistent personal memory vault that is shared across all agent sessions, so it can be recalled later. Ideal for credentials, preferences, and decisions, not for trivial details.

Instructions

Save ONE fact to the user's persistent, encrypted, cross-session memory: anything worth recalling later that is not common public knowledge - names, addresses, contacts, account IDs, passwords, API keys and other credentials, file paths, configuration, preferences, and durable facts or decisions. Call this the moment such information appears. Do NOT store transient chatter or one-off trivia.

text is a SINGLE claim in one or two sentences. Not a summary, not a session log, not a paragraph with several facts in it. If you have several facts, call memory_store_many instead - it stores them all in one call, so there is never a reason to bundle them into one record. A blob cannot be re-tagged, re-dated, superseded, or deduplicated fact by fact, and it returns in full every time any sentence inside it matches a search.

source is REQUIRED: how this fact was established, in a few words. A fact discovered somewhere must say where or how - "web search", "read from pyproject.toml", "observed in the git log", "ran the command", "GitHub API". Something the user told you, a preference or a decision, says so: "from chat". Never invent a method you did not use.

discovered is the DATE the fact became known, as YYYY-MM-DD, and defaults to today. Pass it only when the fact was established on a different day from the one you are storing it on - reading an old log, or writing up yesterday's work. This is not the same as when the memory was saved, which compartment records itself with the time of day included.

compartment appends the method and the discovery date to the stored text as a short "[web search, 2026-08-01]" clause, so never write either into the text yourself.

Write world facts as observations ("a search showed X"), never as timeless truths - they are read years later. Facts about the user and decisions they made can be stated plainly.

importance is a weight from 0.0 to 1.0 (default 0.5); anything outside that range is clamped, not rejected. The tiers in use are: 0.90 decisions, consent, and an explicit "remember this"; 0.80 personal facts and preferences about the user; 0.75 the user's machine, environment, and configuration; 0.55 other substantive statements; 0.20 pleasantries.

Returns the id (or an existing id if a near-duplicate), with the stamped date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNo
textYes
sourceYes
namespaceNo
discoveredNo
importanceNo
quarantinedNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description carries the full disclosure burden and does so thoroughly: persistence, encryption, cross-session scope, automatic appending of method/date clauses, clamping of importance, near-duplicate return behavior, and the long-term readability advice all go beyond the schema. No contradiction with annotations exists.

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-organized into purposeful paragraphs, with the core purpose front-loaded and detailed semantics following. Some list-like enumeration could be trimmed, but each section earns its place given the complexity of the tool.

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?

For a 7-parameter memory tool with no annotations and no schema descriptions, this description is remarkably complete: it covers scope, exclusions, alternatives, parameter formats, clamping behavior, return value, and temporal semantics. The missing tags/namespace/quarantined explanations are minor relative to the overall completeness.

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 description coverage is 0%, and the description compensates well for text, source, discovered, and importance with detailed semantics and defaults. However, three parameters (tags, namespace, quarantined) receive no explanation at all, so the compensation is incomplete.

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 object: 'Save ONE fact to the user's persistent, encrypted, cross-session memory,' and then defines what counts as a memory-worthy fact. It clearly distinguishes itself from the sibling memory_store_many by emphasizing single-claim records and explicitly directing multi-fact cases elsewhere.

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?

Provides explicit when-to-use guidance ('Call this the moment such information appears') and what to avoid ('Do NOT store transient chatter or one-off trivia'). Names memory_store_many as the alternative for multiple facts and gives nuanced source/discovered date instructions.

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/MaxFreedomPollard/Compartment'

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