Skip to main content
Glama

memory

Persist and retrieve semantic memory across sessions. Supports storing key-value entries, appending fragments, editing sections, and semantic search.

Instructions

On session start: get session:latest + project:overview. Semantic memory for cross-session persistence. Returns {success, results/value}. Actions: store (save key+message, full overwrite), append (add fragment to existing key without rewriting it - server concatenates and re-embeds), replace_section (in-place edit of marker-bounded region inside an existing entry), search (semantic query), get (exact key), delete, list. RAM-backed with async disk persist - use liberally. Key conventions: session:latest (current state), project:overview (architecture), learn: (discoveries), pref: (user prefs), todo:, code:. For large rolling docs (timelines, session logs) use append instead of store - massive token savings. For in-place section edits inside a long doc, use replace_section with HTML-comment markers like ''/''. Search is semantic with synonym expansion ('fast'->'quick'). Use preprocess=False for exact match. When encountering issues or problems search for related context. On milestones: store session:latest.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNoStorage key (e.g., 'learn:kg-patterns'). Required for store/append/replace_section/get/delete.
tagsNoTags for filtering (search/list) or storing. Auto-extracted from key prefix (learn:topic -> ['learn']).
limitNoMax results for search/list. Default: 10.
queryNoSemantic search query. Finds related content even with different wording.
actionYesstore=full overwrite, append=add fragment without rewrite, replace_section=in-place edit between markers, search=semantic query, get=exact key, delete=remove, list=all keys
offsetNoFor get: starting char offset into stored text. Use with _next_offset from prior response to page through large entries.
messageNoContent for store/append. For store: full content (overwrites). For append: only the new fragment to add. Markdown supported.
sort_byNoSort order for list: 'date' (newest first) or 'key' (alphabetical).
user_idNoUser namespace. Default: 'default'.
inclusiveNoFor replace_section: if False (default) preserve markers and replace only between them. If True, replace markers along with the content.
max_charsNoFor get: max chars to return from offset. 0 = all remaining. Response includes _total_chars and _next_offset if more data exists.
separatorNoFor append: string inserted between existing text and new fragment. Default '\n\n'. Pass '' for butt-join.
end_markerNoFor replace_section: closing marker. Convention: '<!-- name:end -->'. Must follow start_marker in the document.
new_contentNoFor replace_section: replacement content for the region between markers. Falls back to 'message' if not provided.
start_markerNoFor replace_section: opening marker. Convention: '<!-- name:start -->' (HTML comment, invisible in rendered markdown).
create_if_missingNoFor append (default True) and replace_section (default False): if True, create the key/section when it doesn't exist instead of erroring.
Behavior5/5

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

With no annotations, the description carries full burden and does so thoroughly. It discloses RAM-backed async disk persistence, server-side concatenation and re-embedding for append, semantic search with synonym expansion ('fast'->'quick'), full-overwrite semantics for store, and marker behavior for replace_section. It even mentions preprocess=False for exact match, adding genuine behavioral nuance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although lengthy, the description is densely packed and logically structured: it opens with the most critical startup routine, then defines the tool's purpose, summarizes actions, lists key conventions, and ends with targeted usage tactics. Every sentence earns its place given the tool's complexity (7 actions, 16 params).

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?

The description covers the main use cases, return shape ({success, results/value}), persistence semantics, and key conventions. It lacks detailed per-action return schemas and explicit error-handling behavior. Given no output schema and high complexity, it is mostly complete but not exhaustive.

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 baseline is 3. The description adds value by clarifying action semantics (store=full overwrite, append=add fragment, replace_section=in-place edit), explaining the purpose of markers, and providing key conventions like 'learn:<topic>'. The reference to preprocess=False is extra, though the parameter is not in the 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 the tool is 'semantic memory for cross-session persistence' and enumerates seven specific actions (store, append, replace_section, search, get, delete, list), along with key naming conventions. This distinguishes it from sibling tools by explicitly framing its role as a persistent memory system.

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 strong when-to-use guidance: 'On session start: get session:latest + project:overview', 'When encountering issues or problems search for related context', and 'On milestones: store session:latest'. It also advises using append for large rolling docs and replace_section for in-place edits. However, it never explicitly contrasts with sibling tools like sqlite/retrieve/kg, so it lacks explicit when-not-to-use 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/cutlerbenjamin1-cmd/hybrid-recall'

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